# Hybrid Secure Authentication and Key Exchange Scheme for M2M Home Networks

Authors: Uğur Coruh; Oğuz Bayat
Journal: Security and Communication Networks
 (2018)

---

## Abstract

In this paper, we analyzed Sun et al.’s scheme which proposes an M2M (Machine-to-Machine) secure communication scheme by using existing TD SCMA (Time Division-Synchronous Code Division Multiple Access) networks. They offer a password-based authentication and key establishment protocol for mutual authentication. Moreover, their proposed secure channel establishment protocol uses symmetric cryptography and one-way hash algorithms and they considered using their protected channel model for mobile users and smart home networks. In this paper, we propose to complete the missing part of Sun et al.’s scheme. This can occur by addressing privacy-preserving and message modification protection. Moreover, improvements can be made to MITM (Man-In-The-Middle) attack resistance, anomaly detection and DoS (Denial-of-Service) attacks with timing. ECDH (Elliptic Curve Diffie Hellman) cryptography based protected cipher-key exchange operation used on initial setup and key-injection operations to provide secure user registration, user password change and home gateway network join phases. We simulated both the proposed and Sun et al.’s schemes. We analyzed Sun et al.’s scheme for performance, network congestion and resource usage. Missing privacy-preserving was analyzed and compared with the GLARM scheme, and the storage cost of each phase was analyzed according to Ferrag et al.’s survey proposal. In Sun et al.’s scheme, future work for the security architecture of the home network is related to Li et al.’s protocol being implemented in our proposed design.


---

## Body

## 1. Introduction

Security trade-off and optimization are the most common problems in IoT (Internet-of-Things) devices which come with limited resources. The most common part of an IoT network is interconnection and interoperability between machines, which is called M2M communication.M2M communication covers a wide area including home networks and telecommunication devices. Privacy protection and robust identification, authentication, and authorization requirements are provided with limited system resources.The improvement of consumer products also improves smart home networks and this leads to an increase in wireless network connected devices per user. Moreover, this situation increases the deployment of private information to public networks and increases the security requirements for M2M communication according to the attacks essentially stated in [1].The contributions of this paper focus on message modification, privacy-preserving considered in [2], state management, anomaly detection with the timing for reliable communication, and finally home gateway and user device revocation. Furthermore, we updated current scheme phases and provided security for user registration, password change, and home gateway join stages. In this paper, we aim to fill the security gaps in [3] to provide end-to-end security for practical usage in M2M networks.In [3], the security protocol does not specify on privacy-preserving and message modification. We provide methods for solving these issues. Design [3] does not identify messages, and the scheme entity states are not managed well for reliable data communication. Moreover, mobile user device and home gateway device revocations are not mentioned in their scheme. Design [3] is not resistant to attacks such as the DoS attacks mentioned in [2, 4, 5] or the message modification mentioned in [6]. Our contributions are improving current protection for a number of attacks and we propose an end-to-end enhanced secure authentication and communication scheme. Scheme [3] sends a clear password and ID (identification data) to the public network and assumes that a connection is secure during registration and password change operations. We analyzed privacy-preserving and compared it with the GLARM scheme [2]. In addition, the storage cost of the phases were examined according to survey guidelines [1, 3]. Future work for the security architecture of the home network which is related to [7] is performed in our proposed design.This paper is organized as follows. Section2 describes M2M network related authentication protocols, Section 3 reviews [3], and Section 4 shows its weaknesses. Section 5 presents a proposal of our plan. Section 6 explains the formal analysis and simulation of our proposed protocol. Section 7 presents a security analysis and Section 8 presents a performance comparison of the proposal and [3] security. Finally, Section 9 concludes the paper.


## 2. Related Works

Current scheme [3] is examined in the survey [1], and it is efficient in terms of performance and network congestion compared to the OTP based scheme in [18]; however, privacy-preserving is not analyzed and compared with the GLARM scheme [2], storage cost is not mentioned, and a comparison with the PBA scheme is not sufficient according to survey analysis in [1]. Current scheme [3], which is the composition of a home network model, is proposed in [18, 19]. Scheme [18] is proposed as an OTP based user authentication scheme and [19] is the biometric information based authentication scheme. Scheme [3] is efficient regarding the amount of calculation and network congestion volume compared with [18].Table1 shows M2M network authentication protocol cryptosystems and countermeasures. Additionally, [1] analyzed and classified several schemes to attacks in Table 2. We added our scheme to their results in Table 2. Scheme [1] organizes the designs as “fully supported” and “partially supported” for attacks in Table 2. If a scheme is classified as fully supported for an attack, this means that the authors of the scheme have proven formal verification techniques or simulations perform the reliability of their scheme against the selected attack and security analysis for all conditions. If a scheme claims an attack but there is insufficient formal verification, the simulation of the scheme is classified as partially supported to an attack. If the scheme does not provide security for an attack, then the scheme is classified as not supported. Additionally, this same notation is used in [20–23].Table 1
Summary of cryptosystems and countermeasures in M2M communication [1].
Cryptosystems and Countermeasures [8] [2] [9] [4] [6] [3] [5] [10] [11] Ours Secure cryptographic hash function [12]  ✓ ✓ ✓ ✓ ✓  ✓ ✓ ✓ Original data acquisition        ✓ Spatial-Domain transformation        ✓ Time-domain transformation        ✓ C-MA (Correlation coefficient-based matching algorithm) ✓ D-MA (Deviation ratio-based matching algorithm) ✓ AMACs (Aggregate message authentication codes) [13]  ✓       ✓ Certificateless aggregate signature [14]   ✓ ECDH (Elliptic Curve Diffie-Hellman) [15]    ✓      ✓ ID-based signature scheme [13]     ✓ AES (Advanced encryption standard) [16]      ✓    ✓ Hybrid Linear Combination Encryption [17]       ✓ Supported = ✓; empty = not supported.Table 2
Summary of attacks in M2M networks and defense protocols [1].
Adversary model [8] [2] [9] [4] [6] [3] [5] [10] [11] Ours Audio Replay attack ✓ ✓  ✓ ✓ ✓   1 ✓ Changing distance attack ✓         ✓ Same-type-device attack ✓         ✓ Composition attack ✓         ✓ Redirection attack ✓ ✓ ✓ ✓   ✓  ✓ ✓ Man-in-the-middle attack ✓ ✓ ✓ ✓ ✓ ✓   ✓ ✓ Substitution attack ✓ ✓ ✓ ✓ ✓     ✓ DoS attack  ✓  ✓   ✓   ✓ Replay attack ✓   ✓ ✓ ✓   ✓ ✓ Forging attack    ✓      ✓ Colluding attack ✓   ✓   ✓   ✓ Flooding attack ✓      ✓  ✓ ✓ Side-channel attack ✓      ✓  ✓ ✓ False messages attack ✓    ✓ ✓ ✓  ✓ ✓ Sybil attack     ✓ ✓   ✓ ✓ Movement tracking     ✓    ✓ ✓ Message modification     ✓     ✓ Impersonation attack     ✓ ✓ ✓   ✓ Guessing attack      ✓    ✓ Stolen-verifier attack      ✓    ✓ Wormhole attack ✓ ✓  ✓  ✓   ✓ ✓ Blackhole attack ✓ ✓  ✓ ✓ ✓   ✓ ✓ Attribute-trace attack     ✓     ✓ Eavesdropping attack     ✓ ✓   ✓ ✓ Chosen-plaintext attack     ✓    ✓ ✓ Spam attack ✓    ✓ ✓   ✓ ✓ Identity theft attack ✓     ✓    ✓ User manipulation attack ✓     ✓ ✓  ✓ ✓ Routing attack ✓     ✓    ✓ Linkability attack ✓         ✓ Rejection attack          ✓ Successive-response attack          ✓ Packet analysis attack  ✓    ✓   ✓ ✓ Packet tracing attack  ✓    ✓   ✓ ✓ Brute-force attack ✓ ✓  ✓ ✓  ✓ ✓  ✓ Fully supported =✓, partially supported = ✓, and empty = not supported.


## 3. Review of Sun et al.’s [3] Scheme

In this section, we critique the security authentication scheme in an M2M home network service using existing the TD-SCMA network proposed by Sun et al. [3]. Their scheme has three main components: the user device, the M2M server, and the home gateway device. Scheme [3] consists of five phases: setup, user registration, user login and authentication, user password change, and home gateway join to the TD-SCMA network. The M2M server is a central server in this scheme, as shown in Figure 1.Figure 1
Structure of Sun et al.’s [3] M2M model.M2M servers are defined by an individual identifier and contain a secret key for storage encryption. The user selects a password and user ID which are transferred to the M2M server for registration using mobile devices over an unsecured communication link. The M2M server encrypts and stores the password and the M2M server produces and sends random data to the mobile user device for mutual authentication input and reserves this arbitrary data in the M2M server database. This random value is stored in the mobile user device. During the login and authentication request, the user device generates a message which contains a user ID and an encrypted random number. This random number is encrypted with a user password. The user device then posts this message to the M2M server for registration. Each entity calculates a session key and they verify each other. The password is used as a primary key for mutual authentication. Authenticated users can access their home gateway device information over the M2M server using their mobile devices. In this system, each home gateway device joins the network with their unique ID. When a home gateway boots up, it transmits its unique ID to the M2M server which searches for this ID related user and if it is a match, it then calculates the hash of the combined user ID, user arbitrary data, and M2M server ID data and transmits it to the home gateway for session key computation. The M2M server also calculates the session key for a home gateway for data exchange services. Protocol notations are listed in Tables3 and 4 showing the parameter settings used in the current design.Table 3
Notation of Sun et al.’s scheme [3].
Notation Description k The secret key of the M2M server u i d Mobile user’s ID m i d M2M server’s ID p w User’s password u m k The session key between a user and M2M server h i d Home gateway ID s f Status flag of the mobile user h ( . ) Cryptographic hash function h ( m , n ) Hashing of the concatenation ofm and n m n Most significantn bits of string m F e - A E S ( a , b ) Using AES function to encrypt a with b as the key F d - A E S ( a , b ) Using AES function to decrypt a with b as the keyTable 4
Protocol parameter settings at Sun et al.’s scheme [3].
Parameters Settings and Description s Salt, a 16-bit random number k The secret key of M2M server, 64 bits u i d The equipped SIM card number, 80 bits m i d The equipped SIM card number, 80 bits h i d The equipped SIM card number, 80 bits u m k A session key, 128 bits p w User’s password, 64 bits s f User’s statue flag, 1 bit x 1 128 bits x 2 128 bits h ( . ) SHA-1 Hash, 160 bits output m 128 bits n 128 bits t 128 bits F e - A E S ( a , b ) AES encryption function with 128 bits input, 128 bits key and 128 bits output F d - A E S ( a , b ) AES decryption function with 128 bits input, 128 bits key and 128 bits outputThe encryption and decryption procedures are based on AES (Advanced Encryption Standard), and SHA-1 (Secure HashAlgorithm 1) used as a one-way hash function in the protocol. Figures 2 and 3 show scheme [3] and the proposed scheme’s performance metrics and comparisons for AES MATLAB implementation. Scheme [3] does not demonstrate that their measurements carried AES key schedule operation in encryption and decryption processes. According to our measurement and comparison results, we noticed that their analysis results were close to the AES encryption and decryption without a cipher-key schedule operation’s measurement results. Overall measurements for the proposed scheme are close to the measurement results of [3]. Current measurement results show that AES encryption is faster than decryption, which is the same as the result reported in scheme [3]. These results are presented in Figures 2 and 3. Figure 4 shows scheme [3]’s and the proposed scheme’s performance metrics and comparisons for the SHA-1 MATLAB implementation.Figure 2
AES encryption performance comparison with Sun et al. [3].Figure 3
AES decryption performance comparison with Sun et al. [3].Figure 4
Hash performance comparison with Sun et al. [3].The following subsections cover the complete phase examination of the design [3].


### 3.1. Sun et al.’s [3] Setup Phase

During the setup operation, the M2M server selects the 64-bit server secret keyk. This key is not directly used in cryptographic procedures; it is used as an input to compute the operation key. ID personalization is not specified in the setup phase for each entity; it is specified during the setup operation. There must be a single 80-bit M2M server ID personalized to the smart card to define the M2M server. The server can interact with smartcards. The home gateway device is uniquely identified with an 80-bit ID and customized to a smartcard which is deployed with the home gateway device. Additionally, users are uniquely identified with an 80-bit ID and stored on the smart card.


### 3.2. Sun et al.’s [3] User Registration Phase

A new user submits a concatenated 80-bit user ID, a 64-bit clear password, and an 80-bit home gateway ID as follows:<uid,pw,hid> for registration. Scheme [3] assumes that the communication channel is protected. For this reason, the password is sent in the clear form. Additionally, the current scheme assumes that communication is performed reliably. For this reason, there is no message identification. The M2M server selects a random number s for salt and concatenates with both the M2M server secret key and user ID, followed by calculating the one-way hash of the buffer with SHA-1 and received the first 128 bits of the 160-bit SHA-1 output for the AES encryption key, as follows:(1)d=hk,uid,s(2)keyAES=dnThe M2M server encrypts the user password for storage as follows:(3)p=Fe-AESpw,keyAESUser ID, home gateway ID, salt, encrypted password, and statue flag<uid,hid,s,p,sf> are stored in the database and salt s is transmitted to the user device. Finally, the user device stores salt for login and the authentication operation.


### 3.3. Sun et al.’s [3] User Login and Authentication Phase

This phase ensures secure user communication by performing mutual authentication between the M2M server and the user device over the TD-SCMA network. Messages are not distinguished and reliable data communication is not considered. The user device selects a random numberx1 and calculates the following parameters for an authentication request:(4)g=Fe-AESx1,pw(5)h1=hx1The user device sends the request parameters<uid,g,h,s> to the M2M server, which searches uid and validates s in the M2M server database. If uid does not exist, the request is rejected. Otherwise, the M2M server retrieves the key from the message and decrypts the stored password and processes identical computations to verify the received hash value to guarantee that the user password is correct.(6)keyAES=hk,uid,sn(7)pw′=Fd-AESp,keyAES(8)x1′=Fd-AESg,pw′(9)h1′=hx1′If the receivedh1′ value is equal to the calculated h1 value, it guarantees that the user password and ID are correct, and the user is confirmed by the M2M server. Otherwise, the M2M server declines the operation. If the user is verified, then the M2M server selects another arbitrary number x2 to calculate umk for the communication session key and sends the required values to the user device for the same session key creation; thus,(10)umk=hx1′,x2n(11)h2=humk,midThe M2M server storesumk and sends <mid,x2,h2> to the user device. The user device uses a created x1 and received mid,x2, and h2 for session key umk generation and verifies the M2M server h2 value as follows:(12)umk′=hx1,x2n(13)h′2=humk′,midIf the calculatedh′2 value is equal to the approved h2 value, then the session key is stored in the mobile user device for secure communication, and, finally, the user device calculates the hash h3, as follows:(14)h3=humk′,uidThe user device sendsh3 to the M2M server, and, finally, the M2M server verifies the h3 hash; thus,(15)h′3=humk,uidIf theh3 value is equal to the h′3 value, then a mutual authentication is established between the M2M server and the user device and umk is used for secure data transmission.


### 3.4. Sun et al.’s [3] User Password Change Phase

A user password provides time-based security, and, for this reason, it must be periodically updated. In this phase, the user updates an old password with a new password, thereby receiving a new arbitrary salt values for the next login and authentication operation. Scheme [3] assumes that the data transmission channel is secure and reliable for a password change operation. The password change operation starts from the user device, which sends the user ID, clears the old password, and clears the new password and the current random salt value is formatted thus <uid,pw,pwnew,s> to the M2M server. The M2M server searches for the user ID and obtains an encrypted password p from the database, after which it recovers the password encryption key and encrypts a clear password pw for verification with some subsequent calculations:(16)keyAES=hk,uid,sn(17)p′=Fe-AESpw,keyAESIf the calculated passwordp′ is equal to the stored p, then the M2M server selects a new random salt snew and encrypts the new password to store in the M2M server database; thus,(18)key′AES=hk,uid,snewn(19)pnew=Fe-AESpwnew,key′AESThe M2M server stores the encrypted passwordpnew and sends new salt snew to the user device. The user device stores snew for a new login and authentication process.


### 3.5. Sun et al.’s [3] Home Gateway Join TD-SCMA Network

Home gateway devices send network join requests to M2M servers when powered. This request includes a prepersonalized unique identifier<hid> that is stored on a smart card. Each home gateway must be associated with a user device on the M2M server. For this reason, the M2M server checks related user devices with this home gateway device ID. If a user device exists, then the M2M server calculates the session key Hkey for data transmission followed by key recover data Hp for the home gateway device; thus,(20)Hp=huid,mid,sm(21)Hkey=hhid,HptH k e y is saved on the M2M server and Hp is posted to the home gateway device which calculates Hkey for data transmission. The home gateway device does not need to know the user ID for the session key production:(22)Hkey=hhid,Hpt


## 3.1. Sun et al.’s [3] Setup Phase

During the setup operation, the M2M server selects the 64-bit server secret keyk. This key is not directly used in cryptographic procedures; it is used as an input to compute the operation key. ID personalization is not specified in the setup phase for each entity; it is specified during the setup operation. There must be a single 80-bit M2M server ID personalized to the smart card to define the M2M server. The server can interact with smartcards. The home gateway device is uniquely identified with an 80-bit ID and customized to a smartcard which is deployed with the home gateway device. Additionally, users are uniquely identified with an 80-bit ID and stored on the smart card.


## 3.2. Sun et al.’s [3] User Registration Phase

A new user submits a concatenated 80-bit user ID, a 64-bit clear password, and an 80-bit home gateway ID as follows:<uid,pw,hid> for registration. Scheme [3] assumes that the communication channel is protected. For this reason, the password is sent in the clear form. Additionally, the current scheme assumes that communication is performed reliably. For this reason, there is no message identification. The M2M server selects a random number s for salt and concatenates with both the M2M server secret key and user ID, followed by calculating the one-way hash of the buffer with SHA-1 and received the first 128 bits of the 160-bit SHA-1 output for the AES encryption key, as follows:(1)d=hk,uid,s(2)keyAES=dnThe M2M server encrypts the user password for storage as follows:(3)p=Fe-AESpw,keyAESUser ID, home gateway ID, salt, encrypted password, and statue flag<uid,hid,s,p,sf> are stored in the database and salt s is transmitted to the user device. Finally, the user device stores salt for login and the authentication operation.


## 3.3. Sun et al.’s [3] User Login and Authentication Phase

This phase ensures secure user communication by performing mutual authentication between the M2M server and the user device over the TD-SCMA network. Messages are not distinguished and reliable data communication is not considered. The user device selects a random numberx1 and calculates the following parameters for an authentication request:(4)g=Fe-AESx1,pw(5)h1=hx1The user device sends the request parameters<uid,g,h,s> to the M2M server, which searches uid and validates s in the M2M server database. If uid does not exist, the request is rejected. Otherwise, the M2M server retrieves the key from the message and decrypts the stored password and processes identical computations to verify the received hash value to guarantee that the user password is correct.(6)keyAES=hk,uid,sn(7)pw′=Fd-AESp,keyAES(8)x1′=Fd-AESg,pw′(9)h1′=hx1′If the receivedh1′ value is equal to the calculated h1 value, it guarantees that the user password and ID are correct, and the user is confirmed by the M2M server. Otherwise, the M2M server declines the operation. If the user is verified, then the M2M server selects another arbitrary number x2 to calculate umk for the communication session key and sends the required values to the user device for the same session key creation; thus,(10)umk=hx1′,x2n(11)h2=humk,midThe M2M server storesumk and sends <mid,x2,h2> to the user device. The user device uses a created x1 and received mid,x2, and h2 for session key umk generation and verifies the M2M server h2 value as follows:(12)umk′=hx1,x2n(13)h′2=humk′,midIf the calculatedh′2 value is equal to the approved h2 value, then the session key is stored in the mobile user device for secure communication, and, finally, the user device calculates the hash h3, as follows:(14)h3=humk′,uidThe user device sendsh3 to the M2M server, and, finally, the M2M server verifies the h3 hash; thus,(15)h′3=humk,uidIf theh3 value is equal to the h′3 value, then a mutual authentication is established between the M2M server and the user device and umk is used for secure data transmission.


## 3.4. Sun et al.’s [3] User Password Change Phase

A user password provides time-based security, and, for this reason, it must be periodically updated. In this phase, the user updates an old password with a new password, thereby receiving a new arbitrary salt values for the next login and authentication operation. Scheme [3] assumes that the data transmission channel is secure and reliable for a password change operation. The password change operation starts from the user device, which sends the user ID, clears the old password, and clears the new password and the current random salt value is formatted thus <uid,pw,pwnew,s> to the M2M server. The M2M server searches for the user ID and obtains an encrypted password p from the database, after which it recovers the password encryption key and encrypts a clear password pw for verification with some subsequent calculations:(16)keyAES=hk,uid,sn(17)p′=Fe-AESpw,keyAESIf the calculated passwordp′ is equal to the stored p, then the M2M server selects a new random salt snew and encrypts the new password to store in the M2M server database; thus,(18)key′AES=hk,uid,snewn(19)pnew=Fe-AESpwnew,key′AESThe M2M server stores the encrypted passwordpnew and sends new salt snew to the user device. The user device stores snew for a new login and authentication process.


## 3.5. Sun et al.’s [3] Home Gateway Join TD-SCMA Network

Home gateway devices send network join requests to M2M servers when powered. This request includes a prepersonalized unique identifier<hid> that is stored on a smart card. Each home gateway must be associated with a user device on the M2M server. For this reason, the M2M server checks related user devices with this home gateway device ID. If a user device exists, then the M2M server calculates the session key Hkey for data transmission followed by key recover data Hp for the home gateway device; thus,(20)Hp=huid,mid,sm(21)Hkey=hhid,HptH k e y is saved on the M2M server and Hp is posted to the home gateway device which calculates Hkey for data transmission. The home gateway device does not need to know the user ID for the session key production:(22)Hkey=hhid,Hpt


## 4. Weaknesses of Sun et al.’s [3] Scheme

Sun et al.’s [3] scheme provides less calculation cost compared to the scheme in [18]. Scheme [3] can resist a stolen-verifier attack, replay attack, guessing attack, and impersonation attack. However, there are several security vulnerabilities in overall security.Scheme [3] does not ensure anonymity. The user ID is sent plain during the authentication phase. Moreover, during the authentication phase, privacy-preserving is not analyzed, and this argument is indicated in [1], which offers to compare scheme [3] privacy-preserving with GLARM [2]. GLARM uses temporary user ID that is obtained from the original user ID and is transferred in messages for privacy-preserving. The real user ID is never transferred in messages. Storage cost is not analyzed in scheme [3], but, in our review, we simulated the scheme and analyzed every storage and resource change for each phase.A performance analysis is inadequate for comparison with other designs. Moreover, performance measurement initial configurations are not indicated in their work. In the review section, we simulated and analyzed every scheme phase and we used algorithm performance metrics and memory usage.Scheme [3] does not provide secure registration. The password is sent in an open format with an original user ID. They assume that this communication channel would be shielded so if we have a secure channel that is already protected, then we do not need further authentication.Design [3] also does not provide a safe password change operation like the registration operation. The user ID and password are sent in the unciphered format during this operation.An open formatted password sending during registration and a password change operation with the original user ID has a significant problem with privacy security in scheme [3]. Scheme [3] password change and user registration phase are explained in Section 3.Transferred messages are modifiable during communication. There is no MAC (Message Authentication Code) verification for each phase.There is no reliability during operations. Messages are not distinguished with a sequence number or message tag and there is no acknowledgment of messages between communicating entities.Scheme [3] does not have a message timeout and anomaly detection method. Moreover, there is no communication recovery progress in the protocol phases for dropped or corrupted messages.The home gateway joins the network phase unprotected from DoS attacks. A fraudulent device can attempt to join the network since there is no restriction on this operation. If the home gateway ID is retrieved from the home gateway device communication, then the attacker can process the M2M server session key generation for the fraudulent device or device simulators.User and device revocation are not placed at [3]. Salt is used in the home gateway join network phase for session key agreement, and the salt parameter is updated in the password change phase. After the password change request, the new salt value is stored in the user device and the M2M server, but the home gateway device uses the session key that was created with the old salt, and there is no reboot procedure to update the salt and session key on the home gateway side. If user updates owned the password periodically for security reasons, the home gateway would not be affected by this change and risk would increase.


## 5. Proposed Scheme

In this section, we propose an enhanced scheme to fill the missing parts of Sun et al.’s [3] scheme. A proposed scheme notation is listed in Table 5 and our contributions are arranged as shown in Table 5.Table 5
Notation of the proposed scheme.
Notation Description k The secret key of the M2M server u i d Mobile user’s ID t _ u i d Temporal Mobile User’s ID m i d M2M server’s ID p w User’s password u m k The session key between User and M2M server h i d Home Gateway ID t _ h i d Temporal Home Gateway ID u _ s t User State h _ s t Home Gateway State a ∥ b concatenation ofa and b m n Most significantn bits of string m F S H A 256 ( . ) Cryptographic SHA256 hash function F S H A 1 ( . ) Cryptographic SHA1 hash function F e - A E S ( a , b ) Using AES function to encrypt a with b as the key F d - A E S ( a , b ) Using AES function to decrypt a with b as the key F H - M A C ( a , k e y ) Keyed Cryptographic Mac and Hash Function e c d h _ i d User ECDH Key Pairing Identifier k e y E C D H ECDH Secret Key p u b u s e r ECDH User Public Key p r i v u s e r ECDH User Private Key p u b m 2 m ECDH M2M Server Public Key p r i v m 2 m ECDH M2M Server Private Key [ p u b x , p r i v x ] = F i - E C D H ( ) ECDH Key Pair Generation for Entityx k e y E C D H =  F s - E C D H ( p u b u s e r , p r i v m 2 m ) M2M Server ECDH Secret Key Derivation F e - E C D H ( a , k e y E C D H ) ECDH Encryption with inputa F d - E C D H ( a , k e y E C D H ) ECDH Decryption with inputa k e y e n c Encryption Key k e y m a c MAC (Message Authentication Code) Key


### 5.1. Message Modification Protection with Shortened MAC

Our first contribution to the design [3] is providing message modification protection. Scheme [3] messages are modifiable during transmission. There is no MAC verification security. Moreover, the MAC calculator source must be verified by the receiver. For this reason, we opted to use keyed MAC algorithms such as C-MAC (Cipher-based MAC) [24] or H-MAC (the Keyed-Hash Message Authentication Code) [25] based on DES (Data Encryption Standard) or AES. This protection method was performed in [6]. According to performance and resource restrictions, we have decided to use a shortened MAC as described in the PBA scheme [26] to confirm messages. Moreover, the GLARM scheme [2] uses the MAC algorithm specified in [27]. We used an H-MAC based truncated MAC algorithm that has a similar offset selection to HOTP (HMAC-Based One-Time-Password), as explained in [28].Each request and response in a public channel is protected with MAC and if MAC confirmation fails; then the request is terminated by the receiver entity.We simulated and measured the performance of the H-MAC configuration for SHA-256 (Secure HashAlgorithm 256) and SHA-1 with 16-byte and 8-byte keys, as shown in Table 6.Table 6
Truncated MAC calculation performances.
Algorithm Measurement Mean (sn) Measurement Std. (sn) H-MAC-SHA256 16 bytes key 0.000273 0.000094 H-MAC-SHA1 16 bytes key 0.000268 0.000189 H-MAC-SHA256 8 bytes key 0.000267 0.000109 H-MAC-SHA1 8 bytes key 0.000283 0.000134 ISO9797-ALGO-3 16 bytes key 0.000392 0.000226


### 5.2. Privacy-Preserving with Temporal ID

The second contribution to the scheme is replacing the original user ID with a temporary ID to provide privacy-preserving as stated in the GLARM scheme [2]. The GLARM scheme uses a preshared key to derive the ID and temporal ID used in all procedures. Scheme [3] focuses on privacy security, but, during registration and password change phases, they transferred the password and user ID in an open format. Additionally, the original user ID is always posted in the open format for all stages. Therefore, privacy security has a significant problem in scheme [3] and it does not guarantee anonymity.In our scheme, we have a robust method to solve this problem, namely, ECDH key pairing during registration. Key pairing requests are distinguished by the user ECDH key pairing identifier (ecdh_id). This ecdh_id value is calculated from the user ID (uid) with a trimmed SHA-1 during the user setup phase; thus,(23)ecdh_id=FSHA-1uidnThe user sends the public key (pubuser) to the M2M server during the registration stage with ecdh_id and uid is never revealed, as follows:(24)<ECD_SYN,ecdh_id,pubuser>M2M server uses its private key (privm2m) and receives the public key (pubuser) to derive encryption key (keyECDH). For ECDH secure key establishment is as follows:(25)keyECDH=Fs-ECDHpubuser,privm2mThe M2M server encrypts integrity and confidentiality keys withkeyECDH. These encrypted keys and the M2M server public key (pubm2m) are sent to the user device in the same message to decrease the request size in the proposed scheme; thus,(26)Enckeyenc∥keymac=Fe-ECDHkeyenc∥keymac,keyECDH(27)<ECDH_ACK,ecdh_id,pubm2m,Enckeyenc∥keymac>The user receives the public key and derives the ECDH encryption key to decrypt the encrypted keys. After revealing the keys, the user device prepares the registration message (REGISTER_SYN) by calculating the registration message MAC and encrypting the user ID (uid), password (pw), and home gateway ID (hid) with a confidentiality key to be sent with ecdh_id, as follows:(28)macmsg=FH-MACREGISTER_SYN∥ecdhid∥uid∥pw∥hid,keymac(29)encmsg=Fe-AESuid∥pw∥hid∥macmsg,keyenc(30)<REGISTER_SYN,ecdh_id,encmsg>The problem in [3] is that REGISTER_SYN is a similar request message containing sensitive assets in open format. However, we protect these sensitive assets with encryption and MAC. When the M2M server receives encrypted values with the REGISTER_SYN message, then it is decrypted with keyECDH and acquires the clear user ID, after which it calculates a temporary ID with a H-MAC based truncated MAC algorithm by using an integrity key. The output length of this algorithm is the same as the original ID length. The temporary ID generation operation is also is also identically performed in the user device and the next requests are performed using the temporary ID to protect user privacy in the network. An H-MAC based truncated MAC algorithm is typically resistant to brute-force attacks. In addition, ECDH key pairing provides a defense against MITM attacks, and MAC protects messages from modification. These listed protection methods are not provided by scheme [3].


### 5.3. Forward and Backward Secrecy Improvement

The third participation pertains to the improvement of secrecy. MAC and temporal ID operations are enhanced with H-MAC methods. We used protection keys encapsulated with ECDH keys to provide forward and backward secrecy improvement.Scheme [3] registration and password change phases are not protected; however, we protect every step that we proposed. Our scheme follows general standard algorithms such as ECDH, Trimmed H-MAC, and AES. These algorithms, which are used to protect sensitive assets during communication, are resistant to brute-force attacks.


### 5.4. Reliable Operation Processing and State Management

The fourth contribution pertains to service reliability. Scheme [3] does not include the operation plus message timeout, message acknowledgment segment, and message identifier segment. Moreover, the user and home gateway state management are poor. There is only one bit to keep user state online or offline.We have provided a timeout measurement with an internal device clock without a timestamp. This kind of usage does not require an internal RTC (real-time clock) module for devices. If a timeout occurs during transmission, then entities can terminate or resend requests. Additionally, this timeout measurement can be used to detect eavesdropping attacks by checking operation processing times that are used by the timeout control. Each message is identified with a one-byte tag. Entities can evaluate requests with this identifier. The proposed scheme message identifiers are listed in Table7.Table 7
Proposed scheme message identifiers.
Message Name Message Phase Message Sender Message Receiver ECDH_SYN User Registration and Key Pair User M2M Server  ECDH_ACK User Registration and Key Pair M2M Server User  REGISTER_SYN User Registration and Key Pair User M2M Server  REGISTER_ACK User Registration and Key Pair M2M Server User  KEY_SYN User Home User Home Gateway Gateway Key Injection  KEY_ACK User Home Home Gateway User Gateway Key Injection  JOIN_SYN Home gateway Join Home Gateway M2M Server Network  JOIN_ACK Home gateway Join M2M Server Home Gateway Network  JOIN_OK Home gateway Join Home Gateway M2M Server Network  LOGIN_SYN User Login and Authentication User M2M Server  LOGIN_ACK User Login and Authentication M2M Server User  LOGIN_OK User Login and Authentication User M2M Server  PWD_SYN User Change User M2M Server Password  RE_JOIN User Change M2M Server Home Gateway Password  PWD_ACK User Change M2M Server User Password  PWD_NACK User Change User M2M Server Password  PWD_OK User Change User M2M Server Password  LOGOUT_SYN M2MServer User User M2M Server Logout  LOGOUT_ACK M2MServer User M2M Server User LogoutAdditionally, we have updated the state of the machines for the current design. Enhanced states in the proposed protocol are shown in Figures5 and 6.Figure 5
User state processing.Figure 6
Home gateway state processing.


### 5.5. Proposed Scheme Phases

Our proposed scheme consists of ten phases. We designed a practically good system in the real network and we assumed that there was no secure communication network over the public channel. Moreover, in our scheme, the home gateway devices and user devices have WIFI connection capability via the private home network. We added ECDH key sharing between the user device and the M2M server. This operation was consolidated with user registration. Additionally, we added one more phase according to the current scheme for key injection to the home gateway device, and the user logout operation was also defined in the proposed protocol.


#### 5.5.1. Proposed Scheme M2M Server Setup

During the setup operation, the M2M server generates ECDHpubm2m and privm2m key pairs, as follows:(31)pubm2m,privm2m=Fi-ECDHThe generated public key length is 576 bits, and the private key length is 832 bits. Moreover, the M2M server selects a 64-bit server secret key (k), which is mentioned in scheme [3]. During the setup phase, there must be single 80-bit M2M server ID (mid) personalized to the smart card to define the M2M server in the network. The server can communicate with the smart cards.


#### 5.5.2. Proposed Scheme Home Gateway Setup

During the setup operation, the home gateway device is uniquely identified with an 80-bit ID (hid) and is personalized to a smartcard which is deployed with the home gateway device.


#### 5.5.3. Proposed Scheme User Setup

During the setup operation, users uniquely identified with an 80-bit ID (uid), which is stored on the smart card. In addition, for registration, the key pair’s user device generates ECDH pubm2m and privm2m key pair, as follows:(32)pubuser,privuser=Fi-ECDHA temporal 80-bitecdh_id is used for only key pairing that is generated in this phase with the following operation:(33)ecdh_id=FSHA-1uidnThe generated public key length is 576 bits, and the private key length is 832 bits. Additionally, the user should define the 64-bit password (pw) and 80-bis home gateway id (hid) for the registrations.


#### 5.5.4. Proposed Scheme User Registration and Key Pairing

The user resets the operation timer for theECDH_SYN message sending operation and sends the ECDH_SYN message to the M2M server for registration, as follows:(34)<ECD_SYN,ecdh_id,pubuser>The M2M server deriveskeyECDH with pubuser and its own privm2m to use as a transport key; thus,(35)keyECDH=Fs-ECDHpubuser,privm2mThe M2M server generates a 16-bytekeyenc and keymac for secure transmission. These keys are securely transported under keyECDH between the entities, as follows:(36)Enckeyenc∥keymac=Fe-ECDHkeyenc∥keymac,keyECDHThe M2M server resets the operation timer for theECDH_ACK message sending operation and sends the ECDH_ACK message to the user for the key pair, as follows:(37)<ECDH_ACK,ecdh_id,pubm2m,Enckeyenc∥keymac>The user device checks whether theECDH_SYN operation time is within an acceptable time range; if not, then it destroys sensitive assets and terminates the operation; otherwise, it derives keyECDH as follows:(38)keyECDH=Fs-ECDHpubm2m,privuserThe user device decryptsEnckeyenc∥keymac with keyECDH and keeps keyenc∥keymac in temporary memory. At the end of this operation, the M2M server completes user key pairing, and the MAC keys are securely shared for sensitive operations, as follows:(39)keyenc∥keymac=Fd-ECDHEnckeyenc∥keymac,keyECDHAfter key pairing registration data sending, the user registration operation starts from the user side. The user device prepares the MAC of theREGISTER_SYN message and the encrypted message payload with the following operations:(40)macmsg=FH-MACREGISTER_SYN∥ecdhid∥uid∥pw∥hid,keymac(41)encmsg=Fe-AESuid∥pw∥hid∥macmsg,keyencThe user resets the operation timer forREGISTER_SYN and sends the message to the M2M server; thus,(42)<REGISTER_SYN,ecdh_id,encmsg>The M2M server parses the message and finds a related decryption key withecdh_id and checks whether the ECDH_ACK operation time is within an acceptable time range; if not and if ecdh_id is not found, then it destroys sensitive assets and terminates the operation. Otherwise, it decrypts the encrypted payload and verifies the MAC; thus,(43)uid∥pw∥hid∥macmsg=Fd-AESencmsg,keyenc(44)mac′msg=FH-MACREGISTER_SYN∥ecdhid∥uid∥pw∥hid,keymacIfmacmsg and mac′msg do not match, then the M2M server destroys sensitive assets and terminates the operation. Otherwise, it chooses a salt s. It also calculates 10 bytes of temporary ID (t_uid) for operations as follows:(45)t_uid=FH-MACuid,keyencThe M2M server calculates the password encryption key(keyAES) with SHA-1, as follows:(46)d=FSHA-1k∥t_uid∥s(47)keyAES=dnThe M2M server encrypts the user password (pw) with keyAES, as follows:(48)p=Fe-AESpw,keyAESThe M2M server calculates the temporary 10-byte home gateway ID (t_hid) for storage as follows:(49)t_hid=Fe-AEShid,keyencThe M2M server sets the user state (u_st) to REGISTERED and the home gateway state (h_st) to NONE.(50)u_st=REGISTERED(51)h_st=NONEAt the end of the operation, the M2M server stores the following parameters:(52)<t_uid,t_hid,s,p,sf,keyenc,keymac>After this operation, the M2M server prepares aREGISTER_ACK message MAC and an encrypted payload as follows:(53)macmsg=FH-MACREGISTER_ACK∥ecdh_id∥s,keymac(54)encmsg=Fe-AESs∥macmsg,keyencThe M2M resets the operation timer forREGISTER_ACK and sends it to the user; thus,(55)<REGISTER_ACK,ecdh_id,encmsg>The user device checks whether theREGISTER_SYN operation time is within an acceptable range; if not, then it destroys sensitive assets and terminates the operation. Otherwise, it decrypts the encrypted payload and verifies the MAC as follows:(56)s∥macmsg=Fd-AESencmsg,keyenc(57)mac′msg=FH-MACmsg=REGISTER_ACK∥ecdh_id∥s,keymacIfmac′msg and macmsg are not equal, then the user device destroys sensitive assets and terminates the operation. Otherwise, it stores s and commits keymac and keyenc storage for the next operations.


#### 5.5.5. Proposed Scheme for the User Login and Authentication Phase

The user device selects a randomx1 number and authentication parameters g and h1, as follows:(58)g=Fe-AESx1,pw(59)h1=FSHA-1x1According to user identifier privacy, the user calculatest_uid as follows:(60)t_uid=FH-MACuid,keyencThe user device prepares aLOGIN_SYN message MAC, as follows:(61)macmsg=FH-MACmsg=LOGIN_SYN∥t_uid∥g∥h1∥s,keymacThe user device resets the execution timer for theLOGIN_SYN message and transmits the message to the M2M server; thus,(62)<LOGIN_SYN,t_uid,g,h1,s,macmsg>The M2M server verifiest_uid and s, which are present in the database. If the record is not found, then the M2M server terminates the process. If the user is found but the state is LOCKED or not equal to REGISTERED, OFFLINE, and NEW_PASSWORD, then it ceases the operation. If all conditions are valid, then it verifies the LOGIN_SYN message MAC, as follows:(63)macmsg′=FH-MACLOGIN_SYN∥t_uid∥g∥h1∥s,keymacIf the messagemacmsg and calculated macmsg′ are equal, the computation of keyAES continues in order to verify h1. The M2M server calculates the password encryption key (keyAES) with SHA-1, as follows:(64)d=FSHA-1k∥t_uid∥s(65)keyAES=dn(66)pw′=Fd-AESp,keyAES(67)x′1=Fd-AESg,pw′(68)h′1=FSHA-1x′1If the receivedh1 and the calculated h1′ do not match, then the stored password is wrong and the M2M server terminates the operation; otherwise, the M2M server selects another random number x2 and calculates umk and h2, as follows:(69)umk=FSHA-1x′1∥x2n(70)h2=FSHA1umk∥midM2M server calculatesLOGIN_ACK message MAC as follows:(71)macmsg=FH-MACLOGIN_ACK∥mid∥x2∥h2∥s,keymacAfter this step, the M2M server resets the operation timer forLOGIN_ACK and sends the message to the user, as follows:(72)<LOGIN_ACK,mid,x2,h2,macmsg>The user checks whether theLOGIN_SYN operation time is an acceptable range. If not the operation is terminated; otherwise, it verifies the LOGIN_ACK message MAC, as follows:(73)mac′msg=FH-MACmsg=LOGIN_ACK∥mid∥x2∥h2∥s,keymacIf the calculatedmac′msg and received macmsg are not equal, then the action is terminated; otherwise, it verifies that h2 is received from the M2M server, as follows:(74)umk′=FSHA1x1∥x2n(75)h2′=FSHA1umk′∥midIf the receivedh2 value and calculated h2′ value are equal, then authentication is completed. After this point, the user device keeps umk′ for secure data transmission. Otherwise, the user device terminates the process. Until this step, the user verifies the M2M server and then calculates h3 for the M2M server mutual authentication, as follows:(76)h3=FSHA1umk′∥t_uidThe user device calculates theLOGIN_OK message MAC and sends the LOGIN_OK message to the M2M server, as follows:(77)macmsg=FH-MACLOGIN_OK∥h3,keymac(78)<LOGIN_OK,h3,macmsg>The M2M server checks whether theLOGIN_ACK operation time is in an acceptable time range; if not, then it terminates the operation. Otherwise, it verifies the LOGIN_OK message MAC, as follows:(79)mac′msg=FH-MACmsg=LOGIN_OK∥h3,keymacIf the calculatedmac′msg is equal to the received macmsg, then the M2M server verifies h3, as follows:(80)h′3=FSHA1umk∥t_uidIf the receivedh3 value and calculated h′3 value match, then authentication is completed. The M2M server sets the user state to ONLINE and keeps umk for secure data transmission.


#### 5.5.6. Proposed Scheme User Home Gateway Key Injection

A successfully registered user haskeyenc and keymac values. These keys are used to protect sensitive data transmissions between the home gateway device, M2M server, and mobile user device. In the current design [3], the home gateway device can connect a home network and sensors, which means these devices are capable of IP (Internet Protocol) network connections over WIFI or Ethernet. We assume that this device is connected to the home IP network and can be found by a mobile user device that is connected to the same network by searching over the home network. Without a home network, the home gateway device can set up a personal-private-network by using access point mode and allowing the user device to connect via prefabricated and marked information on the device. Additionally, this connection can be authenticated over Bluetooth capable home gateway devices.This personal-private-network provides a secure data transmission channel. The user sends keys to the home gateway device over this secure channel with aKEY_SYN message, as follows:(81)<KEY_SYN,keyenc∥keymac>The home gateway device stores thekeyenc and keymac values for the network join operation and returns the KEY_ACK message to the user device, as follows:(82)<KEY_ACK>After this message, the key injection is complete.


#### 5.5.7. Proposed Scheme Home Gateway Join Network

After the key injection operation, the home gateway device can securely join the network. The first home gateway device calculates the temporal home gateway ID (t_hid) from hid, as follows:(83)t_hid=FH-MAChid,keyencThe home gateway device prepares theJOIN_SYN message with MAC and resets the operation timer for this message and sends it to the M2M server, as follows:(84)macmsg=FH-MACJOIN_SYN∥t_hid,keymac(85)<JOIN_SYN,t_hid,macmsg>The M2M server searchest_hid in the database and attempts to obtain the detailed record. If the user-related device is not found, then the server terminates the operation. Otherwise, the M2M server obtains _uidu_st, h_st, s, keyenc, and keymac for the related operation. If the home gateway state (h_st) or user state (u_st) is LOCKED, or the home gateway state is already JOINED, then the server terminates the operation. Otherwise, the M2M server verifies the JOIN_SYN message MAC, as follows:(86)mac′msg=FH-MACJOIN_SYN∥t_hid,keymacIf the receivedmacmsg and the calculated mac′msg do not match, then the server terminates the operation. Otherwise, the server proceeds with the session key encryption. The M2M server calculates the session key, Hkey and the session key parameter Hp for the home gateway device, as follows:(87)Hp=FSHA1t_uid∥mid∥sm(88)Hkey=FSHA1t_hid∥HptThe M2M server storesHkey and prepares the JOIN_ACK message with MAC and the encrypted payload, as follows:(89)macmsg=FH-MACJOIN_ACK∥Hp,keymac(90)encmsg=Fe-AESHp∥macmsg,keyenc(91)<JOIN_ACK,encmsg>The home gateway device checks whether theJOIN_SYN operation time is valid; if not, then the device terminates the process. Otherwise, the device decrypts the JOIN_SYN message and verifies MAC, as follows:(92)Hp∥macmsg=Fd-AESencmsg,keyenc(93)mac′msg=FH-MACJOIN_ACK∥Hp,keymacIf the receivedmacmsg and calculated mac′msg do not match, then the home gateway device terminates the operation. Otherwise, the device calculates H′key and keeps it in memory for secure transmission, as follows:(94)Hkey′=FSHA1t_hid∥HptThe home gateway device prepares theJOIN_OK message for the M2M server with MAC, as follows:(95)macmsg=FH-MACJOIN_OK∥t_hid,keymac(96)<JOIN_OK,t_hid,macmsg>The M2M server checks whether theJOIN_ACK operation time is valid; if not, then it terminates the operation. Otherwise, it verifies JOIN_OK MAC and sets the home gateway state (h_st) to JOINED, as follows:(97)mac′msg=FH-MACJOIN_OK∥t_hid,keymacIf MAC verification has failed or a timeout occurs, andJOIN_OK is not received, then the M2M server terminates the operation.


#### 5.5.8. Proposed Scheme for the User Password Change

The user device calculatest_uid for the operation. It also prepares a PWD_SYN message with MAC and an encrypted payload, as follows:(98)t_uid=FH-MACuid,keyenc(99)macmsg=FH-MACPWD_SYN∥t_uid∥pw∥pw_new∥s,keymac(100)encmsg=Fe-AESpw∥pw_new∥s∥macmsg,keyencThe user resets the operation timer forPWD_SYN and sends the message to the M2M server, as follows:(101)<PWD_SYN,t_uid,encmsg>The M2M server acquires information fromt_uid and checks the status of the user. If the user state is LOCKED or not equal to ONLINE, then the M2M server terminates the operation. Otherwise, the M2M server acquires keys from the record and decrypts PWD_SYN and verifies the message MAC, as follows:(102)pw∥pw_new∥s∥macmsg=Fd-AESencmsg,keyenc(103)mac′msg=FH-MACPWD_SYN∥t_uid∥pw∥pw_new∥s,keymacIf the receivedmacmsg and calculated mac′msg do not match, then the M2M server terminates the operation. Otherwise, the M2M server calculates keyAES to verify whether the password is correct, as follows:(104)keyAES=FSHA1k∥t_uid∥sn(105)p′=Fe-AESpw,keyAESIf the storedp is not equal to p′, then the password verification fails and the M2M server terminates the operation. Otherwise, the M2M server selects a new salt snew and calculates a new key′AES. Finally, the M2M server encrypts the password for storage as follows:(106)key′AES=FSHA1k∥t_uid∥snewn(107)p′new=Fe-AESpw_new,key′AESThe M2M server storesp′new and prepares a PWD_ACK message with MAC and the encrypted payload. The prepared message is sent to the user device, as follows:(108)macmsg=FH-MACPWD_ACK∥snew,keymac(109)encmsg=Fe-AESsnew∥macmsg,keyenc(110)<PWD_ACK,encmsg>The user device checks whether thePWD_SYN operation time is inside the valid range. If not, it then sets fail_flag to true. If the execution time check fails, then the device skips MAC verification and sends PWD_NACK. Otherwise, the user device verifies PWD_ACK MAC, as follows:(111)snew∥macmsg=Fd-AESencmsg,keyenc(112)mac′msg=FH-MACPWD_ACK∥snew,keymacIf the receivedmacmsg and calculated mac′msg do not match, then the user device sets fail_flag to true and sends PWD_NACK to the M2M server, as follows:(113)macmsg=FH-MACPWD_NACK∥t_uid,keymac(114)<PWD_NACK,t_uid,macmsg>The M2M server verifiesPWD_NACK MAC. If MAC fails, then the server rejects the request. Otherwise, the server restores pnew to p and sets the user device state to the previous state. If fail_flag is not true, then the user stores s_new and preparesPWD_OK for the M2M server with MAC, as follows:(115)macmsg=FH-MACPWD_OK∥t_uid,keymac(116)<PWD_OK,t_uid,macmsg>The M2M server verifies thePWD_OK message MAC, as follows:(117)mac′msg=FH-MACPWD_OK∥t_uid,keymacIf the receivedmacmsg is equal to the calculated mac′msg, then the M2M server sets the user device state to NEW_PASSWORD and the home gateway device state to REVOKED. Otherwise, the server rejects the requests. The home gateway device key’s revocation is reported to the device with a RE_JOIN message by the M2M server, which calculates the RE_JOIN message with MAC and sends it to the home gateway device. When the home gateway device verifies the RE_JOIN message MAC, the home gateway device starts joining the flow again to refresh its session key; thus,(118)macmsg=FH-MACRE_JOIN∥t_hid,keymac(119)<RE_JOIN,macmsg>


#### 5.5.9. Proposed Scheme User Logout

User device safe logout for reliable operations is the most critical part. The user device calculates a temporary user ID (t_uid) and LOGOUT_SYN message with MAC for the M2M server, as follows:(120)macmsg=FH-MACLOGOUT_SYN∥t_uid,keymac(121)<LOGOUT_SYN,t_uid,macmsg>The userLOGOUT_SYN message is sent to the M2M server, as follows:(122)mac′msg=FH-MACLOGOUT_SYN∥t_uid,keymacThe M2M server finds the keys fromt_uid and calculates LOGOUT_SYNmac′msg and compares it with the received macmsg. If MAC does not match, then the M2M server rejects the operation. Otherwise, it sets the user device state to OFFLINE and prepares a LOGOUT_ACK message for the user device, as follows:(123)macmsg=FH-MACLOGOUT_ACK∥t_uid,keymac(124)<LOGOUT_ACK,t_uid,macmsg>When the user receivesLOGOUT_ACK, it verifies MAC, as follows:(125)mac′msg=FH-MACLOGOUT_ACK∥t_uid,keymacIf the receivedmacmsg and calculated mac′msg match, then the user device updates its state to the OFFLINE case. Otherwise, it rejects the request.


#### 5.5.10. Home Gateway Rejoin Network

This operation is processed after the password change operation. The M2M server sets the home gateway device state toREVOKED and prepares the RE_JOIN message for the home gateway device, as follows:(126)macmsg=FH-MACRE_JOIN∥t_hid,keymac(127)<RE_JOIN,macmsg>The home gateway device calculatest_hid and verifies RE_JOIN MAC. If MAC verifies it, then the home gateway device processes the home gateway join network flow.


## 5.1. Message Modification Protection with Shortened MAC

Our first contribution to the design [3] is providing message modification protection. Scheme [3] messages are modifiable during transmission. There is no MAC verification security. Moreover, the MAC calculator source must be verified by the receiver. For this reason, we opted to use keyed MAC algorithms such as C-MAC (Cipher-based MAC) [24] or H-MAC (the Keyed-Hash Message Authentication Code) [25] based on DES (Data Encryption Standard) or AES. This protection method was performed in [6]. According to performance and resource restrictions, we have decided to use a shortened MAC as described in the PBA scheme [26] to confirm messages. Moreover, the GLARM scheme [2] uses the MAC algorithm specified in [27]. We used an H-MAC based truncated MAC algorithm that has a similar offset selection to HOTP (HMAC-Based One-Time-Password), as explained in [28].Each request and response in a public channel is protected with MAC and if MAC confirmation fails; then the request is terminated by the receiver entity.We simulated and measured the performance of the H-MAC configuration for SHA-256 (Secure HashAlgorithm 256) and SHA-1 with 16-byte and 8-byte keys, as shown in Table 6.Table 6
Truncated MAC calculation performances.
Algorithm Measurement Mean (sn) Measurement Std. (sn) H-MAC-SHA256 16 bytes key 0.000273 0.000094 H-MAC-SHA1 16 bytes key 0.000268 0.000189 H-MAC-SHA256 8 bytes key 0.000267 0.000109 H-MAC-SHA1 8 bytes key 0.000283 0.000134 ISO9797-ALGO-3 16 bytes key 0.000392 0.000226


## 5.2. Privacy-Preserving with Temporal ID

The second contribution to the scheme is replacing the original user ID with a temporary ID to provide privacy-preserving as stated in the GLARM scheme [2]. The GLARM scheme uses a preshared key to derive the ID and temporal ID used in all procedures. Scheme [3] focuses on privacy security, but, during registration and password change phases, they transferred the password and user ID in an open format. Additionally, the original user ID is always posted in the open format for all stages. Therefore, privacy security has a significant problem in scheme [3] and it does not guarantee anonymity.In our scheme, we have a robust method to solve this problem, namely, ECDH key pairing during registration. Key pairing requests are distinguished by the user ECDH key pairing identifier (ecdh_id). This ecdh_id value is calculated from the user ID (uid) with a trimmed SHA-1 during the user setup phase; thus,(23)ecdh_id=FSHA-1uidnThe user sends the public key (pubuser) to the M2M server during the registration stage with ecdh_id and uid is never revealed, as follows:(24)<ECD_SYN,ecdh_id,pubuser>M2M server uses its private key (privm2m) and receives the public key (pubuser) to derive encryption key (keyECDH). For ECDH secure key establishment is as follows:(25)keyECDH=Fs-ECDHpubuser,privm2mThe M2M server encrypts integrity and confidentiality keys withkeyECDH. These encrypted keys and the M2M server public key (pubm2m) are sent to the user device in the same message to decrease the request size in the proposed scheme; thus,(26)Enckeyenc∥keymac=Fe-ECDHkeyenc∥keymac,keyECDH(27)<ECDH_ACK,ecdh_id,pubm2m,Enckeyenc∥keymac>The user receives the public key and derives the ECDH encryption key to decrypt the encrypted keys. After revealing the keys, the user device prepares the registration message (REGISTER_SYN) by calculating the registration message MAC and encrypting the user ID (uid), password (pw), and home gateway ID (hid) with a confidentiality key to be sent with ecdh_id, as follows:(28)macmsg=FH-MACREGISTER_SYN∥ecdhid∥uid∥pw∥hid,keymac(29)encmsg=Fe-AESuid∥pw∥hid∥macmsg,keyenc(30)<REGISTER_SYN,ecdh_id,encmsg>The problem in [3] is that REGISTER_SYN is a similar request message containing sensitive assets in open format. However, we protect these sensitive assets with encryption and MAC. When the M2M server receives encrypted values with the REGISTER_SYN message, then it is decrypted with keyECDH and acquires the clear user ID, after which it calculates a temporary ID with a H-MAC based truncated MAC algorithm by using an integrity key. The output length of this algorithm is the same as the original ID length. The temporary ID generation operation is also is also identically performed in the user device and the next requests are performed using the temporary ID to protect user privacy in the network. An H-MAC based truncated MAC algorithm is typically resistant to brute-force attacks. In addition, ECDH key pairing provides a defense against MITM attacks, and MAC protects messages from modification. These listed protection methods are not provided by scheme [3].


## 5.3. Forward and Backward Secrecy Improvement

The third participation pertains to the improvement of secrecy. MAC and temporal ID operations are enhanced with H-MAC methods. We used protection keys encapsulated with ECDH keys to provide forward and backward secrecy improvement.Scheme [3] registration and password change phases are not protected; however, we protect every step that we proposed. Our scheme follows general standard algorithms such as ECDH, Trimmed H-MAC, and AES. These algorithms, which are used to protect sensitive assets during communication, are resistant to brute-force attacks.


## 5.4. Reliable Operation Processing and State Management

The fourth contribution pertains to service reliability. Scheme [3] does not include the operation plus message timeout, message acknowledgment segment, and message identifier segment. Moreover, the user and home gateway state management are poor. There is only one bit to keep user state online or offline.We have provided a timeout measurement with an internal device clock without a timestamp. This kind of usage does not require an internal RTC (real-time clock) module for devices. If a timeout occurs during transmission, then entities can terminate or resend requests. Additionally, this timeout measurement can be used to detect eavesdropping attacks by checking operation processing times that are used by the timeout control. Each message is identified with a one-byte tag. Entities can evaluate requests with this identifier. The proposed scheme message identifiers are listed in Table7.Table 7
Proposed scheme message identifiers.
Message Name Message Phase Message Sender Message Receiver ECDH_SYN User Registration and Key Pair User M2M Server  ECDH_ACK User Registration and Key Pair M2M Server User  REGISTER_SYN User Registration and Key Pair User M2M Server  REGISTER_ACK User Registration and Key Pair M2M Server User  KEY_SYN User Home User Home Gateway Gateway Key Injection  KEY_ACK User Home Home Gateway User Gateway Key Injection  JOIN_SYN Home gateway Join Home Gateway M2M Server Network  JOIN_ACK Home gateway Join M2M Server Home Gateway Network  JOIN_OK Home gateway Join Home Gateway M2M Server Network  LOGIN_SYN User Login and Authentication User M2M Server  LOGIN_ACK User Login and Authentication M2M Server User  LOGIN_OK User Login and Authentication User M2M Server  PWD_SYN User Change User M2M Server Password  RE_JOIN User Change M2M Server Home Gateway Password  PWD_ACK User Change M2M Server User Password  PWD_NACK User Change User M2M Server Password  PWD_OK User Change User M2M Server Password  LOGOUT_SYN M2MServer User User M2M Server Logout  LOGOUT_ACK M2MServer User M2M Server User LogoutAdditionally, we have updated the state of the machines for the current design. Enhanced states in the proposed protocol are shown in Figures5 and 6.Figure 5
User state processing.Figure 6
Home gateway state processing.


## 5.5. Proposed Scheme Phases

Our proposed scheme consists of ten phases. We designed a practically good system in the real network and we assumed that there was no secure communication network over the public channel. Moreover, in our scheme, the home gateway devices and user devices have WIFI connection capability via the private home network. We added ECDH key sharing between the user device and the M2M server. This operation was consolidated with user registration. Additionally, we added one more phase according to the current scheme for key injection to the home gateway device, and the user logout operation was also defined in the proposed protocol.


### 5.5.1. Proposed Scheme M2M Server Setup

During the setup operation, the M2M server generates ECDHpubm2m and privm2m key pairs, as follows:(31)pubm2m,privm2m=Fi-ECDHThe generated public key length is 576 bits, and the private key length is 832 bits. Moreover, the M2M server selects a 64-bit server secret key (k), which is mentioned in scheme [3]. During the setup phase, there must be single 80-bit M2M server ID (mid) personalized to the smart card to define the M2M server in the network. The server can communicate with the smart cards.


### 5.5.2. Proposed Scheme Home Gateway Setup

During the setup operation, the home gateway device is uniquely identified with an 80-bit ID (hid) and is personalized to a smartcard which is deployed with the home gateway device.


### 5.5.3. Proposed Scheme User Setup

During the setup operation, users uniquely identified with an 80-bit ID (uid), which is stored on the smart card. In addition, for registration, the key pair’s user device generates ECDH pubm2m and privm2m key pair, as follows:(32)pubuser,privuser=Fi-ECDHA temporal 80-bitecdh_id is used for only key pairing that is generated in this phase with the following operation:(33)ecdh_id=FSHA-1uidnThe generated public key length is 576 bits, and the private key length is 832 bits. Additionally, the user should define the 64-bit password (pw) and 80-bis home gateway id (hid) for the registrations.


### 5.5.4. Proposed Scheme User Registration and Key Pairing

The user resets the operation timer for theECDH_SYN message sending operation and sends the ECDH_SYN message to the M2M server for registration, as follows:(34)<ECD_SYN,ecdh_id,pubuser>The M2M server deriveskeyECDH with pubuser and its own privm2m to use as a transport key; thus,(35)keyECDH=Fs-ECDHpubuser,privm2mThe M2M server generates a 16-bytekeyenc and keymac for secure transmission. These keys are securely transported under keyECDH between the entities, as follows:(36)Enckeyenc∥keymac=Fe-ECDHkeyenc∥keymac,keyECDHThe M2M server resets the operation timer for theECDH_ACK message sending operation and sends the ECDH_ACK message to the user for the key pair, as follows:(37)<ECDH_ACK,ecdh_id,pubm2m,Enckeyenc∥keymac>The user device checks whether theECDH_SYN operation time is within an acceptable time range; if not, then it destroys sensitive assets and terminates the operation; otherwise, it derives keyECDH as follows:(38)keyECDH=Fs-ECDHpubm2m,privuserThe user device decryptsEnckeyenc∥keymac with keyECDH and keeps keyenc∥keymac in temporary memory. At the end of this operation, the M2M server completes user key pairing, and the MAC keys are securely shared for sensitive operations, as follows:(39)keyenc∥keymac=Fd-ECDHEnckeyenc∥keymac,keyECDHAfter key pairing registration data sending, the user registration operation starts from the user side. The user device prepares the MAC of theREGISTER_SYN message and the encrypted message payload with the following operations:(40)macmsg=FH-MACREGISTER_SYN∥ecdhid∥uid∥pw∥hid,keymac(41)encmsg=Fe-AESuid∥pw∥hid∥macmsg,keyencThe user resets the operation timer forREGISTER_SYN and sends the message to the M2M server; thus,(42)<REGISTER_SYN,ecdh_id,encmsg>The M2M server parses the message and finds a related decryption key withecdh_id and checks whether the ECDH_ACK operation time is within an acceptable time range; if not and if ecdh_id is not found, then it destroys sensitive assets and terminates the operation. Otherwise, it decrypts the encrypted payload and verifies the MAC; thus,(43)uid∥pw∥hid∥macmsg=Fd-AESencmsg,keyenc(44)mac′msg=FH-MACREGISTER_SYN∥ecdhid∥uid∥pw∥hid,keymacIfmacmsg and mac′msg do not match, then the M2M server destroys sensitive assets and terminates the operation. Otherwise, it chooses a salt s. It also calculates 10 bytes of temporary ID (t_uid) for operations as follows:(45)t_uid=FH-MACuid,keyencThe M2M server calculates the password encryption key(keyAES) with SHA-1, as follows:(46)d=FSHA-1k∥t_uid∥s(47)keyAES=dnThe M2M server encrypts the user password (pw) with keyAES, as follows:(48)p=Fe-AESpw,keyAESThe M2M server calculates the temporary 10-byte home gateway ID (t_hid) for storage as follows:(49)t_hid=Fe-AEShid,keyencThe M2M server sets the user state (u_st) to REGISTERED and the home gateway state (h_st) to NONE.(50)u_st=REGISTERED(51)h_st=NONEAt the end of the operation, the M2M server stores the following parameters:(52)<t_uid,t_hid,s,p,sf,keyenc,keymac>After this operation, the M2M server prepares aREGISTER_ACK message MAC and an encrypted payload as follows:(53)macmsg=FH-MACREGISTER_ACK∥ecdh_id∥s,keymac(54)encmsg=Fe-AESs∥macmsg,keyencThe M2M resets the operation timer forREGISTER_ACK and sends it to the user; thus,(55)<REGISTER_ACK,ecdh_id,encmsg>The user device checks whether theREGISTER_SYN operation time is within an acceptable range; if not, then it destroys sensitive assets and terminates the operation. Otherwise, it decrypts the encrypted payload and verifies the MAC as follows:(56)s∥macmsg=Fd-AESencmsg,keyenc(57)mac′msg=FH-MACmsg=REGISTER_ACK∥ecdh_id∥s,keymacIfmac′msg and macmsg are not equal, then the user device destroys sensitive assets and terminates the operation. Otherwise, it stores s and commits keymac and keyenc storage for the next operations.


### 5.5.5. Proposed Scheme for the User Login and Authentication Phase

The user device selects a randomx1 number and authentication parameters g and h1, as follows:(58)g=Fe-AESx1,pw(59)h1=FSHA-1x1According to user identifier privacy, the user calculatest_uid as follows:(60)t_uid=FH-MACuid,keyencThe user device prepares aLOGIN_SYN message MAC, as follows:(61)macmsg=FH-MACmsg=LOGIN_SYN∥t_uid∥g∥h1∥s,keymacThe user device resets the execution timer for theLOGIN_SYN message and transmits the message to the M2M server; thus,(62)<LOGIN_SYN,t_uid,g,h1,s,macmsg>The M2M server verifiest_uid and s, which are present in the database. If the record is not found, then the M2M server terminates the process. If the user is found but the state is LOCKED or not equal to REGISTERED, OFFLINE, and NEW_PASSWORD, then it ceases the operation. If all conditions are valid, then it verifies the LOGIN_SYN message MAC, as follows:(63)macmsg′=FH-MACLOGIN_SYN∥t_uid∥g∥h1∥s,keymacIf the messagemacmsg and calculated macmsg′ are equal, the computation of keyAES continues in order to verify h1. The M2M server calculates the password encryption key (keyAES) with SHA-1, as follows:(64)d=FSHA-1k∥t_uid∥s(65)keyAES=dn(66)pw′=Fd-AESp,keyAES(67)x′1=Fd-AESg,pw′(68)h′1=FSHA-1x′1If the receivedh1 and the calculated h1′ do not match, then the stored password is wrong and the M2M server terminates the operation; otherwise, the M2M server selects another random number x2 and calculates umk and h2, as follows:(69)umk=FSHA-1x′1∥x2n(70)h2=FSHA1umk∥midM2M server calculatesLOGIN_ACK message MAC as follows:(71)macmsg=FH-MACLOGIN_ACK∥mid∥x2∥h2∥s,keymacAfter this step, the M2M server resets the operation timer forLOGIN_ACK and sends the message to the user, as follows:(72)<LOGIN_ACK,mid,x2,h2,macmsg>The user checks whether theLOGIN_SYN operation time is an acceptable range. If not the operation is terminated; otherwise, it verifies the LOGIN_ACK message MAC, as follows:(73)mac′msg=FH-MACmsg=LOGIN_ACK∥mid∥x2∥h2∥s,keymacIf the calculatedmac′msg and received macmsg are not equal, then the action is terminated; otherwise, it verifies that h2 is received from the M2M server, as follows:(74)umk′=FSHA1x1∥x2n(75)h2′=FSHA1umk′∥midIf the receivedh2 value and calculated h2′ value are equal, then authentication is completed. After this point, the user device keeps umk′ for secure data transmission. Otherwise, the user device terminates the process. Until this step, the user verifies the M2M server and then calculates h3 for the M2M server mutual authentication, as follows:(76)h3=FSHA1umk′∥t_uidThe user device calculates theLOGIN_OK message MAC and sends the LOGIN_OK message to the M2M server, as follows:(77)macmsg=FH-MACLOGIN_OK∥h3,keymac(78)<LOGIN_OK,h3,macmsg>The M2M server checks whether theLOGIN_ACK operation time is in an acceptable time range; if not, then it terminates the operation. Otherwise, it verifies the LOGIN_OK message MAC, as follows:(79)mac′msg=FH-MACmsg=LOGIN_OK∥h3,keymacIf the calculatedmac′msg is equal to the received macmsg, then the M2M server verifies h3, as follows:(80)h′3=FSHA1umk∥t_uidIf the receivedh3 value and calculated h′3 value match, then authentication is completed. The M2M server sets the user state to ONLINE and keeps umk for secure data transmission.


### 5.5.6. Proposed Scheme User Home Gateway Key Injection

A successfully registered user haskeyenc and keymac values. These keys are used to protect sensitive data transmissions between the home gateway device, M2M server, and mobile user device. In the current design [3], the home gateway device can connect a home network and sensors, which means these devices are capable of IP (Internet Protocol) network connections over WIFI or Ethernet. We assume that this device is connected to the home IP network and can be found by a mobile user device that is connected to the same network by searching over the home network. Without a home network, the home gateway device can set up a personal-private-network by using access point mode and allowing the user device to connect via prefabricated and marked information on the device. Additionally, this connection can be authenticated over Bluetooth capable home gateway devices.This personal-private-network provides a secure data transmission channel. The user sends keys to the home gateway device over this secure channel with aKEY_SYN message, as follows:(81)<KEY_SYN,keyenc∥keymac>The home gateway device stores thekeyenc and keymac values for the network join operation and returns the KEY_ACK message to the user device, as follows:(82)<KEY_ACK>After this message, the key injection is complete.


### 5.5.7. Proposed Scheme Home Gateway Join Network

After the key injection operation, the home gateway device can securely join the network. The first home gateway device calculates the temporal home gateway ID (t_hid) from hid, as follows:(83)t_hid=FH-MAChid,keyencThe home gateway device prepares theJOIN_SYN message with MAC and resets the operation timer for this message and sends it to the M2M server, as follows:(84)macmsg=FH-MACJOIN_SYN∥t_hid,keymac(85)<JOIN_SYN,t_hid,macmsg>The M2M server searchest_hid in the database and attempts to obtain the detailed record. If the user-related device is not found, then the server terminates the operation. Otherwise, the M2M server obtains _uidu_st, h_st, s, keyenc, and keymac for the related operation. If the home gateway state (h_st) or user state (u_st) is LOCKED, or the home gateway state is already JOINED, then the server terminates the operation. Otherwise, the M2M server verifies the JOIN_SYN message MAC, as follows:(86)mac′msg=FH-MACJOIN_SYN∥t_hid,keymacIf the receivedmacmsg and the calculated mac′msg do not match, then the server terminates the operation. Otherwise, the server proceeds with the session key encryption. The M2M server calculates the session key, Hkey and the session key parameter Hp for the home gateway device, as follows:(87)Hp=FSHA1t_uid∥mid∥sm(88)Hkey=FSHA1t_hid∥HptThe M2M server storesHkey and prepares the JOIN_ACK message with MAC and the encrypted payload, as follows:(89)macmsg=FH-MACJOIN_ACK∥Hp,keymac(90)encmsg=Fe-AESHp∥macmsg,keyenc(91)<JOIN_ACK,encmsg>The home gateway device checks whether theJOIN_SYN operation time is valid; if not, then the device terminates the process. Otherwise, the device decrypts the JOIN_SYN message and verifies MAC, as follows:(92)Hp∥macmsg=Fd-AESencmsg,keyenc(93)mac′msg=FH-MACJOIN_ACK∥Hp,keymacIf the receivedmacmsg and calculated mac′msg do not match, then the home gateway device terminates the operation. Otherwise, the device calculates H′key and keeps it in memory for secure transmission, as follows:(94)Hkey′=FSHA1t_hid∥HptThe home gateway device prepares theJOIN_OK message for the M2M server with MAC, as follows:(95)macmsg=FH-MACJOIN_OK∥t_hid,keymac(96)<JOIN_OK,t_hid,macmsg>The M2M server checks whether theJOIN_ACK operation time is valid; if not, then it terminates the operation. Otherwise, it verifies JOIN_OK MAC and sets the home gateway state (h_st) to JOINED, as follows:(97)mac′msg=FH-MACJOIN_OK∥t_hid,keymacIf MAC verification has failed or a timeout occurs, andJOIN_OK is not received, then the M2M server terminates the operation.


### 5.5.8. Proposed Scheme for the User Password Change

The user device calculatest_uid for the operation. It also prepares a PWD_SYN message with MAC and an encrypted payload, as follows:(98)t_uid=FH-MACuid,keyenc(99)macmsg=FH-MACPWD_SYN∥t_uid∥pw∥pw_new∥s,keymac(100)encmsg=Fe-AESpw∥pw_new∥s∥macmsg,keyencThe user resets the operation timer forPWD_SYN and sends the message to the M2M server, as follows:(101)<PWD_SYN,t_uid,encmsg>The M2M server acquires information fromt_uid and checks the status of the user. If the user state is LOCKED or not equal to ONLINE, then the M2M server terminates the operation. Otherwise, the M2M server acquires keys from the record and decrypts PWD_SYN and verifies the message MAC, as follows:(102)pw∥pw_new∥s∥macmsg=Fd-AESencmsg,keyenc(103)mac′msg=FH-MACPWD_SYN∥t_uid∥pw∥pw_new∥s,keymacIf the receivedmacmsg and calculated mac′msg do not match, then the M2M server terminates the operation. Otherwise, the M2M server calculates keyAES to verify whether the password is correct, as follows:(104)keyAES=FSHA1k∥t_uid∥sn(105)p′=Fe-AESpw,keyAESIf the storedp is not equal to p′, then the password verification fails and the M2M server terminates the operation. Otherwise, the M2M server selects a new salt snew and calculates a new key′AES. Finally, the M2M server encrypts the password for storage as follows:(106)key′AES=FSHA1k∥t_uid∥snewn(107)p′new=Fe-AESpw_new,key′AESThe M2M server storesp′new and prepares a PWD_ACK message with MAC and the encrypted payload. The prepared message is sent to the user device, as follows:(108)macmsg=FH-MACPWD_ACK∥snew,keymac(109)encmsg=Fe-AESsnew∥macmsg,keyenc(110)<PWD_ACK,encmsg>The user device checks whether thePWD_SYN operation time is inside the valid range. If not, it then sets fail_flag to true. If the execution time check fails, then the device skips MAC verification and sends PWD_NACK. Otherwise, the user device verifies PWD_ACK MAC, as follows:(111)snew∥macmsg=Fd-AESencmsg,keyenc(112)mac′msg=FH-MACPWD_ACK∥snew,keymacIf the receivedmacmsg and calculated mac′msg do not match, then the user device sets fail_flag to true and sends PWD_NACK to the M2M server, as follows:(113)macmsg=FH-MACPWD_NACK∥t_uid,keymac(114)<PWD_NACK,t_uid,macmsg>The M2M server verifiesPWD_NACK MAC. If MAC fails, then the server rejects the request. Otherwise, the server restores pnew to p and sets the user device state to the previous state. If fail_flag is not true, then the user stores s_new and preparesPWD_OK for the M2M server with MAC, as follows:(115)macmsg=FH-MACPWD_OK∥t_uid,keymac(116)<PWD_OK,t_uid,macmsg>The M2M server verifies thePWD_OK message MAC, as follows:(117)mac′msg=FH-MACPWD_OK∥t_uid,keymacIf the receivedmacmsg is equal to the calculated mac′msg, then the M2M server sets the user device state to NEW_PASSWORD and the home gateway device state to REVOKED. Otherwise, the server rejects the requests. The home gateway device key’s revocation is reported to the device with a RE_JOIN message by the M2M server, which calculates the RE_JOIN message with MAC and sends it to the home gateway device. When the home gateway device verifies the RE_JOIN message MAC, the home gateway device starts joining the flow again to refresh its session key; thus,(118)macmsg=FH-MACRE_JOIN∥t_hid,keymac(119)<RE_JOIN,macmsg>


### 5.5.9. Proposed Scheme User Logout

User device safe logout for reliable operations is the most critical part. The user device calculates a temporary user ID (t_uid) and LOGOUT_SYN message with MAC for the M2M server, as follows:(120)macmsg=FH-MACLOGOUT_SYN∥t_uid,keymac(121)<LOGOUT_SYN,t_uid,macmsg>The userLOGOUT_SYN message is sent to the M2M server, as follows:(122)mac′msg=FH-MACLOGOUT_SYN∥t_uid,keymacThe M2M server finds the keys fromt_uid and calculates LOGOUT_SYNmac′msg and compares it with the received macmsg. If MAC does not match, then the M2M server rejects the operation. Otherwise, it sets the user device state to OFFLINE and prepares a LOGOUT_ACK message for the user device, as follows:(123)macmsg=FH-MACLOGOUT_ACK∥t_uid,keymac(124)<LOGOUT_ACK,t_uid,macmsg>When the user receivesLOGOUT_ACK, it verifies MAC, as follows:(125)mac′msg=FH-MACLOGOUT_ACK∥t_uid,keymacIf the receivedmacmsg and calculated mac′msg match, then the user device updates its state to the OFFLINE case. Otherwise, it rejects the request.


### 5.5.10. Home Gateway Rejoin Network

This operation is processed after the password change operation. The M2M server sets the home gateway device state toREVOKED and prepares the RE_JOIN message for the home gateway device, as follows:(126)macmsg=FH-MACRE_JOIN∥t_hid,keymac(127)<RE_JOIN,macmsg>The home gateway device calculatest_hid and verifies RE_JOIN MAC. If MAC verifies it, then the home gateway device processes the home gateway join network flow.


## 5.5.1. Proposed Scheme M2M Server Setup

During the setup operation, the M2M server generates ECDHpubm2m and privm2m key pairs, as follows:(31)pubm2m,privm2m=Fi-ECDHThe generated public key length is 576 bits, and the private key length is 832 bits. Moreover, the M2M server selects a 64-bit server secret key (k), which is mentioned in scheme [3]. During the setup phase, there must be single 80-bit M2M server ID (mid) personalized to the smart card to define the M2M server in the network. The server can communicate with the smart cards.


## 5.5.2. Proposed Scheme Home Gateway Setup

During the setup operation, the home gateway device is uniquely identified with an 80-bit ID (hid) and is personalized to a smartcard which is deployed with the home gateway device.


## 5.5.3. Proposed Scheme User Setup

During the setup operation, users uniquely identified with an 80-bit ID (uid), which is stored on the smart card. In addition, for registration, the key pair’s user device generates ECDH pubm2m and privm2m key pair, as follows:(32)pubuser,privuser=Fi-ECDHA temporal 80-bitecdh_id is used for only key pairing that is generated in this phase with the following operation:(33)ecdh_id=FSHA-1uidnThe generated public key length is 576 bits, and the private key length is 832 bits. Additionally, the user should define the 64-bit password (pw) and 80-bis home gateway id (hid) for the registrations.


## 5.5.4. Proposed Scheme User Registration and Key Pairing

The user resets the operation timer for theECDH_SYN message sending operation and sends the ECDH_SYN message to the M2M server for registration, as follows:(34)<ECD_SYN,ecdh_id,pubuser>The M2M server deriveskeyECDH with pubuser and its own privm2m to use as a transport key; thus,(35)keyECDH=Fs-ECDHpubuser,privm2mThe M2M server generates a 16-bytekeyenc and keymac for secure transmission. These keys are securely transported under keyECDH between the entities, as follows:(36)Enckeyenc∥keymac=Fe-ECDHkeyenc∥keymac,keyECDHThe M2M server resets the operation timer for theECDH_ACK message sending operation and sends the ECDH_ACK message to the user for the key pair, as follows:(37)<ECDH_ACK,ecdh_id,pubm2m,Enckeyenc∥keymac>The user device checks whether theECDH_SYN operation time is within an acceptable time range; if not, then it destroys sensitive assets and terminates the operation; otherwise, it derives keyECDH as follows:(38)keyECDH=Fs-ECDHpubm2m,privuserThe user device decryptsEnckeyenc∥keymac with keyECDH and keeps keyenc∥keymac in temporary memory. At the end of this operation, the M2M server completes user key pairing, and the MAC keys are securely shared for sensitive operations, as follows:(39)keyenc∥keymac=Fd-ECDHEnckeyenc∥keymac,keyECDHAfter key pairing registration data sending, the user registration operation starts from the user side. The user device prepares the MAC of theREGISTER_SYN message and the encrypted message payload with the following operations:(40)macmsg=FH-MACREGISTER_SYN∥ecdhid∥uid∥pw∥hid,keymac(41)encmsg=Fe-AESuid∥pw∥hid∥macmsg,keyencThe user resets the operation timer forREGISTER_SYN and sends the message to the M2M server; thus,(42)<REGISTER_SYN,ecdh_id,encmsg>The M2M server parses the message and finds a related decryption key withecdh_id and checks whether the ECDH_ACK operation time is within an acceptable time range; if not and if ecdh_id is not found, then it destroys sensitive assets and terminates the operation. Otherwise, it decrypts the encrypted payload and verifies the MAC; thus,(43)uid∥pw∥hid∥macmsg=Fd-AESencmsg,keyenc(44)mac′msg=FH-MACREGISTER_SYN∥ecdhid∥uid∥pw∥hid,keymacIfmacmsg and mac′msg do not match, then the M2M server destroys sensitive assets and terminates the operation. Otherwise, it chooses a salt s. It also calculates 10 bytes of temporary ID (t_uid) for operations as follows:(45)t_uid=FH-MACuid,keyencThe M2M server calculates the password encryption key(keyAES) with SHA-1, as follows:(46)d=FSHA-1k∥t_uid∥s(47)keyAES=dnThe M2M server encrypts the user password (pw) with keyAES, as follows:(48)p=Fe-AESpw,keyAESThe M2M server calculates the temporary 10-byte home gateway ID (t_hid) for storage as follows:(49)t_hid=Fe-AEShid,keyencThe M2M server sets the user state (u_st) to REGISTERED and the home gateway state (h_st) to NONE.(50)u_st=REGISTERED(51)h_st=NONEAt the end of the operation, the M2M server stores the following parameters:(52)<t_uid,t_hid,s,p,sf,keyenc,keymac>After this operation, the M2M server prepares aREGISTER_ACK message MAC and an encrypted payload as follows:(53)macmsg=FH-MACREGISTER_ACK∥ecdh_id∥s,keymac(54)encmsg=Fe-AESs∥macmsg,keyencThe M2M resets the operation timer forREGISTER_ACK and sends it to the user; thus,(55)<REGISTER_ACK,ecdh_id,encmsg>The user device checks whether theREGISTER_SYN operation time is within an acceptable range; if not, then it destroys sensitive assets and terminates the operation. Otherwise, it decrypts the encrypted payload and verifies the MAC as follows:(56)s∥macmsg=Fd-AESencmsg,keyenc(57)mac′msg=FH-MACmsg=REGISTER_ACK∥ecdh_id∥s,keymacIfmac′msg and macmsg are not equal, then the user device destroys sensitive assets and terminates the operation. Otherwise, it stores s and commits keymac and keyenc storage for the next operations.


## 5.5.5. Proposed Scheme for the User Login and Authentication Phase

The user device selects a randomx1 number and authentication parameters g and h1, as follows:(58)g=Fe-AESx1,pw(59)h1=FSHA-1x1According to user identifier privacy, the user calculatest_uid as follows:(60)t_uid=FH-MACuid,keyencThe user device prepares aLOGIN_SYN message MAC, as follows:(61)macmsg=FH-MACmsg=LOGIN_SYN∥t_uid∥g∥h1∥s,keymacThe user device resets the execution timer for theLOGIN_SYN message and transmits the message to the M2M server; thus,(62)<LOGIN_SYN,t_uid,g,h1,s,macmsg>The M2M server verifiest_uid and s, which are present in the database. If the record is not found, then the M2M server terminates the process. If the user is found but the state is LOCKED or not equal to REGISTERED, OFFLINE, and NEW_PASSWORD, then it ceases the operation. If all conditions are valid, then it verifies the LOGIN_SYN message MAC, as follows:(63)macmsg′=FH-MACLOGIN_SYN∥t_uid∥g∥h1∥s,keymacIf the messagemacmsg and calculated macmsg′ are equal, the computation of keyAES continues in order to verify h1. The M2M server calculates the password encryption key (keyAES) with SHA-1, as follows:(64)d=FSHA-1k∥t_uid∥s(65)keyAES=dn(66)pw′=Fd-AESp,keyAES(67)x′1=Fd-AESg,pw′(68)h′1=FSHA-1x′1If the receivedh1 and the calculated h1′ do not match, then the stored password is wrong and the M2M server terminates the operation; otherwise, the M2M server selects another random number x2 and calculates umk and h2, as follows:(69)umk=FSHA-1x′1∥x2n(70)h2=FSHA1umk∥midM2M server calculatesLOGIN_ACK message MAC as follows:(71)macmsg=FH-MACLOGIN_ACK∥mid∥x2∥h2∥s,keymacAfter this step, the M2M server resets the operation timer forLOGIN_ACK and sends the message to the user, as follows:(72)<LOGIN_ACK,mid,x2,h2,macmsg>The user checks whether theLOGIN_SYN operation time is an acceptable range. If not the operation is terminated; otherwise, it verifies the LOGIN_ACK message MAC, as follows:(73)mac′msg=FH-MACmsg=LOGIN_ACK∥mid∥x2∥h2∥s,keymacIf the calculatedmac′msg and received macmsg are not equal, then the action is terminated; otherwise, it verifies that h2 is received from the M2M server, as follows:(74)umk′=FSHA1x1∥x2n(75)h2′=FSHA1umk′∥midIf the receivedh2 value and calculated h2′ value are equal, then authentication is completed. After this point, the user device keeps umk′ for secure data transmission. Otherwise, the user device terminates the process. Until this step, the user verifies the M2M server and then calculates h3 for the M2M server mutual authentication, as follows:(76)h3=FSHA1umk′∥t_uidThe user device calculates theLOGIN_OK message MAC and sends the LOGIN_OK message to the M2M server, as follows:(77)macmsg=FH-MACLOGIN_OK∥h3,keymac(78)<LOGIN_OK,h3,macmsg>The M2M server checks whether theLOGIN_ACK operation time is in an acceptable time range; if not, then it terminates the operation. Otherwise, it verifies the LOGIN_OK message MAC, as follows:(79)mac′msg=FH-MACmsg=LOGIN_OK∥h3,keymacIf the calculatedmac′msg is equal to the received macmsg, then the M2M server verifies h3, as follows:(80)h′3=FSHA1umk∥t_uidIf the receivedh3 value and calculated h′3 value match, then authentication is completed. The M2M server sets the user state to ONLINE and keeps umk for secure data transmission.


## 5.5.6. Proposed Scheme User Home Gateway Key Injection

A successfully registered user haskeyenc and keymac values. These keys are used to protect sensitive data transmissions between the home gateway device, M2M server, and mobile user device. In the current design [3], the home gateway device can connect a home network and sensors, which means these devices are capable of IP (Internet Protocol) network connections over WIFI or Ethernet. We assume that this device is connected to the home IP network and can be found by a mobile user device that is connected to the same network by searching over the home network. Without a home network, the home gateway device can set up a personal-private-network by using access point mode and allowing the user device to connect via prefabricated and marked information on the device. Additionally, this connection can be authenticated over Bluetooth capable home gateway devices.This personal-private-network provides a secure data transmission channel. The user sends keys to the home gateway device over this secure channel with aKEY_SYN message, as follows:(81)<KEY_SYN,keyenc∥keymac>The home gateway device stores thekeyenc and keymac values for the network join operation and returns the KEY_ACK message to the user device, as follows:(82)<KEY_ACK>After this message, the key injection is complete.


## 5.5.7. Proposed Scheme Home Gateway Join Network

After the key injection operation, the home gateway device can securely join the network. The first home gateway device calculates the temporal home gateway ID (t_hid) from hid, as follows:(83)t_hid=FH-MAChid,keyencThe home gateway device prepares theJOIN_SYN message with MAC and resets the operation timer for this message and sends it to the M2M server, as follows:(84)macmsg=FH-MACJOIN_SYN∥t_hid,keymac(85)<JOIN_SYN,t_hid,macmsg>The M2M server searchest_hid in the database and attempts to obtain the detailed record. If the user-related device is not found, then the server terminates the operation. Otherwise, the M2M server obtains _uidu_st, h_st, s, keyenc, and keymac for the related operation. If the home gateway state (h_st) or user state (u_st) is LOCKED, or the home gateway state is already JOINED, then the server terminates the operation. Otherwise, the M2M server verifies the JOIN_SYN message MAC, as follows:(86)mac′msg=FH-MACJOIN_SYN∥t_hid,keymacIf the receivedmacmsg and the calculated mac′msg do not match, then the server terminates the operation. Otherwise, the server proceeds with the session key encryption. The M2M server calculates the session key, Hkey and the session key parameter Hp for the home gateway device, as follows:(87)Hp=FSHA1t_uid∥mid∥sm(88)Hkey=FSHA1t_hid∥HptThe M2M server storesHkey and prepares the JOIN_ACK message with MAC and the encrypted payload, as follows:(89)macmsg=FH-MACJOIN_ACK∥Hp,keymac(90)encmsg=Fe-AESHp∥macmsg,keyenc(91)<JOIN_ACK,encmsg>The home gateway device checks whether theJOIN_SYN operation time is valid; if not, then the device terminates the process. Otherwise, the device decrypts the JOIN_SYN message and verifies MAC, as follows:(92)Hp∥macmsg=Fd-AESencmsg,keyenc(93)mac′msg=FH-MACJOIN_ACK∥Hp,keymacIf the receivedmacmsg and calculated mac′msg do not match, then the home gateway device terminates the operation. Otherwise, the device calculates H′key and keeps it in memory for secure transmission, as follows:(94)Hkey′=FSHA1t_hid∥HptThe home gateway device prepares theJOIN_OK message for the M2M server with MAC, as follows:(95)macmsg=FH-MACJOIN_OK∥t_hid,keymac(96)<JOIN_OK,t_hid,macmsg>The M2M server checks whether theJOIN_ACK operation time is valid; if not, then it terminates the operation. Otherwise, it verifies JOIN_OK MAC and sets the home gateway state (h_st) to JOINED, as follows:(97)mac′msg=FH-MACJOIN_OK∥t_hid,keymacIf MAC verification has failed or a timeout occurs, andJOIN_OK is not received, then the M2M server terminates the operation.


## 5.5.8. Proposed Scheme for the User Password Change

The user device calculatest_uid for the operation. It also prepares a PWD_SYN message with MAC and an encrypted payload, as follows:(98)t_uid=FH-MACuid,keyenc(99)macmsg=FH-MACPWD_SYN∥t_uid∥pw∥pw_new∥s,keymac(100)encmsg=Fe-AESpw∥pw_new∥s∥macmsg,keyencThe user resets the operation timer forPWD_SYN and sends the message to the M2M server, as follows:(101)<PWD_SYN,t_uid,encmsg>The M2M server acquires information fromt_uid and checks the status of the user. If the user state is LOCKED or not equal to ONLINE, then the M2M server terminates the operation. Otherwise, the M2M server acquires keys from the record and decrypts PWD_SYN and verifies the message MAC, as follows:(102)pw∥pw_new∥s∥macmsg=Fd-AESencmsg,keyenc(103)mac′msg=FH-MACPWD_SYN∥t_uid∥pw∥pw_new∥s,keymacIf the receivedmacmsg and calculated mac′msg do not match, then the M2M server terminates the operation. Otherwise, the M2M server calculates keyAES to verify whether the password is correct, as follows:(104)keyAES=FSHA1k∥t_uid∥sn(105)p′=Fe-AESpw,keyAESIf the storedp is not equal to p′, then the password verification fails and the M2M server terminates the operation. Otherwise, the M2M server selects a new salt snew and calculates a new key′AES. Finally, the M2M server encrypts the password for storage as follows:(106)key′AES=FSHA1k∥t_uid∥snewn(107)p′new=Fe-AESpw_new,key′AESThe M2M server storesp′new and prepares a PWD_ACK message with MAC and the encrypted payload. The prepared message is sent to the user device, as follows:(108)macmsg=FH-MACPWD_ACK∥snew,keymac(109)encmsg=Fe-AESsnew∥macmsg,keyenc(110)<PWD_ACK,encmsg>The user device checks whether thePWD_SYN operation time is inside the valid range. If not, it then sets fail_flag to true. If the execution time check fails, then the device skips MAC verification and sends PWD_NACK. Otherwise, the user device verifies PWD_ACK MAC, as follows:(111)snew∥macmsg=Fd-AESencmsg,keyenc(112)mac′msg=FH-MACPWD_ACK∥snew,keymacIf the receivedmacmsg and calculated mac′msg do not match, then the user device sets fail_flag to true and sends PWD_NACK to the M2M server, as follows:(113)macmsg=FH-MACPWD_NACK∥t_uid,keymac(114)<PWD_NACK,t_uid,macmsg>The M2M server verifiesPWD_NACK MAC. If MAC fails, then the server rejects the request. Otherwise, the server restores pnew to p and sets the user device state to the previous state. If fail_flag is not true, then the user stores s_new and preparesPWD_OK for the M2M server with MAC, as follows:(115)macmsg=FH-MACPWD_OK∥t_uid,keymac(116)<PWD_OK,t_uid,macmsg>The M2M server verifies thePWD_OK message MAC, as follows:(117)mac′msg=FH-MACPWD_OK∥t_uid,keymacIf the receivedmacmsg is equal to the calculated mac′msg, then the M2M server sets the user device state to NEW_PASSWORD and the home gateway device state to REVOKED. Otherwise, the server rejects the requests. The home gateway device key’s revocation is reported to the device with a RE_JOIN message by the M2M server, which calculates the RE_JOIN message with MAC and sends it to the home gateway device. When the home gateway device verifies the RE_JOIN message MAC, the home gateway device starts joining the flow again to refresh its session key; thus,(118)macmsg=FH-MACRE_JOIN∥t_hid,keymac(119)<RE_JOIN,macmsg>


## 5.5.9. Proposed Scheme User Logout

User device safe logout for reliable operations is the most critical part. The user device calculates a temporary user ID (t_uid) and LOGOUT_SYN message with MAC for the M2M server, as follows:(120)macmsg=FH-MACLOGOUT_SYN∥t_uid,keymac(121)<LOGOUT_SYN,t_uid,macmsg>The userLOGOUT_SYN message is sent to the M2M server, as follows:(122)mac′msg=FH-MACLOGOUT_SYN∥t_uid,keymacThe M2M server finds the keys fromt_uid and calculates LOGOUT_SYNmac′msg and compares it with the received macmsg. If MAC does not match, then the M2M server rejects the operation. Otherwise, it sets the user device state to OFFLINE and prepares a LOGOUT_ACK message for the user device, as follows:(123)macmsg=FH-MACLOGOUT_ACK∥t_uid,keymac(124)<LOGOUT_ACK,t_uid,macmsg>When the user receivesLOGOUT_ACK, it verifies MAC, as follows:(125)mac′msg=FH-MACLOGOUT_ACK∥t_uid,keymacIf the receivedmacmsg and calculated mac′msg match, then the user device updates its state to the OFFLINE case. Otherwise, it rejects the request.


## 5.5.10. Home Gateway Rejoin Network

This operation is processed after the password change operation. The M2M server sets the home gateway device state toREVOKED and prepares the RE_JOIN message for the home gateway device, as follows:(126)macmsg=FH-MACRE_JOIN∥t_hid,keymac(127)<RE_JOIN,macmsg>The home gateway device calculatest_hid and verifies RE_JOIN MAC. If MAC verifies it, then the home gateway device processes the home gateway join network flow.


## 6. Protocol Analysis

The formal protocol analysis is not processed. We plan to process BAN-LOGIC or ProVerif for future work. We created a MATLAB simulation and tested valid and invalid case behaviors for our proposal and [3] designs.


## 7. Security Analysis

The proposed scheme guarantees protection against replay attacks, changing distance attacks, same-type-device attacks, composition attacks, redirection attacks, MITM attacks, substitution attacks, DoS attacks, forging attacks, colluding attacks, flooding attacks, false message attacks, Sybil attacks, message modifications, wormhole attacks, blackhole attacks, attribute-trace attacks, eavesdropping attacks, chosen-plaintext attacks, spam attacks, identity theft attacks, user manipulation attacks, routing attacks, linkability attacks, rejection attacks, successive response attacks, packet analysis attacks, packet tracing attacks, and brute-force attacks.We used a hybrid cryptographic scheme (ECDH, AES, SHA-1, and H-MAC) to share confidentiality and integrity keys for required entities securely. Identity information for home gateway and user devices were transformed to temporary identities for anonymity with H-MAC, which uses a securely shared MAC key. In addition, user password and home gateway key revocations were developed in the proposed scheme.


### 7.1. Replay Attack

Scheme [3] is classified as partially supported for this attack in [1, 3] claims protection for this attack. They assume that if an intruder intercepts a valid login message and replays the same message that contains <uid,g,h1,s> after logout detection, then the login operation terminated according to the random number input x1 verification. However, for the home gateway device, there is no replay attack protection. The attacker can intercept a home gateway device request and send hid to the M2M server to obtain encryption key information. A registered attacker can send bogus data to the M2M server over this communication channel. We added an additional home gateway key’s injection phase to protect the device registration from this kind of attack. Additionally, state machine flags detect invalid replay requests. Invalid status detection aborts the operation on the M2M server side. Another issue pertains to [3]. They assume that registration and password change channels are secure and that these operations are being performed by the user device. However, if there is a secure channel, then there is no more authentication required. Our scheme assumes that there is no secure channel furthermore to protect each phase for replay attacks. For these reasons, we classified our protocol as fully supported.


### 7.2. Changing Distance Attack

Scheme [3] is listed as not being supported for this attack in [1]. There is no time measurement during the operations for each phase in [3]. An intruder can intercept a message and then send one after its own analysis to the receiver. There is no detection of this attack. The changing distance attack has effects on request timing and the proposed scheme has a minimum and maximum operation time range for the detection of suspicious operations. This additionally provides timeout detection for each request. For these reasons, we classified our scheme as being fully supported.


### 7.3. Same-Type-Device Attack

Scheme [3] is classified as not being supported for this attack in [1]. Scheme [3] The home gateway join request can intercept an intruder, and the original hid can collect from the public channel. The attacker useshid to send multiple register messages to the M2M server to acquire the encryption key. If more than one registration request sending is available, then the encryption key can be revealed via sniffing and decoding the home gateway and M2M server traffic. Moreover, transferred messages can be modified by an attacker, and fraudulent information can be sent to the M2M server to block services.Our proposed scheme only accepts MAC verified messages. A join message is sent by a home gateway device after user key injection. Moreover, each device is uniquely identified with an ID, and this ID protects the device from sniffing with H-MAC diversification on the public network. These protection mechanisms defend against same-type-device attacks. If an intruder virtually registers the device to the M2M server, it should have a user integrity key which is securely injected through the home gateway with the personal network as described in the home gateway join phase section. For these reasons, we classified our scheme as being fully supported.


### 7.4. Composition Attack

Scheme [3] is classified as being not supported for this attack in [1]. Composition attacks are based on collecting several attributes. The composition of this attribute reveals sensitive assets. Scheme [3] user registration and password change operation are not as secure as we mentioned previously. Moreover, the user ID can be sniffed and used to collect or request user-sensitive information over bogus systems. In our scheme, all sensitive assets are protected by the encryption key and MAC. These encryption keys are transported under ECDH keys. This mechanism protects against revealing sensitive assets. For these reasons, we labeled our scheme as being fully supported.


### 7.5. Redirection Attack

Scheme [3] is classified as being not supported for this attack in [1]. An attacker initiates a redirection attack by simulating the M2M server to obtain the user and home gateway device’s network information and sensitive assets. Scheme [3] targets M2M server information injection and protection not mentioned and requests to redirect via a fraudulent base station to the attacker server, and messages can be analyzed and modified for the real server.Our design protects redirection attacks with time measurements and redirected messages are encrypted. MAC protects useful information that cannot be obtained from messages. The attacker cannot modify messages. Furthermore, we have the secure key injection to provide secure registration for home gateway devices as mentioned previously. Sensitive assets are never transmitted over a public network and messages are protected with MAC. For this reason, the attacker must know the encryption and MAC keys to sniff or modify messages. Therefore, we ordered our scheme as being fully supported.


### 7.6. MITM Attack

[3] is labeled as being partially supported for this attack in [1]. However, there is no MAC verification for transmitted messages in scheme [3]. Messages can be modified and operations ceased. Additionally, terminated activities force the user to retry and this causes it to collect more data about the attacked user to recover data. Another issue is that the attacker can cause the transmission of wrong data with modification.Our scheme MAC verification provides message modification attack protection. Sensitive assets are protected with an encryption key for confidentiality and a MAC key for integrity. Sensitive assets are never transmitted clear over a public network and this provides resistance to an MITM attack. For these reasons, we classified our scheme as being fully supported.


### 7.7. Substitution Attack

Scheme [3] is marked as not supported for this attack in [1]. The substitution attack is a particular type of MITM attack to replace original implementation with derived implementation to leak information from the transmission. Scheme [3] user registrations, user password changes, and home gateway devices join phases that are not protected. An attacker can quickly retrieve a sensitive password and user ID from messages.The proposed scheme original user ID is never transmitted in a public network. This privacy protection is provided with the ECDH-key-pair between the user device and the M2M server and a secure key injection between the user device and the home gateway device. This method offers secure key sharing between the home gateway device, the user device, and the M2M server to protect the ID on the public network in the event of this kind of attack. Therefore, a substitution attack is not suitable for this proposed scheme, and we organized our scheme as being fully supported.


### 7.8. DoS Attack

[3] is assigned as not being supported for this attack in [1]. A DoS attacker sends a bulk message system to use more system resources to block servers. Scheme [3] does not have any protection or detection of this kind of attack. In our scheme, on the other hand, DoS attacks are avoided with an operation time measurement and state machine control mechanism. Moreover, messages are protected with MAC and encryption keys. Attackers cannot send valid messages to modify state machine variables on the M2M server. If an attacker sends fewer messages than expected within the minimum operation period, then this is marked as a suspicious operation and it is terminated. Moreover, there is a try count mechanism if an attacker sends continuous messages with invalid MACs; then the user or device is stated as BLOCKED and requests are rejected. This prevents the use of more system resources, such as cryptographic operations on the server. We classified our scheme as fully supported for this attack.


### 7.9. Forging Attack

Scheme [3] is marked as not being supported for this attack in [1]. Scheme [3] user registration, user password changes, and home gateway device join phases are not protected. The attacker can quickly retrieve a sensitive password and user ID from messages. However, in the proposed scheme, forging attack modifications are prevented with MAC protection, state machine control, and operation time measurements. The attacker cannot extract keys from our scheme to join the network and standard algorithms immune to brute-force attacks are used. We deemed our protocol as being fully supported for this attack.


### 7.10. Colluding Attack

Design [3] is classified as not being supported for this attack in [1]. The colluding attack is a guessing attack. The attacker can use old information for new requests. Scheme [3] uses salt (s) to derive a home gateway join key. This salt is updated with a user password change on the server side; however, there is no revocation and the home gateway key is updated after a password change operation.Our scheme password change request also has a key revocation flow to update any old keys. In addition, every message is protected with MAC protection and IDs are never transmitted over a public network. Therefore, an attacker should know the MAC key for the colluding attack, and this is not suitable for this proposed scheme. For these reasons, our plan is deemed by us to be fully supported for this attack.


### 7.11. Flooding Attack

[3] is labeled as not being supported for this attack in [1]. Flooding attacks such as SYN-FLOODING attacks occur during communication channel initiation. An attacker can sniff the first message and replay it to block services. Scheme [3] does not have a try count mechanism for requests to avoid this kind of attack. Our protocol avoids the operation time measurement and state machine control mechanism. Additionally, messages are protected with MAC verification. The attacker should know the MAC key in order to send the first request to the M2M server, so this is not feasible for the attacker and our scheme is fully supported against this attack.


### 7.12. False Message Attack

Scheme [3] is classified as partially supported for this attack in [1]. A malicious message attacker can inject false messages to block the system. Scheme [3] does not have MAC verification or try count for requests.In the proposed scheme, an attacker cannot send any messages without a MAC key. MAC protection and bulk requests trigger the timing control mechanism to detect the attacker. Moreover, rejections never reveal usable information for attackers. We organized our scheme as being fully supported for this attack.


### 7.13. Sybil Attack

[3] is labeled as partially supported for this attack in [1]. Sybil attacks are based on copying the identity of the user device or home gateway device in the current network. Scheme [3] user ID is sent in an open format and it can be sniffed by an attacker.Sybil attacks are avoided with a temporary ID, MAC protection, and sensitive message encryption in this proposed scheme. We identified our project as being fully supported for this attack.


### 7.14. Message Modification Attack

[3] is classified as being not supported for this attack in [1]. Scheme [3] messages are not protected with MAC and they can be modified during transmission.In our scheme, message integrity is protected with a MAC key. Attackers should know the MAC key in order to modify messages. We ordered our design as being fully supported for this attack.


### 7.15. Wormhole Attack

Scheme [3] is marked as being partially supported for this attack in [1]. Wormhole attacker tunnels packets from one point to another point in the network for blocking or for customized analysis. This attack affects transmission and execution time. Scheme [3] does not have an operation time analysis for requests. However, in our scheme, operation time measurement can detect this kind of attack. Moreover, attackers should have MAC and encryption keys to join the M2M secure network. Our scheme is deemed by us to be fully supported for this attack.


### 7.16. Blackhole Attack

Scheme [3] is assigned as partially supported for this attack in [1]. A blackhole attacker returns a false response to broadcast messages to block communications between entities. Scheme [3] does not have message verification and it can be affected by this attack.Our proposed design requests and responses are protected with MAC verification. The attacker cannot send a valid response to the requesting entity without an integrity key. Without such keys, the attacker cannot affect the communication channel. Moreover, this kind of attack affects request timing and the proposed scheme time analysis feature detects this attack. We claim that our scheme is fully supported for this attack.


### 7.17. Attribute-Trace Attack

Scheme [3] is labeled as not being supported for this attack in [1]. An attacker traces attributes and analyses data from all collected information. For this reason, we protect [3] registration and password change phase. Sensitive items, such as user ID and password, can be sniffed during transmission, as mentioned in Section 3.The proposed scheme encrypts sensitive assets with the encryption key and an asymmetric key pair is used for cipher-key transportation. Therefore, attribute tracing is hardened for usable information revealing. We have deemed our scheme as being fully supported for this attack.


### 7.18. Eavesdropping Attack

Design [3] is assigned as being partially supported for this attack in [1]. Eavesdropping attacks are based on listening to the communication channel and obtaining useful information about entities. Scheme [3] user registration and password change phases can be easily affected by this attack and sensitive assets such as password and user ID are readily revealed.In the current scheme, the eavesdropping attack is prevented with the ECDH-key-pair provided for key transportation and message MAC protection. Moreover, sensitive assets are encrypted with the encryption key and IDs are diversified to a temporal ID on the public network for anonymity. We marked our scheme as being fully supported for this attack.


### 7.19. Chosen-Plaintext Attack

Scheme [3] is listed as being not supported for this attack in [1]. Scheme [3] home gateway key revocation that is missing has been considered in Sections 1 and 3.In our scheme, the selected plaintext attack is not proper. There are keys and user revocation mechanisms to refresh key values. Additionally, the algorithms use 128-bit AES encryption and ECDH encryption which are not ideal for brute-force attacks. Our scheme is fully supported for this attack.


### 7.20. Spam Attack

Scheme [3] is assigned as being partially supported for this attack in [1]. The attacker can join the network and send invalid messages to the system to break the communication channel and states during operations or they modify original message data [3]. Messages can change and invalid messages can be sent over [3] the channel to suspend communication.The proposed scheme uses message MAC protection, operation time measurement, and state machine management to avoid spam attacks. For these reasons, our scheme is labeled as being fully supported for this attack.


### 7.21. Identity Theft Attack

Design [3] is classified as being partially supported for this attack in [1]. An attacker sniffs the entity ID and simulates messages [3]. User identifiers are stored on a smartcard, but, during data transmission, the user ID is sent in a clear format. The attacker can easily sniff the user ID and simulate messages.The proposed scheme uses a temporary ID and hides the identity with H-MAC. Real IDs are never transmitted over public networks. We classified our scheme as being fully supported for this attack.


### 7.22. User Manipulation Attack

Scheme [3] is assigned as being partially supported for this attack in [1]. In this attack, an adversary attempts to appear as an M2M server. In [3], the home gateway device can route to the bogus M2M server and then the home gateway device’s message encryption key can be retrieved from the messages. Additionally, the attacker can sniff or modify sensitive assets carried in messages between the home gateway device and the M2M server.The attacker can acquire the user ID (uid) and registered device ID (hid) from an unprotected user registration phase. Additionally, the attacker sniffs traffic between the M2M server and the home gateway device to obtain Hp for a key calculation. After this step, the attacker can provide a fraudulent network for the attacked home gateway device to route a request to the fake M2M server and return Hp to the home gateway device for the session key. Home gateway devices use Hp and calculate Hkey. This procedure is identical to that performed by the attacker and sensitive information can be collected from user home gateway devices or commands can be sent to the home gateway to control devices, as follows:(128)Hp=huid,mid,sm(129)Hkey=hhid,HptIn our scheme user manipulation attack is not applicable. Because we encrypt all sensitive assets Hp are encrypted and MAC protected during transmission as follows:(130)macmsg=FH-MACJOIN_ACK∥Hp,keymac(131)encmsg=Fe-AESHp∥macmsg,keyenc(132)<JOIN_ACK,encmsg>Other requests also ciphered. Our scheme fully supported for this attack.


### 7.23. Routing Attack

Scheme [3] is listed as being partially supported for this attack in [1]. In this attack, the attacker first uses user manipulation attack to acquire the home gateway device’s communication key and routes the user request to intercept user and home gateway communication. During this phase, the attacker can collect sensitive information from the home gateway device. Scheme [3] explained the operation as being suitable. However, in the proposed scheme, routing attacks are avoided with MAC and encrypted messages and operation time measurements can detect routings. For these reasons, our scheme is fully supported for this attack.


### 7.24. Linkability Attack

Scheme [3] is marked as not being supported for this attack in [1]. In this attack, the attacker can obtain the required inputs from different messages to calculate or decode sensitive assets. Scheme [3] user registration and password change operations are not protected and the user ID and password is sent in a clear format. In addition, the home gateway join phase is not sufficiently well protected, and the attacker can reveal a secure channel key. This is explained in the user manipulation attack.Sensitive and usable assets are never transmitted over a public network. Therefore, the linkability attack is not applicable to the proposed scheme.Our scheme is fully supported for this attack.


### 7.25. Rejection Attack

Scheme [3] is labeled as not being supported for this attack in [1]. This is a type of eavesdropping attack. An attacker simulates an M2M server and refuses home gateway or user requests to block service. Scheme [3] user and home gateway devices can be routed to the bogus M2M server, as explained in the routing attack.The proposed design avoids eavesdropping attacks, and this protects our system from rejection attacks. A home gateway can be online after key injection and response protection with MAC verification. The attacker should know the integrity key to send a valid rejection message for the requested entity. The proposed scheme is not suitable for this attack. For these reasons, our project is fully supported for this attack.


### 7.26. Successive Response Attack

Scheme [3] is classified as being not recommended for this attack in [1]. In this attack, an adversary server simulates the M2M server and accepts wrong authorization requests. After this operation, the attacker can send bogus home gateway information to the user device. Scheme [3] user registration and password change phases are considered to work on the secure channel, so there is no protection in these phases. Also according to design [3], the home gateway join phase is not protected well. The home gateway secure channel key can be sniffed as explained by the user manipulation attack.Our scheme messages are protected with MAC verification. Therefore, wrong messages are discarded and successive response attacks are avoided. If an attacker wants to send a successive response, then he should know the integrity key, and this is not suitable in the proposed scheme. For these reasons, our method is fully supported for this attack.


### 7.27. Packet Analysis Attack

Method [3] is classified as partially endorsed for this attack in [1]. In this attack, the attacker analyzes traffic to obtain the user ID, password, and sensitive assets during transmission.Scheme [3] login operation does not reveal the password, but, during the registration and password change phase, the user ID and password are sent in a clear format and are open to sniffing. Other requests are encrypted.The proposed scheme packet analysis is hardened and not suitable for the attacker. It uses the ECDH-key-pair provided for key transportation and message MAC protection. Moreover, sensitive assets are encrypted with the encryption key and IDs are diversified into a temporal ID on the public network for anonymity. For these reasons, our scheme is fully supported for this attack


### 7.28. Packet Tracing Attack

Scheme [3] is classified as being partially supported for this attack in [1]. In this attack, packets are traced with attributes and requests and responses are matched with identifiers to collect or decode sensitive information. Scheme [3] data packages can be determined with the user ID. However, after login, all traffic is encrypted with the session key, so packet tracing is not an issue. However, registration and password change requests have a significant problem with packet tracing attacks. The user ID and password are sent in a clear format and packets are modified according to attacker requirements.In the proposed scheme, packets can be traced but they cannot be modified. Sensitive assets are revealed during transmission. Packet analysis is hardened. The proposed scheme uses the ECDH-key-pair provided for key transportation and message MAC protection. Moreover, sensitive assets are encrypted with the encryption key and IDs are diversified into a temporal ID on the public network for anonymity. For these reasons, our scheme is fully supported for this attack.


### 7.29. Brute-Force Attack

Scheme [3] is classified as not being recommended for this attack in [1]. There are two kinds of brute-force attack.The first is about decoding sniffed traffic. If we do not think about nonsecure user registration and password change phases in [3], then the used standard AES algorithm is immune to the brute-force attack. However, design [3] user registration and password change phases send clear sensitive data (user ID, home gateway ID, and user password), which is a significant problem.In our scheme, we have secure communication for all stages and we used standard AES and trimmed H-MAC algorithms immune to brute-force attacks. Moreover, [3] does not have the revocation mechanism. In the proposed scheme, brute-force is avoided with a user password, key revocation, and the home gateway key’s revocation mechanism.The second one is about repeatedly attempting to log in. Scheme [3] does not have try counter for this kind of attack. The proposed scheme provides the try count to avoid invalid attempts. We classified our system as fully supported for this kind of attack.


## 7.1. Replay Attack

Scheme [3] is classified as partially supported for this attack in [1, 3] claims protection for this attack. They assume that if an intruder intercepts a valid login message and replays the same message that contains <uid,g,h1,s> after logout detection, then the login operation terminated according to the random number input x1 verification. However, for the home gateway device, there is no replay attack protection. The attacker can intercept a home gateway device request and send hid to the M2M server to obtain encryption key information. A registered attacker can send bogus data to the M2M server over this communication channel. We added an additional home gateway key’s injection phase to protect the device registration from this kind of attack. Additionally, state machine flags detect invalid replay requests. Invalid status detection aborts the operation on the M2M server side. Another issue pertains to [3]. They assume that registration and password change channels are secure and that these operations are being performed by the user device. However, if there is a secure channel, then there is no more authentication required. Our scheme assumes that there is no secure channel furthermore to protect each phase for replay attacks. For these reasons, we classified our protocol as fully supported.


## 7.2. Changing Distance Attack

Scheme [3] is listed as not being supported for this attack in [1]. There is no time measurement during the operations for each phase in [3]. An intruder can intercept a message and then send one after its own analysis to the receiver. There is no detection of this attack. The changing distance attack has effects on request timing and the proposed scheme has a minimum and maximum operation time range for the detection of suspicious operations. This additionally provides timeout detection for each request. For these reasons, we classified our scheme as being fully supported.


## 7.3. Same-Type-Device Attack

Scheme [3] is classified as not being supported for this attack in [1]. Scheme [3] The home gateway join request can intercept an intruder, and the original hid can collect from the public channel. The attacker useshid to send multiple register messages to the M2M server to acquire the encryption key. If more than one registration request sending is available, then the encryption key can be revealed via sniffing and decoding the home gateway and M2M server traffic. Moreover, transferred messages can be modified by an attacker, and fraudulent information can be sent to the M2M server to block services.Our proposed scheme only accepts MAC verified messages. A join message is sent by a home gateway device after user key injection. Moreover, each device is uniquely identified with an ID, and this ID protects the device from sniffing with H-MAC diversification on the public network. These protection mechanisms defend against same-type-device attacks. If an intruder virtually registers the device to the M2M server, it should have a user integrity key which is securely injected through the home gateway with the personal network as described in the home gateway join phase section. For these reasons, we classified our scheme as being fully supported.


## 7.4. Composition Attack

Scheme [3] is classified as being not supported for this attack in [1]. Composition attacks are based on collecting several attributes. The composition of this attribute reveals sensitive assets. Scheme [3] user registration and password change operation are not as secure as we mentioned previously. Moreover, the user ID can be sniffed and used to collect or request user-sensitive information over bogus systems. In our scheme, all sensitive assets are protected by the encryption key and MAC. These encryption keys are transported under ECDH keys. This mechanism protects against revealing sensitive assets. For these reasons, we labeled our scheme as being fully supported.


## 7.5. Redirection Attack

Scheme [3] is classified as being not supported for this attack in [1]. An attacker initiates a redirection attack by simulating the M2M server to obtain the user and home gateway device’s network information and sensitive assets. Scheme [3] targets M2M server information injection and protection not mentioned and requests to redirect via a fraudulent base station to the attacker server, and messages can be analyzed and modified for the real server.Our design protects redirection attacks with time measurements and redirected messages are encrypted. MAC protects useful information that cannot be obtained from messages. The attacker cannot modify messages. Furthermore, we have the secure key injection to provide secure registration for home gateway devices as mentioned previously. Sensitive assets are never transmitted over a public network and messages are protected with MAC. For this reason, the attacker must know the encryption and MAC keys to sniff or modify messages. Therefore, we ordered our scheme as being fully supported.


## 7.6. MITM Attack

[3] is labeled as being partially supported for this attack in [1]. However, there is no MAC verification for transmitted messages in scheme [3]. Messages can be modified and operations ceased. Additionally, terminated activities force the user to retry and this causes it to collect more data about the attacked user to recover data. Another issue is that the attacker can cause the transmission of wrong data with modification.Our scheme MAC verification provides message modification attack protection. Sensitive assets are protected with an encryption key for confidentiality and a MAC key for integrity. Sensitive assets are never transmitted clear over a public network and this provides resistance to an MITM attack. For these reasons, we classified our scheme as being fully supported.


## 7.7. Substitution Attack

Scheme [3] is marked as not supported for this attack in [1]. The substitution attack is a particular type of MITM attack to replace original implementation with derived implementation to leak information from the transmission. Scheme [3] user registrations, user password changes, and home gateway devices join phases that are not protected. An attacker can quickly retrieve a sensitive password and user ID from messages.The proposed scheme original user ID is never transmitted in a public network. This privacy protection is provided with the ECDH-key-pair between the user device and the M2M server and a secure key injection between the user device and the home gateway device. This method offers secure key sharing between the home gateway device, the user device, and the M2M server to protect the ID on the public network in the event of this kind of attack. Therefore, a substitution attack is not suitable for this proposed scheme, and we organized our scheme as being fully supported.


## 7.8. DoS Attack

[3] is assigned as not being supported for this attack in [1]. A DoS attacker sends a bulk message system to use more system resources to block servers. Scheme [3] does not have any protection or detection of this kind of attack. In our scheme, on the other hand, DoS attacks are avoided with an operation time measurement and state machine control mechanism. Moreover, messages are protected with MAC and encryption keys. Attackers cannot send valid messages to modify state machine variables on the M2M server. If an attacker sends fewer messages than expected within the minimum operation period, then this is marked as a suspicious operation and it is terminated. Moreover, there is a try count mechanism if an attacker sends continuous messages with invalid MACs; then the user or device is stated as BLOCKED and requests are rejected. This prevents the use of more system resources, such as cryptographic operations on the server. We classified our scheme as fully supported for this attack.


## 7.9. Forging Attack

Scheme [3] is marked as not being supported for this attack in [1]. Scheme [3] user registration, user password changes, and home gateway device join phases are not protected. The attacker can quickly retrieve a sensitive password and user ID from messages. However, in the proposed scheme, forging attack modifications are prevented with MAC protection, state machine control, and operation time measurements. The attacker cannot extract keys from our scheme to join the network and standard algorithms immune to brute-force attacks are used. We deemed our protocol as being fully supported for this attack.


## 7.10. Colluding Attack

Design [3] is classified as not being supported for this attack in [1]. The colluding attack is a guessing attack. The attacker can use old information for new requests. Scheme [3] uses salt (s) to derive a home gateway join key. This salt is updated with a user password change on the server side; however, there is no revocation and the home gateway key is updated after a password change operation.Our scheme password change request also has a key revocation flow to update any old keys. In addition, every message is protected with MAC protection and IDs are never transmitted over a public network. Therefore, an attacker should know the MAC key for the colluding attack, and this is not suitable for this proposed scheme. For these reasons, our plan is deemed by us to be fully supported for this attack.


## 7.11. Flooding Attack

[3] is labeled as not being supported for this attack in [1]. Flooding attacks such as SYN-FLOODING attacks occur during communication channel initiation. An attacker can sniff the first message and replay it to block services. Scheme [3] does not have a try count mechanism for requests to avoid this kind of attack. Our protocol avoids the operation time measurement and state machine control mechanism. Additionally, messages are protected with MAC verification. The attacker should know the MAC key in order to send the first request to the M2M server, so this is not feasible for the attacker and our scheme is fully supported against this attack.


## 7.12. False Message Attack

Scheme [3] is classified as partially supported for this attack in [1]. A malicious message attacker can inject false messages to block the system. Scheme [3] does not have MAC verification or try count for requests.In the proposed scheme, an attacker cannot send any messages without a MAC key. MAC protection and bulk requests trigger the timing control mechanism to detect the attacker. Moreover, rejections never reveal usable information for attackers. We organized our scheme as being fully supported for this attack.


## 7.13. Sybil Attack

[3] is labeled as partially supported for this attack in [1]. Sybil attacks are based on copying the identity of the user device or home gateway device in the current network. Scheme [3] user ID is sent in an open format and it can be sniffed by an attacker.Sybil attacks are avoided with a temporary ID, MAC protection, and sensitive message encryption in this proposed scheme. We identified our project as being fully supported for this attack.


## 7.14. Message Modification Attack

[3] is classified as being not supported for this attack in [1]. Scheme [3] messages are not protected with MAC and they can be modified during transmission.In our scheme, message integrity is protected with a MAC key. Attackers should know the MAC key in order to modify messages. We ordered our design as being fully supported for this attack.


## 7.15. Wormhole Attack

Scheme [3] is marked as being partially supported for this attack in [1]. Wormhole attacker tunnels packets from one point to another point in the network for blocking or for customized analysis. This attack affects transmission and execution time. Scheme [3] does not have an operation time analysis for requests. However, in our scheme, operation time measurement can detect this kind of attack. Moreover, attackers should have MAC and encryption keys to join the M2M secure network. Our scheme is deemed by us to be fully supported for this attack.


## 7.16. Blackhole Attack

Scheme [3] is assigned as partially supported for this attack in [1]. A blackhole attacker returns a false response to broadcast messages to block communications between entities. Scheme [3] does not have message verification and it can be affected by this attack.Our proposed design requests and responses are protected with MAC verification. The attacker cannot send a valid response to the requesting entity without an integrity key. Without such keys, the attacker cannot affect the communication channel. Moreover, this kind of attack affects request timing and the proposed scheme time analysis feature detects this attack. We claim that our scheme is fully supported for this attack.


## 7.17. Attribute-Trace Attack

Scheme [3] is labeled as not being supported for this attack in [1]. An attacker traces attributes and analyses data from all collected information. For this reason, we protect [3] registration and password change phase. Sensitive items, such as user ID and password, can be sniffed during transmission, as mentioned in Section 3.The proposed scheme encrypts sensitive assets with the encryption key and an asymmetric key pair is used for cipher-key transportation. Therefore, attribute tracing is hardened for usable information revealing. We have deemed our scheme as being fully supported for this attack.


## 7.18. Eavesdropping Attack

Design [3] is assigned as being partially supported for this attack in [1]. Eavesdropping attacks are based on listening to the communication channel and obtaining useful information about entities. Scheme [3] user registration and password change phases can be easily affected by this attack and sensitive assets such as password and user ID are readily revealed.In the current scheme, the eavesdropping attack is prevented with the ECDH-key-pair provided for key transportation and message MAC protection. Moreover, sensitive assets are encrypted with the encryption key and IDs are diversified to a temporal ID on the public network for anonymity. We marked our scheme as being fully supported for this attack.


## 7.19. Chosen-Plaintext Attack

Scheme [3] is listed as being not supported for this attack in [1]. Scheme [3] home gateway key revocation that is missing has been considered in Sections 1 and 3.In our scheme, the selected plaintext attack is not proper. There are keys and user revocation mechanisms to refresh key values. Additionally, the algorithms use 128-bit AES encryption and ECDH encryption which are not ideal for brute-force attacks. Our scheme is fully supported for this attack.


## 7.20. Spam Attack

Scheme [3] is assigned as being partially supported for this attack in [1]. The attacker can join the network and send invalid messages to the system to break the communication channel and states during operations or they modify original message data [3]. Messages can change and invalid messages can be sent over [3] the channel to suspend communication.The proposed scheme uses message MAC protection, operation time measurement, and state machine management to avoid spam attacks. For these reasons, our scheme is labeled as being fully supported for this attack.


## 7.21. Identity Theft Attack

Design [3] is classified as being partially supported for this attack in [1]. An attacker sniffs the entity ID and simulates messages [3]. User identifiers are stored on a smartcard, but, during data transmission, the user ID is sent in a clear format. The attacker can easily sniff the user ID and simulate messages.The proposed scheme uses a temporary ID and hides the identity with H-MAC. Real IDs are never transmitted over public networks. We classified our scheme as being fully supported for this attack.


## 7.22. User Manipulation Attack

Scheme [3] is assigned as being partially supported for this attack in [1]. In this attack, an adversary attempts to appear as an M2M server. In [3], the home gateway device can route to the bogus M2M server and then the home gateway device’s message encryption key can be retrieved from the messages. Additionally, the attacker can sniff or modify sensitive assets carried in messages between the home gateway device and the M2M server.The attacker can acquire the user ID (uid) and registered device ID (hid) from an unprotected user registration phase. Additionally, the attacker sniffs traffic between the M2M server and the home gateway device to obtain Hp for a key calculation. After this step, the attacker can provide a fraudulent network for the attacked home gateway device to route a request to the fake M2M server and return Hp to the home gateway device for the session key. Home gateway devices use Hp and calculate Hkey. This procedure is identical to that performed by the attacker and sensitive information can be collected from user home gateway devices or commands can be sent to the home gateway to control devices, as follows:(128)Hp=huid,mid,sm(129)Hkey=hhid,HptIn our scheme user manipulation attack is not applicable. Because we encrypt all sensitive assets Hp are encrypted and MAC protected during transmission as follows:(130)macmsg=FH-MACJOIN_ACK∥Hp,keymac(131)encmsg=Fe-AESHp∥macmsg,keyenc(132)<JOIN_ACK,encmsg>Other requests also ciphered. Our scheme fully supported for this attack.


## 7.23. Routing Attack

Scheme [3] is listed as being partially supported for this attack in [1]. In this attack, the attacker first uses user manipulation attack to acquire the home gateway device’s communication key and routes the user request to intercept user and home gateway communication. During this phase, the attacker can collect sensitive information from the home gateway device. Scheme [3] explained the operation as being suitable. However, in the proposed scheme, routing attacks are avoided with MAC and encrypted messages and operation time measurements can detect routings. For these reasons, our scheme is fully supported for this attack.


## 7.24. Linkability Attack

Scheme [3] is marked as not being supported for this attack in [1]. In this attack, the attacker can obtain the required inputs from different messages to calculate or decode sensitive assets. Scheme [3] user registration and password change operations are not protected and the user ID and password is sent in a clear format. In addition, the home gateway join phase is not sufficiently well protected, and the attacker can reveal a secure channel key. This is explained in the user manipulation attack.Sensitive and usable assets are never transmitted over a public network. Therefore, the linkability attack is not applicable to the proposed scheme.Our scheme is fully supported for this attack.


## 7.25. Rejection Attack

Scheme [3] is labeled as not being supported for this attack in [1]. This is a type of eavesdropping attack. An attacker simulates an M2M server and refuses home gateway or user requests to block service. Scheme [3] user and home gateway devices can be routed to the bogus M2M server, as explained in the routing attack.The proposed design avoids eavesdropping attacks, and this protects our system from rejection attacks. A home gateway can be online after key injection and response protection with MAC verification. The attacker should know the integrity key to send a valid rejection message for the requested entity. The proposed scheme is not suitable for this attack. For these reasons, our project is fully supported for this attack.


## 7.26. Successive Response Attack

Scheme [3] is classified as being not recommended for this attack in [1]. In this attack, an adversary server simulates the M2M server and accepts wrong authorization requests. After this operation, the attacker can send bogus home gateway information to the user device. Scheme [3] user registration and password change phases are considered to work on the secure channel, so there is no protection in these phases. Also according to design [3], the home gateway join phase is not protected well. The home gateway secure channel key can be sniffed as explained by the user manipulation attack.Our scheme messages are protected with MAC verification. Therefore, wrong messages are discarded and successive response attacks are avoided. If an attacker wants to send a successive response, then he should know the integrity key, and this is not suitable in the proposed scheme. For these reasons, our method is fully supported for this attack.


## 7.27. Packet Analysis Attack

Method [3] is classified as partially endorsed for this attack in [1]. In this attack, the attacker analyzes traffic to obtain the user ID, password, and sensitive assets during transmission.Scheme [3] login operation does not reveal the password, but, during the registration and password change phase, the user ID and password are sent in a clear format and are open to sniffing. Other requests are encrypted.The proposed scheme packet analysis is hardened and not suitable for the attacker. It uses the ECDH-key-pair provided for key transportation and message MAC protection. Moreover, sensitive assets are encrypted with the encryption key and IDs are diversified into a temporal ID on the public network for anonymity. For these reasons, our scheme is fully supported for this attack


## 7.28. Packet Tracing Attack

Scheme [3] is classified as being partially supported for this attack in [1]. In this attack, packets are traced with attributes and requests and responses are matched with identifiers to collect or decode sensitive information. Scheme [3] data packages can be determined with the user ID. However, after login, all traffic is encrypted with the session key, so packet tracing is not an issue. However, registration and password change requests have a significant problem with packet tracing attacks. The user ID and password are sent in a clear format and packets are modified according to attacker requirements.In the proposed scheme, packets can be traced but they cannot be modified. Sensitive assets are revealed during transmission. Packet analysis is hardened. The proposed scheme uses the ECDH-key-pair provided for key transportation and message MAC protection. Moreover, sensitive assets are encrypted with the encryption key and IDs are diversified into a temporal ID on the public network for anonymity. For these reasons, our scheme is fully supported for this attack.


## 7.29. Brute-Force Attack

Scheme [3] is classified as not being recommended for this attack in [1]. There are two kinds of brute-force attack.The first is about decoding sniffed traffic. If we do not think about nonsecure user registration and password change phases in [3], then the used standard AES algorithm is immune to the brute-force attack. However, design [3] user registration and password change phases send clear sensitive data (user ID, home gateway ID, and user password), which is a significant problem.In our scheme, we have secure communication for all stages and we used standard AES and trimmed H-MAC algorithms immune to brute-force attacks. Moreover, [3] does not have the revocation mechanism. In the proposed scheme, brute-force is avoided with a user password, key revocation, and the home gateway key’s revocation mechanism.The second one is about repeatedly attempting to log in. Scheme [3] does not have try counter for this kind of attack. The proposed scheme provides the try count to avoid invalid attempts. We classified our system as fully supported for this kind of attack.


## 8. Performance and Security Comparisons

In this section, we compare the security of our design with the previous designs [2–6, 8–11] and we compare the performance of our schemes with the previous design [3]. Previous scheme results were taken from the survey [1] and the proposed scheme analysis was added to the results. The security analysis attacks are shown in Table 8. Table 9 shows the security comparison of each scheme and how our proposed system provides more security and countermeasures for assaults than previous designs. We also compared the proposed method with [3] for performance, network congestion, and resource usage. Table 10 shows the operations notations, and Table 11 shows the operation costs of scheme [3] and the proposed scheme. The calculated times are based on approximately single operation times, and the measured times were based on MATLAB simulated results. Performance comparisons are also shown in Figure 7. The most frequently used login and authentication operation has seven more H-MAC operations in our scheme compared to scheme [3]. The H-MAC is used for anonymity and message modification protection. H-MAC operation usage increases current login and authentication operation times by only 0.088101 seconds. Operation resource usages and network congestion comparisons are shown in Figures 8 and 9.Table 8
Analyzed attacks.
SC1 Replay Attack SC16 Blackhole Attack SC2 Changing Distance Attack SC17 Attribute-Trace Attack SC3 Same-Type-Device Attack SC18 Eavesdropping Attack SC4 Composition Attack SC19 Chosen-Plaintext Attack SC5 Redirection Attack SC20 Spam Attack SC6 Man-In-The-Middle Attack SC21 Identity Theft Attack SC7 Substitution Attack SC22 User Manipulation Attack SC8 DOS Attack SC23 Routing Attack SC9 Forging Attack SC24 Linkability Attack SC10 Colluding Attack SC25 Rejection Attack SC11 Flooding Attack SC26 Successive Response Attack SC12 False Message Attack SC27 Packet Analysis Attack SC13 Sybil Attack SC28 Packet Tracing Attack SC14 Message Modification SC29 Brute-Force Attack SC15 Wormhole AttackTable 9
Security comparison [1].
SC1 SC2 SC3 SC4 SC5 SC6 SC7 SC8 SC9 SC10 SC11 SC12 SC13 SC14 SC15 SC16 SC17 SC18 SC19 SC20 SC21 SC22 SC23 SC24 SC25 SC26 SC27 SC28 SC29 Our. ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ [3] ✓     ✓      ✓ ✓  ✓ ✓  ✓  ✓ ✓ ✓ ✓    ✓ ✓ [2] ✓    ✓ ✓ ✓ ✓       ✓ ✓           ✓ ✓ ✓ [4] ✓    ✓ ✓ ✓ ✓ ✓ ✓     ✓ ✓             ✓ [5]     ✓   ✓  ✓ ✓ ✓    ✓      ✓       ✓ [6] ✓     ✓ ✓     ✓ ✓ ✓  ✓ ✓ ✓ ✓ ✓         ✓ [8] ✓ ✓ ✓ ✓ ✓ ✓ ✓   ✓ ✓ ✓   ✓ ✓    ✓ ✓ ✓ ✓ ✓     ✓ [9]     ✓ ✓ ✓ [10]                             ✓ [11] ✓    ✓ ✓     ✓ ✓   ✓ ✓  ✓ ✓ ✓ ✓ ✓     ✓ ✓ Fully supported =✓, partially supported = ✓, and empty = not supported.Table 10
Operation notations and approximately single operations.
Operation Name Operation Notation Approximately Time (sn) ECDH Generate Key Pair E I 0.009486 ECDH Key Derive E G 0.004638 ECDH Encryption E E 0.001605 ECDH Decryption E D 0.000293 AES Encryption S E 0.073256 AES Decryption S D 0.068992 H-MAC – SHA256 H M 0.000267 SHA-1 H H 0.046198Table 11
Operation comparison between Sun et al.’s [3] and the proposed scheme.
Scheme Operations User M2M Server Home Gateway Total Proposed [3] Proposed [3] Proposed [3] Proposed [3] M2M Server Setup 0 0 1 E I 0 0 0 1 E I 0  Home Gateway Setup 0 0 0 0 0 0 0 0  User Setup 1 E G + 1 H H 0 0 0 0 0 1 E G + 1 H H 0  User Registration and Key Pairing 1 S E + 1 S D + 2 H M + 1 E G + 1 E D 0 2 S E + 1 S D + 4 H M + 1 E G + 1 E E + 1 H H 1 S E + 1 H H 0 0 3 S E + 2 S D + 6 H M + 2 E G + 1 E E + 1 E D + 1 H H 1 S E + 1 H H  User Login And Authentication 1 S E + 3 H M + 4 H H 1 S E + 5 H H 2 S D + 4 H M + 5 H H 2 S D + 4 H H 0 0 2 S D + 1 S E + 7 H M + 9 H H 2 S D + 1 S E + 9 H H  User Home Gateway Key Injection 0 N/A 0 N/A 0 N/A 0 N/A  Home Gateway Join Network 0 0 1 S D + 2 S E + 10 H M + 5 H H 2 H H 1 S D + 4 H M + 1 H H 1 H H 2 S D + 2 S E + 14 H M + 6 H H 3 H H  User Password Change 1 S E + 1 D E + 3 H M 0 3 S E + 1 S D + 4 H M + 2 H H 2 S E + 2 H H 0 0 4 S E + 2 S D + 7 H M + 2 H H 2 S E + 2 H H  User Logout 2 H M N/A 3 H M N/A 0 N/A 5 H M N/A  Home Gateway Re-Join Network 0 N/A 1 S D + 2 S E + 11 H M + 5 H H N/A 1 S D + 5 H M + 1 H H N/A 2 S D + 2 S E + 16 H M + 6 H H N/AFigure 7
Operation time comparison between Sun et al. [3] and the proposed scheme.Figure 8
Operation resource comparison between Sun et al. [3] and the proposed scheme.Figure 9
Network congestion comparison between Sun et al. [3] and the proposed scheme.


## 9. Conclusions

In this paper, we offer an end-to-end secure communication scheme for M2M networks. All required analyses of the proposed scheme have been provided, but formal verification is not complete in this paper. Future work is planned to complete formal verification, increase performance, and decrease resource usage for the proposed scheme based on our measurements.



---

*Source: 6563089-2018-11-01.xml*