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.
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. Section 2 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].
Table 1 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].
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.
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 Tables 3 and 4 showing the parameter settings used in the current design.
The encryption and decryption procedures are based on AES (Advanced Encryption Standard), and SHA-1 (Secure Hash lgorithm 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.
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 key . 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: 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 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:
The M2M server encrypts the user password for storage as follows:
User ID, home gateway ID, salt, encrypted password, and statue flag are stored in the database and salt 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 number and calculates the following parameters for an authentication request:
The user device sends the request parameters to the M2M server, which searches and validates in the M2M server database. If 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.
If the received value is equal to the calculated 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 to calculate for the communication session key and sends the required values to the user device for the same session key creation; thus,
The M2M server stores and sends to the user device. The user device uses a created and received , and for session key generation and verifies the M2M server value as follows:
If the calculated value is equal to the approved value, then the session key is stored in the mobile user device for secure communication, and, finally, the user device calculates the hash , as follows:
The user device sends to the M2M server, and, finally, the M2M server verifies the hash; thus,
If the value is equal to the value, then a mutual authentication is established between the M2M server and the user device and 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 value 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 to the M2M server. The M2M server searches for the user ID and obtains an encrypted password from the database, after which it recovers the password encryption key and encrypts a clear password for verification with some subsequent calculations:
If the calculated password is equal to the stored , then the M2M server selects a new random salt and encrypts the new password to store in the M2M server database; thus,
The M2M server stores the encrypted password and sends new salt to the user device. The user device stores 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 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 for data transmission followed by key recover data for the home gateway device; thus,
is saved on the M2M server and is posted to the home gateway device which calculates for data transmission. The home gateway device does not need to know the user ID for the session key production:
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.
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 Hash lgorithm 256) and SHA-1 with 16-byte and 8-byte keys, as shown in Table 6.
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 (). This value is calculated from the user ID () with a trimmed SHA-1 during the user setup phase; thus,
The user sends the public key () to the M2M server during the registration stage with and is never revealed, as follows:
M2M server uses its private key () and receives the public key () to derive encryption key (). For ECDH secure key establishment is as follows:
The M2M server encrypts integrity and confidentiality keys with . These encrypted keys and the M2M server public key () are sent to the user device in the same message to decrease the request size in the proposed scheme; thus,
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 () by calculating the registration message MAC and encrypting the user ID (), password (), and home gateway ID () with a confidentiality key to be sent with , as follows:
The problem in [3] is that 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 message, then it is decrypted with 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 Table 7.
Additionally, we have updated the state of the machines for the current design. Enhanced states in the proposed protocol are shown in Figures 5 and 6.
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 ECDH and key pairs, as follows:
The 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 (, which is mentioned in scheme [3]. During the setup phase, there must be single 80-bit M2M server ID ( 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 () 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 (), which is stored on the smart card. In addition, for registration, the key pair’s user device generates ECDH and key pair, as follows:
A temporal 80-bit is used for only key pairing that is generated in this phase with the following operation:
The generated public key length is 576 bits, and the private key length is 832 bits. Additionally, the user should define the 64-bit password () and 80-bis home gateway id () for the registrations.
5.5.4. Proposed Scheme User Registration and Key Pairing
The user resets the operation timer for the message sending operation and sends the message to the M2M server for registration, as follows:
The M2M server derives with and its own to use as a transport key; thus,
The M2M server generates a 16-byte and for secure transmission. These keys are securely transported under between the entities, as follows:
The M2M server resets the operation timer for the message sending operation and sends the message to the user for the key pair, as follows:
The user device checks whether the operation time is within an acceptable time range; if not, then it destroys sensitive assets and terminates the operation; otherwise, it derives as follows:
The user device decrypts with and keeps 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:
After key pairing registration data sending, the user registration operation starts from the user side. The user device prepares the MAC of the message and the encrypted message payload with the following operations:
The user resets the operation timer for and sends the message to the M2M server; thus,
The M2M server parses the message and finds a related decryption key with and checks whether the operation time is within an acceptable time range; if not and if is not found, then it destroys sensitive assets and terminates the operation. Otherwise, it decrypts the encrypted payload and verifies the MAC; thus,
If and do not match, then the M2M server destroys sensitive assets and terminates the operation. Otherwise, it chooses a salt It also calculates 10 bytes of temporary ID () for operations as follows:
The M2M server calculates the password encryption key with SHA-1, as follows:
The M2M server encrypts the user password () with , as follows:
The M2M server calculates the temporary 10-byte home gateway ID () for storage as follows:
The M2M server sets the user state () to and the home gateway state () to .
At the end of the operation, the M2M server stores the following parameters:
After this operation, the M2M server prepares a message MAC and an encrypted payload as follows:
The M2M resets the operation timer for and sends it to the user; thus,
The user device checks whether the 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:
If and are not equal, then the user device destroys sensitive assets and terminates the operation. Otherwise, it stores and commits and storage for the next operations.
5.5.5. Proposed Scheme for the User Login and Authentication Phase
The user device selects a random number and authentication parameters and , as follows:
According to user identifier privacy, the user calculates as follows:
The user device prepares a message MAC, as follows:
The user device resets the execution timer for the message and transmits the message to the M2M server; thus,
The M2M server verifies and , 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 or not equal to , , and , then it ceases the operation. If all conditions are valid, then it verifies the message MAC, as follows:
If the message and calculated are equal, the computation of continues in order to verify . The M2M server calculates the password encryption key with SHA-1, as follows:
If the received and the calculated do not match, then the stored password is wrong and the M2M server terminates the operation; otherwise, the M2M server selects another random number and calculates and , as follows:
M2M server calculates message MAC as follows:
After this step, the M2M server resets the operation timer for and sends the message to the user, as follows:
The user checks whether the operation time is an acceptable range. If not the operation is terminated; otherwise, it verifies the message MAC, as follows:
If the calculated and received are not equal, then the action is terminated; otherwise, it verifies that is received from the M2M server, as follows:
If the received value and calculated value are equal, then authentication is completed. After this point, the user device keeps for secure data transmission. Otherwise, the user device terminates the process. Until this step, the user verifies the M2M server and then calculates for the M2M server mutual authentication, as follows:
The user device calculates the message MAC and sends the message to the M2M server, as follows:
The M2M server checks whether the operation time is in an acceptable time range; if not, then it terminates the operation. Otherwise, it verifies the message MAC, as follows:
If the calculated is equal to the received , then the M2M server verifies , as follows:
If the received value and calculated value match, then authentication is completed. The M2M server sets the user state to and keeps for secure data transmission.
5.5.6. Proposed Scheme User Home Gateway Key Injection
A successfully registered user has and 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 a message, as follows:
The home gateway device stores the and values for the network join operation and returns the message to the user device, as follows:
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 () from , as follows:
The home gateway device prepares the message with MAC and resets the operation timer for this message and sends it to the M2M server, as follows:
The M2M server searches 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 , , , , and for the related operation. If the home gateway state () or user state () is , or the home gateway state is already , then the server terminates the operation. Otherwise, the M2M server verifies the message MAC, as follows:
If the received and the calculated 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, and the session key parameter for the home gateway device, as follows:
The M2M server stores and prepares the message with MAC and the encrypted payload, as follows:
The home gateway device checks whether the operation time is valid; if not, then the device terminates the process. Otherwise, the device decrypts the message and verifies MAC, as follows:
If the received and calculated do not match, then the home gateway device terminates the operation. Otherwise, the device calculates and keeps it in memory for secure transmission, as follows:
The home gateway device prepares the message for the M2M server with MAC, as follows:
The M2M server checks whether the operation time is valid; if not, then it terminates the operation. Otherwise, it verifies MAC and sets the home gateway state () to , as follows:
If MAC verification has failed or a timeout occurs, and is not received, then the M2M server terminates the operation.
5.5.8. Proposed Scheme for the User Password Change
The user device calculates for the operation. It also prepares a message with MAC and an encrypted payload, as follows:
The user resets the operation timer for and sends the message to the M2M server, as follows:
The M2M server acquires information from and checks the status of the user. If the user state is or not equal to , then the M2M server terminates the operation. Otherwise, the M2M server acquires keys from the record and decrypts and verifies the message MAC, as follows:
If the received and calculated do not match, then the M2M server terminates the operation. Otherwise, the M2M server calculates to verify whether the password is correct, as follows:
If the stored is not equal to , then the password verification fails and the M2M server terminates the operation. Otherwise, the M2M server selects a new salt and calculates a new . Finally, the M2M server encrypts the password for storage as follows:
The M2M server stores and prepares a message with MAC and the encrypted payload. The prepared message is sent to the user device, as follows:
The user device checks whether the operation time is inside the valid range. If not, it then sets to true. If the execution time check fails, then the device skips MAC verification and sends . Otherwise, the user device verifies MAC, as follows:
If the received and calculated do not match, then the user device sets to true and sends to the M2M server, as follows:
The M2M server verifies MAC. If MAC fails, then the server rejects the request. Otherwise, the server restores to and sets the user device state to the previous state. If is not true, then the user stores and prepares for the M2M server with MAC, as follows:
The M2M server verifies the message MAC, as follows:
If the received is equal to the calculated , then the M2M server sets the user device state to and the home gateway device state to . Otherwise, the server rejects the requests. The home gateway device key’s revocation is reported to the device with a message by the M2M server, which calculates the message with MAC and sends it to the home gateway device. When the home gateway device verifies the message MAC, the home gateway device starts joining the flow again to refresh its session key; thus,
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 () and message with MAC for the M2M server, as follows:
The user message is sent to the M2M server, as follows:
The M2M server finds the keys from and calculates and compares it with the received . If MAC does not match, then the M2M server rejects the operation. Otherwise, it sets the user device state to and prepares a message for the user device, as follows:
When the user receives , it verifies MAC, as follows:
If the received and calculated match, then the user device updates its state to the 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 to and prepares the message for the home gateway device, as follows:
The home gateway device calculates and verifies 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 after logout detection, then the login operation terminated according to the random number input verification. However, for the home gateway device, there is no replay attack protection. The attacker can intercept a home gateway device request and send 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 can collect from the public channel. The attacker uses hid 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 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 () and registered device ID () from an unprotected user registration phase. Additionally, the attacker sniffs traffic between the M2M server and the home gateway device to obtain 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 to the home gateway device for the session key. Home gateway devices use and calculate . 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:In our scheme user manipulation attack is not applicable. Because we encrypt all sensitive assets are encrypted and MAC protected during transmission as follows:
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.
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.
Data Availability
The data used to support the findings of this study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that they have no conflicts of interest.