User Authentication and Authorization Framework in IoT Protocols

Abstract

The Internet of Things (IoT) has become one of the most attractive domains nowadays. It works by creating a special network between physical devices such as vehicles, home equipment, and other items. In recent days, the common technologies of communication such as Wi-Fi and 2G/3G/4G cellular networks are insufficient for IoT networks because they are designed to serve appliances with immense processing capabilities such as laptops and PCs. Moreover, most of these technologies are centralized and use an existing infrastructure. Currently, new communication technologies such as Z-Wave, 6LowPAN, and Thread are dedicated to the IoT and have been developed to meet its requirements. These technologies can handle many factors such as range, data requirements, security, power demands, and battery life. Nevertheless, the security issues in IoT systems have major concerns and issues because vulnerabilities in such systems may result in fatal catastrophes. In this paper, an enhanced IoT security framework for authentication and authorization is proposed and implemented to protect the IoT protocols from different types of attacks such as man-in-the-middle attacks, reply attacks, and brute force attacks. The proposed framework combines an enhanced token authentication that has identity verification capabilities and a new sender verification mechanism on the IoT device side based on time stamps, which in turn can mitigate the need for local identity verification methods in IoT devices. The proposed IoT security framework was tested using security analysis with different types of attacks compared with previous related frameworks. The analysis shows the high capability of the proposed framework to protect IoT networks against many types of attacks compared with the currently available security frameworks. Finally, the proposed framework was developed using Windows applications to simulate the framework phases, check its validity through the real network, and calculate the payload time added.

1. Introduction

Kevin Ashton introduced the term Internet of Things (IoT) in 1999. Since then, it has been growing rapidly, and the number of installed IoT devices is expected to reach 38.6 billion at the end of 2025 according to Statista [1]. Another statistic shows that the number of IoT-connected devices in 2017 was around 20 billion, and it will be about 22 billion in 2018 and more than double that in 2025 [1]. The IoT is defined as a network of physical objects (sensors, actuators) that interact with one another to perform special tasks while maintaining connectivity to internet services to obtain stationary control and monitoring over the Internet (connect humans with devices). The Internet is not only a network of computers but has evolved into a network of devices of all type and sizes such as vehicles, smartphones, home appliances, toys, cameras, medical instruments and industrial systems, animals, people, and buildings that are all connected, communicating, and sharing information based on stipulated protocols to achieve smart reorganizations, positioning, tracing, safety and control, and even personal real-time online monitoring [2]. The IoT can be classified into three categories, namely, people-to-people, people-to-machine, and machine-to-machine (M2M), all interacting through the Internet. The IoT conforms to a paradigm that considers the pervasive presence in the environment of various things or objects that, through wireless and wired connections and unique addressing schemes, can interact with one another and cooperate with other things or objects to create new applications and services to reach common goals. In this context, the research and development challenges to creating a smart world are enormous. The importance of the IoT can be revealed by its wide range of applications, such as smart cities, smart workplaces, smart industries, smart cars, and smart homes. The IoT environment consists of a considerable number of smart devices such as sensors, actuators, and microcontrollers connected via different means of network communication such as wireless and wired networks. Sensor networks consist of a large number of small, low-powered wireless nodes with limited computation, communication, and sensing abilities; in a battery-powered sensor network, energy and communication bandwidth are precious resources.

Thus, there is a need to adapt the networking process to match the applications in order to minimize the resources consumed and extend the life of the network [3]. Smart devices inside the IoT can connect, transfer information, and decide on behalf of people in a world where the real, the digital, and the virtual are converging to create smart environments that make energy, transport, cities, and many other areas more intelligent. The IoT is characterized by real-world small things that are widely distributed and have limited storage and processing capacities, which involve concerns regarding reliability, performance, security, and privacy. However, cloud computing is considered the backbone of IoT technology because it relies on the Internet, can be accessed from everywhere, and has unlimited capabilities in terms of storage and processing power. IoT devices are required to perform the heavy task and statistical analysis of the gathered data in such cloud computing infrastructures. Cloud computing brings along a new cycle of development of the Internet. On this basis, cloud computing eliminates many limitations. With cloud computing, people will not be constrained by physical resources anymore. On the contrary, they can use the Internet anywhere and at any time [4]. Due to the emergence of various cloud computing services and deployment models and the increasing of security and privacy issues related to them, it is critical to address the infrastructure aspects of cloud computing, such as utility, SaaS, platform and managed services, web, service commerce platforms and internet integration [5]. Thus, a novel IT paradigm in which the cloud and the IoT are two complementary technologies merged expectedly to disrupt current and future smart services [6], and this merged technology, or the new paradigm, is called cloud IoT. The IoT also uses the cloud by exporting cloud services that can deliver services to users and allow them to control the IoT environment.

The concept of cloud computing has emerged widely in the past years because of the nature that facilitates the fast deployment of solution and services. However, the immense data transfer between cloud services and human applications reveal high-priority demands for securing transmission protocols. Therefore, much research has been conducted to overcome the available security issues in terms of user authentication and authorization processes in the internet protocols used in the cloud services. Choudhury et al. proposed a user authentication framework to prevent many types of attacks such as man-in-the-middle attacks, impersonation attacks, and phishing attacks [7]. Those attacks can access the server, damage it, or steal important information between users and servers. The study in [8] proposed an enhancement for the user authentication framework built by [7], but their work still had shortcomings. According to Al-Refai et al. the authentication problem is solved by using an evaluation function conducted by a control agent to verify authentication properties by timestamps, hash functions, identification, and digital signatures [9]. This research investigates the issues in the available security frameworks related to IoT protocols in terms of applicability and security levels and proposes an enhanced security framework adapted for IoT devices based on token authentication technology and fingerprints (FP). The two main purposes of the proposed framework are to deliver a framework that understands the needs of IoT devices such as minimizing the computational load and memory usage of IoT devices due to their capabilities from a hardware design viewpoint, such as limited memory and low processing power, and to deliver a best-practice security framework that overcomes the security issues and attacks available on IoT protocols such as man-in-the-middle attacks and replay attacks by enhancing the registration, authentication, and authorization phases, and adding FP in the registration and authentication phase combined with tokens that contain information from the IoT device itself.

Research Context

This paper studies and analyzes the security needs for IoT protocols while communicating with cloud services over the Internet in terms of authentication and authorization schemes. The IoT proposes new challenges surrounding the cloud network due to its open architecture behavior. Moreover, the standard security criteria used in cloud networks are not fit to be implemented by IoT protocols because they add extra load on the network, which uses very limited resources such as low memory, power consumption constraints, and limited CPU processing capabilities. Owing to those reasons, IoT protocols have been created, which concentrate on allowing IoT devices to communicate with one another and with cloud services with the least power consumption and the fastest end-to-end packet delay. Therefore, IoT protocols do not contain solid standards for security implementations. Despite several efforts from IoT manufacturers to inject security features into their products, most of the implementations were not mature enough to protect the IoT networks and devices from attacks. Moreover, most of the IoT products did not consider the security factor, which led to serious harms due to different types of attacks over IoT networks [10]. This paper studies the different types of attacks and their effect on the IoT network to provide enhanced user authentication and authorization security frameworks for IoT protocols. This work proposes an enhanced framework of the one proposed by [8], which overcomes the weak points related to IoT security preaches. One of the most important issues that appeared in the previous frameworks is token implementation over a session, which can be easily grabbed and used by a third party (i.e., attacker) using a man-in-the-middle attack. This work also investigates the special needs of IoT devices in terms of low memory usage and low computation power. Previous security frameworks did not address such platforms and applied a very heavy load to the processor and the memory of devices to achieve high-security levels for user authentication and authorization. Cloud computing security itself is the set of control-based technologies and policies designed to adhere to regulatory compliance rules and protect the information, data applications, and infrastructure associated with cloud computing use. Different researchers have developed cloud computing and merged it with many security protocols such as internet protocol security, secure shell protocol, TLS, and ACE. All of these protocols enhance the privacy of cloud computing to make it more secure from attackers. Nevertheless, cloud security protocols do not suit IoT technology because of their high complexity. Hence, many IoT protocols such as “Thread protocol and Z wave protocol” have been proposed. Unfortunately, no security standard has been adopted in these protocols. Therefore, this paper aims to present a standard security framework for IoT protocols, which allows IoT protocols to overcome the security issues available in the IoT, such as authentication and authorization breaches, whilst considering the low power consumption, CPU processing, and memory limitations of IoT devices.

This paper aims to propose an enhanced security framework for IoT protocols that overcomes the weakness of previous frameworks in terms of attack vulnerabilities and process power utilization as follows:

• Identity information is added to the generated tokens to allow cloud services to verify the sender (client, IoT device) identity and prevent stolen tokens from being used by attackers because stolen tokens sent by the attacker will have identity information that is different from the attacker request identity.
• All heavy processing to be performed on the cloud servers is relayed to reduce the load on the IoT devices by generating most of the encryption keys (public key [PK] and private key [PRK]) on the cloud services. Moreover, most of the checking mechanisms and token generation are implemented on the cloud side. IoT devices only need to handle a simple pre-shared key encryption mechanism.
• A time stamp (TS) is added to each request or response from the cloud service to the IoT device only, which eliminates reply attacks from being carried out on IoT devices. IoT devices only use tokens to authenticate themselves on cloud services and cannot authenticate the server request using the token mechanism because it will add an immense load on the IoT devices. Therefore, the proposed security framework applies a special mechanism for requests and responses sent from the server side to the IoT devices by using pre-shared key data encryption to encrypt the sent data combined with a TS that restricts hackers from using reply attacks on IoT protocols to control IoT devices.
• An IoT registration phase with the FP authentication method by authorized clients is added to allow them to add new IoT devices securely and prevent other attackers from adding their own malicious IoT devices.
• A software tool for the proposed security framework that simulates all the framework phases is developed to define a core software that can be integrated later inside IoT protocols.

2. Related Work

This section investigates the main previously proposed frameworks and then compares them with our proposed work.

Trnka, M. & Cerny, T. presented a method for managing IoT device authentication and authorization rules that relies on a central identity store [11]. Every device has a registered account in the identity store to confirm its identity against any device and application in the network. The method also provides scalability over the authorization rules because it allows central management for multiple IoT devices and services based on group policies. Token-based authentication is used inside the central identity store to enable fast data access. The results showed a low time consumption for the authentication phase. However, this method used no means of data encryption, which allows different types of attacks such as man-in-the-middle attacks and phishing attacks. Moreover, tokens are not protected from being stolen. Moreover, the central identity store requires all the tokens to be verified directly through it, which disables the local token authentication from the service provider side and leads to an extra time delay through the request–response procedures.

Polat, H. & Oyucu, S. proposed new security authentication procedures based on a combination of token and machine ID authentication [12]. They developed the proposed security authentication model to allow the secure transmission of data for IoT M2M platforms. The new model leveraged the One-M2M model into the database server, web service server, and web client server to allow the full support of internet protocols and to increase M2M scalability while decreasing system complexity by using Restful web services as a communication protocol because it supported the data structure of JSON. The NoSQL database was used for the database server. Finally, token-based authentication was used as a stateless authentication and authorization method to handle machine and human access requests. However, the presented M2M model lacked data encryption, which induced high levels of security breaches such as man-in-the-middle attacks and phishing attacks. Moreover, tokens were not secured from stealing through anti-forgery mechanisms, which made the proposed security model open to reply attacks.

Sciancalepore, S. et al., presented a framework to solve the traditional approaches already adopted for web and cloud applications that cannot be used directly [13]. Most require large computational and bandwidth capabilities (that cannot be reached with restricted devices) and provide low interoperability versus standardized communication protocols for the IoT. The proposed work provided access control functions to the resources to which the IoT is exposed by using existing, widely accepted, and open standards and their proper alignment. The primary component of the OAuth-IoT framework was the gateway, which deals with the following: The first process is collecting the information produced by restricted devices through recently standardized lightweight protocols in the IETF context. The second process is monitoring permission requests provided by party applications through the well-known OAuth 2.0. The third process is supporting various symbolic formats to handle application authentication and authorization properly. The final stage of the system process is temporarily storing data collection. The limitation of this work is that it did not evaluate various scenarios in which the owners of the resources are not online or not identifiable to the client, whether the number of owners is one, two, or more.

Table 1. Comparison between previous IoT frameworks and the proposed one in terms of used security techniques.

Testing Criteria	Author Name
	Trnka and Cerny	Polat, H. et al.	Sciancalepore et al.	Claeys et al.	Oh, Kim and Cho	Hasan Alrefai et al.	Proposed Framework
Protect token	No	No	Yes	Yes	No	No	Yes
Verify cloud service identity	Yes	Yes	Yes	Yes	Yes	No	Yes
Use time stamp	No	No	No	No	No	Yes	Yes
Optimize load over IoT devices	No	Yes	No	No	Yes	No	Yes
Use biometric verification	No	No	No	No	No	Yes	Yes
Use asymmetric encryption	No	No	Yes	Yes	No	Yes	Yes
Use symmetric encryption	No	No	Yes	Yes	Yes	Yes	Yes

summarizes the most substantial previous security frameworks related to the proposed IoT security framework and their used techniques.

Claeys, T. et al., presented an IoT security framework for authentication and authorization [14]. The framework was designed using OAuth 1.0, a model combined with a light version of the ACE security standard. The security framework also presented a new self-securing token that contains security keys for identity verification using a technique called Proof of Possession (PoP). The PoP method was used with an accompanying long-term replay window value maintained by the authorization server that allowed it to increment a special counter inside the token for each new fresh token request for each client. This approach eliminated stolen token reuse attacks. The proposed framework also conducted a new method for authentication and authorization between devices with indirect connection criteria through proxy servers. The results showed a high demand for IoT devices during the token generation and authentication phase due to asymmetric encryption, but the framework was very secure against different types of attacks.

However, the framework allowed local token authentication between IoT devices, which added a high processing and energy demand on the IoT devices. Moreover, no biometric verification for the users was conducted, which may lead to brute force attacks.

Oh, S. R., Kim, Y. G. & Cho, S. presented an access control framework that used OAuth 2.0 [15]. However, the main use of OAuth 2.0 is protecting the user-specific domain and role-based access control to protect resources in the domain. Specifically, the authors expanded OAuth 2.0 to release an Interoperable Access Token (IAT) that acted as a global connectivity range through the IoT platforms by utilizing multiple pairs of clients’ credentials. After testing the interoperability scenario using IAT on the implementation results, they came out with implementing the proposed framework (Mobius), which is one of the M2M-based IoT and firmware. The framework showed good results by rapidly determining if the user can access the domain with a token. Moreover, the role-related permissions were easily managed by administrators in the client-specific domain. The drawbacks of this paper were that the framework could not work in a dynamic environment; it could only work in a static environment. The second drawback was that the framework had no mechanism for protecting against stolen token attacks.

Section 5.2 discusses in detail the comparison between previous works and the proposed work.

3. Enhanced User Authentication and Authorization Framework

This work investigates the issues in the available security frameworks related to IoT protocols in terms of applicability and security levels and proposes an enhanced security framework adapted for IoT devices based on enhanced token authentication technology and FP. An enhanced token adds two new features to a regular token. The first one is for identity verification, whereas the second one allows fast authorization through the token directly. The two main purposes of the proposed framework are to deliver a framework that understands the needs of IoT devices such as minimizing the computational load and memory usage of the IoT devices due to their capabilities from a hardware design viewpoint, limited memory, and low processing power, and the best practice security levels that overcome the security issues and attacks available on IoT protocols such as man-in-the-middle attacks and replay attacks. This approach enhances the registration, authentication, and authorization phases by adding the FP in the registration and authentication phases combined with a token that contains information from the IoT device itself. The proposed framework’s main contribution relies on enhancing the standard token authentication characteristics to overcome the limited hardware capabilities of IoT devices by reducing the authentication and authorization calculations on the IoT devices to a minimum and restrict the complex calculations to be executed on the server side only. This in turn follows the low power consumption standards of IoT protocols and adds a very strong and reliable security layer while maintaining long-life operation for battery-powered IoT devices.

Regular authentication between IoT network devices uses a username and password as the key for accessing the network, which may be the default data as the credentials ‘admin, admin’ come with most devices. Such an authentication type may lead to authentication key exposures; this can be explained depending on the login issuer.

3.1. Client Login via Terminal

In this scenario, the user enters the username and password via a terminal (such as a PC, tablet, or mobile) to access the IoT-connected devices through cloud services to collect data or send a command for a specific device. Even if the protocol is encrypted, if the messages are intercepted by a hacker, then the hacker can easily resend the same messages to the IoT network to perform the same commands, which may lead to immense damage to the devices. Moreover, the IoT network needs to create a session for the logged users to verify them, which in turn creates a load on the devices’ memories.

3.1.1. IoT Device-to-Cloud Service over the IoT Network

This method is the same as the client login, but in this case the IoT device tries to control others or obtain some information to perform dependent actions. The same scenario appears because the connection can be intercepted, and the sent messages can be regenerated between devices.

However, in this case, creating the session has a greater effect because it stays on the IoT network until the device is shut down or the connection is closed, which leads to extra memory usage on each device.

The enhanced security framework consists of seven main phases:

• Cloud service initiation phase;
• Client registration phase;
• Client login phase;
• IoT registration phase;
• IoT login phase;
• IoT to cloud server data transmission;
• Cloud server to IoT data transmission.

3.1.2. Cloud Service Initiation Phase

In this phase, the cloud service prepares itself to receive the requests and data transactions from the clients and the IoT devices by generating asymmetric keys (PK and PRK) to prevent the client’s credentials from being stolen. Moreover, this phase generates a symmetric token encryption key (TEK), which is used only by the cloud service to generate the encrypted tokens and decrypt them in the validation phase. The generated keys are refreshed constantly based on the expiration time of the token assigned by the cloud service administrator to increase the security level of the encryption key by eliminating crypto-analysis attacks.

Using this mechanism in the proposed IoT security framework allows the cryptographic keys to be generated only once and to be used for all requests in other phases. This mechanism reduces the overall process time needed to generate separate keys for different clients and IoT devices. This phase is mainly adopted by the proposed framework to reduce the response time from the server side to the clients and the IoT devices. Different types of encryptions (symmetric, asymmetric) are used to eliminate different types of attacks such as man-in-the-middle attacks, reply attacks, and brute force attacks. Even though asymmetric encryption is considered heavy and time consuming, it is mandatorily used in the presented security framework. As illustrated by the sequence diagrams in Figure 1 (Step 2.1), Figure 2 (Step 2.1), Figure 3 (Step 2.1) and Figure 4 (Step 2.1), the asymmetric key PK is used only once to prevent the client and IoT credentials from being stolen and reused by hackers during transmission to the server because the pre-shared key, SK, can be stolen if used instead of a PK in the mentioned steps. This step is performed to achieve the first and second problem statements. However, asymmetric encryption over the IoT devices in the proposed security framework is only used once and is restricted to the encryption only, which minimizes the load of using asymmetric encryption because generating the keys and decrypting the data are the cloud server’s responsibility.

3.1.3. Client Registration Phase

The client starts the handshake by sending a registration request to the server, and the server replies to the client with an asymmetric PK. The registration phase starts by requesting the user to enter the username and password, with valid conditions such as password length, number and character combinations, and uppercase with a combination of special characters. After a successful input, the framework asks the user to enter three valid FPs using the FP reader attached to the client device. Next, the terminal uses the hash function to sign the submitted data, encrypts all the entered data with the hash code using the PK, and sends them to the server. The server decrypts the data using the PRK, stores them as user account records with the requested permissions, and replies to the client that the registration is finished successfully.

On the one hand, the hash function is used in this phase to sign the transmitted data to prevent data from being manipulated or changed by hackers using man-in-the-middle attacks, as shown in Figure 1 (Step 5), Figure 2 (Step 5), Figure 3 (step 3), and Figure 4 (Step 4). On the other hand, FP biometric authentication is performed to prevent brute force attacks, as shown in Figure 1 (Step 7) and Figure 2 (Step 7) because it eliminates the automatic username and password generation tools from having a successful authentication on the cloud service. Other mechanisms to defend against brute force attacks include using captcha codes. However, it does not completely prevent the attacks from being applied, especially brute force attacks that use artificial intelligence recognition systems such as optical character recognition (OCR). Therefore, using biometric verification in the proposed security framework is the best choice to prevent such attack types. Encryption is also added in this phase to secure the transmitted data and prevent them from being exposed through man-in-the-middle attacks, as mentioned in Figure 1 (Step 3.1). Figure 1 shows the sequence diagram for the registration phase in the proposed security IoT framework.

The steps of the client registration sequence diagram are illustrated below:

• 1- The client sends a registration request through the terminal device (i.e., laptop/mobile):
• C→T: Registration Request
• 1.1- The terminal sends the request to the cloud server:
• T→S: Registration Request
• 2- The server receives the request and sends PK.
• 2.1- The server sends (PK) to terminal and requests CD:
• S→T: (PK)
• 2.2- Through the terminal, the client asks to insert CD.
• 3- The client inserts CD.
• 3.1- The terminal computes (CD, h (CD)) and sends them to the server:
• T→S: Enc pk(CD, h (CD))
• 4- The server decrypts (CD, h (CD)) and starts to check h (CD), RII validity.
• 5- The server checks h (CD) validity.
• 5.1- IF h (CD) is invalid.
• S→T: Invalid CD
• 5.2- Through the terminal to client Invalid Registration.
• T→C: Invalid Registration
• 6- Checks RII Validity.
• 6.1- IF RII Invalid.
• S→T: Invalid RII.
• 6.2- Through the terminal to client Invalid Registration.
• T→C: Invalid Registration
• 7- The server saves CN, CP, and FP.
• 7.1- The server sends Registration Done to the terminal:
• S→T: Registration Done.
• 7.2- Through the terminal to client Registration Done:
• T→C: Registration Done.

Figure 1. Sequence Diagram of Client Registration Phase.

Figure 1. Sequence Diagram of Client Registration Phase.

The main purpose of the client registration phase is not only to add the client into the authenticated pool but also to prevent the client information from being stolen using man-in-the-middle attacks. This step is performed by sending the user information through a secure tunnel and encrypting the information using asymmetric encryption. Moreover, the registration phase applies identity verification based on the Requester Identity Information (RII) sent by the terminal to verify the client identity and eliminate reply attacks. The usage of biometric authentication also removes the possibility of brute force attacks. The framework also uses the hashing mechanism to eliminate data changes and manipulation by hackers.

3.1.4. Client Login Phase

This phase is implemented to ensure that the username, password, and FP information transmitted by the client are not compromised by any type of attacks while they are sent to the server through the network and to secure the data transmitted later between the clients and the server. Thus, the security framework uses asymmetric cryptography techniques based on PKs and PRKs because it prevents the PRK, which is needed to decrypt the data, from being shared over the network, as shown in Figure 2 (Steps 2 to 4). However, the complexity of asymmetric encryption is very high due to the long process required to generate PKs and PRKs. The encryption and decryption of the algorithm is time consuming, and it is not the best way to handle data transmission over slow networks such as IoT networks. Hence, the security framework uses asymmetric key generation only in the cloud service initiation phase periodically based on the expiration time of the token. In addition, the asymmetric encryption/decryption in the login phase is only used in the first step to exchange the user credentials with the pre-shared encryption key (i.e., session key, shared key [SK]).

The client login phase starts by sending the login request to the cloud service. The cloud service then replies to the request with the generated PK. The client submits his credentials (username, password, and FP) in the terminal. The terminal then generates a pre-shared key (SK) and uses a hashing function on the submitted credentials and the generated pre-shared key. Then, the PK received from the cloud server is used to encrypt the client credentials, the SK, and the hash code. Next, the encrypted data are sent to the cloud server. The hash code is used to detect any manipulation in the data by a hacker during their transmission over the IoT network, as shown in Figure 2 (Step 5). After that, the cloud server receives the encrypted data and decrypts them using its PRK. Later, it authenticates the username, password, and finger stamp. In case of a valid login, the cloud server generates the token using the client information and the TEK key and sends it back to the client. The token generation is completely taken by the server starting from generating a payload string of data that contain client name, client authorization level, token expiration date, the RII, and pre-shared key. The generated payload string is then signed using a hash function. The generated payload string and the hash code are encrypted after that using the TEK key. Later, the final encrypted data are sent back to the client and stored in its memory as a token. The token is sent over the network without encrypting it using the SK key generated by the terminal because it is secured by itself using the TEK key. Moreover, the token cannot be reused by hackers because it contains identity verification information. The procedure of this phase is as follows (Figure 2).

Figure 2. Client login phase sequence diagram.

Figure 2. Client login phase sequence diagram.

The steps of the client login sequence diagram are illustrated below:

• 1- The client sends a login request through his terminal (laptop/mobile):
• C→T: Login Request
• 1.1- The terminal sends the request to the cloud server:
• T→S: Login Request
• 2- The server receives the request and generates and sends PK.
• 2.1- The server sends (PK) to terminal and requests CD:
• S→T: (PK)
• 2.2- Through terminal, the client asks to insert CD.
• 3- The client inserts CD.
• 3.1- The terminal computes (SK).
• 3.2- The terminal generates (CD, SK, h (CD, SK)) and sends them to the server:
• T→S: Enc pk(CD, SKh (CD, SK))
• 4- The server decrypts (CD, SK, h (CD, SK)) and starts to check h (CD), RII validity.
• 5- The server checks h (CD)validity.
• 5.1- IF h (CD)Invalid.
• S→T: Invalid CD
• 5.2- Through the terminal to client Invalid Login:
• T→C: Invalid Login
• 6- Checks RII validity.
• 6.1-IF RII Invalid.
• S→T: Invalid RII.
• 6.2-Through the terminal to client Invalid Login:
• T→C: Invalid Login
• 7- The server compares CN, CP, and FP with Registration Record.
• 7.1- IF wrong, CN, CP, FP Data.
• S→T: Invalid Login.
• 7.2- Through the terminal to client Invalid Login:
• T→C: Invalid Login
• 8- The server generates TEK.
• 8.1- The server generates Enc TEK (SK, CN, ED, CA, RII,) h (SK, CN, ED, CA, RII))
• 8.2- The server sends Login Done to the terminal with the token:
• S→T: valid Login (Token)
• 8.3- Through the terminal to client Login Done:
• T→C: Valid Login.

The main purpose of the client login phase is to prevent the IoT network from unauthenticated login breaches using man-in-the-middle attacks by securing the user credentials information using asymmetric encryption. Moreover, this phase protects the client authentication from being hacked using stolen tokens because of the identity verification mechanism. Furthermore, it prevents reply attacks due to the encrypted RII data.

3.1.5. IoT Registration Phase

After a successful login (authentication) of the client through the framework to the cloud server, the client can send the IoT register request and submit all the needed information such as IoT ID, password, and IoT-device-related information such as the MAC address. The submitted IoT device information is then encrypted by the terminal using the pre-shared key (SK), which is used to protect the data from being compromised using man-in-the-middle attacks, as shown in Figure 3 (Step 2.1). The terminal then sends the encrypted data with the authentication token to the cloud service. The framework then verifies the sender client token validity and the received IoT information and saves the newly registered IoT device information. Figure 3 shows the sequence diagram for the IoT registration phase.

Figure 3. IoT registration phase sequence diagram.

Figure 3. IoT registration phase sequence diagram.

The procedure for this phase is illustrated as follows:

• 1- The client sends Login Process through his terminal (laptop/mobile):
• C→T: Login Process
• 1.1- The terminal sends the request to the cloud server:
• T→S: Login Process
• 1.2- The server receives the request and sends Login Done through the terminal to the client:
• S→T: Login Done.
• 1.3- Terminal to Client Login Done:
• T→C: Login Done
• 2- Client to the Terminal IoT Registration Request with, IoT Data, and Token:
• C→T: IoT Reg-Req (IoT Data, Token)
• 2.1- Through Terminal to the cloud server Registration Request with SK for IoTData, TOKEN:
• T→S: Enc SK (IoT Data), Token.
• 3- The server Validate Token (Hash Code).
• 4- The server Decrypt IoTD.
• 5- The server Validate (RII, CA, ED).
• 5.1- IF Invalid Token:
• S→T: Invalid Token.
• 5.2- Through the terminal to the client Invalid Token:
• T→C: Invalid Token.
• 6- The server saves (IoTID, IoTP)
• 6.1- The server sends IoT Registration Done to the terminal:
• S→T: IoT Registration Done.
• 6.2- Through the terminal to the client IoT Registration Done:
• T→C: IoT Registration Done.
• 7- Through the client to the IoT Device, save IoT Data:
• C→IoT: Save IoTD.

The main purpose of the IoT registration phase is to protect the IoT network from malicious IoT devices injected by hackers who may affect the whole network operation. Moreover, this phase prevents the IoT device’s credentials from being stolen using attacking techniques such as man-in-the-middle attacks and reply attacks. Stealing the IoT device credentials may lead to severe damage depending on the operation type of the IoT device.

3.1.6. IoT Login Phase

After the client’s successful registration of the IoT device, the IoT device sends a login request to the server. The server replies to the IoT device by sending its PK, which is used to prevent man-in-the-middle attack in earlier login stages, as shown in Figure 4 (Step 3.1). Then, a unique SK is generated on the side of the IoT device, which will be used later for securing data transactions between the IoT device and the cloud service using a light simple encryption mechanism, as shown in Figure 4 (Steps 3 to 3.1), Figure 5 (Step 1), and 6 (Steps 2 to 2.1). After that, the IoT device sends encrypted data (IoTD, IoTRI, SK h (IoTD, SK, IoTRI)) to the cloud service. The server checks the validation of the data (h (IoTD, SK, IoTRI)). This stage ensures that the data have not been changed by hackers using man-in-the-middle attacks, as shown in Figure 4 (Step 5). The cloud service then responds to the IoT device with an invalid login if the h (IoTD) is invalid. Otherwise, the server checks the validation of the IoRTI; if it is invalid, the server responds with an invalid login to the IoT device. Next, the cloud service compares the IoT ID and the IoTP data. If the IoT ID and the IoTP data are incorrect, the server responds with an invalid login. Otherwise, the server responds to the IoT device with a valid login (token) encrypted with the TEK encryption key. Figure 1 shows the sequence diagram of the IoT login phase.

Figure 4. IoT login phase.

Figure 4. IoT login phase.

The procedure for this phase is illustrated as follows:

• 1- The IoT device sends Login Request to the cloud server:
• IoT Device → S: Login Request.
• 2- The server receives the request and generates PK and PRK:
• S→IoT Device: Login Process.
• 2.1- The server sends (PK) to the IoT device:
• S→IoT Device: (PK)
• 3- The IoT device generates SK
• 3.1- Through IoT device to cloud server with SK for (IoT Data, SK, IoTRI), h (IoT Data, SK, IoTRI).
• 4- The cloud server decrypts (IoT Data, SK, IoTRI), h (IoT Data, SK, IoTRI).
• 5- The cloud server checks h (IoT Data, SK, IoTRI) validity.
• 5.1- IF Invalid h (IoTD), the server sends IoT Invalid Login to the IoT device:
• S→IoT Device: Invalid Login
• 6- The cloud server checks the IoTRI Validity.
• 6.1- IF Invalid IoTRI, the cloud server sends Invalid Login to the IoT device.
• 7- The cloud server compares (IoTID, IoTP) with Registration Record.
• 7.1- IF wrong IoTID, IoTP Data, the cloud server sends Invalid Login to the IoT Device.
• 8- The cloud server generates TEK (From Initiating Phase).
• 8.1- The cloud server generates Token Enc TEK (SK, IoTID, ED, IoTRI) h (SK, IoTID, ED, IoTRI)).
• 8.2- The cloud server sends Valid Login with Token to the IoT device.
• S→IoT Device: Valid Login (Token).

The main purpose of the IoT device login phase is to protect the IoT network from unauthenticated login breaches using malicious IoT devices or man-in-the-middle attacks by securing the IoT device credential information using asymmetric encryption. Moreover, this phase prevents reply attacks using the identity verification technique.

3.1.7. IoT to Cloud Data Transmission

After authenticating the IoT device, the IoT device sends an encryption request to the server with a pre-shared key (SK) and token. The server then decrypts the token and checks the h (SK, IoTID, ED, IoTRI). If the h (SK, IoTID, ED, IoTRI) is invalid, the server responds with invalid requests. Next, the server checks the validation of the IoTRI; if it is invalid, the server responds with an invalid request. The server then checks the validation of ED. If it is invalid, the server responds with an expired token. Lastly, the server decrypts the (SK) data and sends a response with an encrypted SK (Response, TS). On the IoT device side, it decrypts SK (Response, TS) and checks the validation of TS; if it is invalid, it ignores the response. Otherwise, it acts based on the response. Figure 6 shows the sequence diagram of the IoT-to-cloud data transmission.

The procedure for this phase is illustrated as follows:

• 1- The IoT device sends the encryption request with token to the cloud server:
• IoT Device → S: Enc SK (Request), Token
• 1.1- The server receives the request and decrypts using TEK (Token).
• 2- The server checks h (SK, IoTID, ED, IoTRI) validity.
• 2.1- IF Invalid h (SK, IoTID, ED, IoTRI),
• The cloud server sends Invalid Request to the IoT device:
• S→IoT Device: Invalid Request.
• 2.2- The cloud server checks (IoTRI) validity.
• 2.3- IF Invalid (IoTRI), the cloud server sends Invalid Request to the IoT device:
• S→IoT Device: Invalid Request.
• 2.4- The cloud server checks ED validity.
• 2.5- IF Invalid ED, the cloud server sends Expired Token to the IoT device:
• S→IoT Device: Expired Token.
• 3- The cloud server decrypts the data.
• 3.1- The cloud server sends encrypted response with TS to the IoT device:
• S→IoT Device: Enc SK (Response, TS).
• 4- The IoT device decrypts the response with the TS and checks the validity.
• 4.1- The IoT device checks TS validity.
• 4.2- IF Invalid TS, the IoT Device rejects the response.
• 4.3- IF valid, act based on the response.

The main purpose of the IoT to cloud server data transmission phase is to protect the connection between the IoT device and the server from man-in-the-middle attacks by securing the IoT device request information using symmetric encryption and identity verification through the enhanced token, as shown in Figure 6 (Step 1). Moreover, a reply attack is prevented in this phase by having token verification with RII. The TS in this phase is defined as the real time of the cloud service when the response to the IoT device is sent. The TS used in this phase protects the IoT device from being hacked using a reply attack without the need of a local authentication method. This new mechanism leads to the reduction in the load over the IoT device, which solves the fourth problem statement and enhances the IoT device performance in terms of response time and IoT network overall end-to-end delay. Moreover, the cloud service does not need to save the special SK for each IoT device because it depends on the token to obtain the SK.

3.1.8. Cloud Server to IoT Data Transmission

In this phase, the server sends a token request to the IoT device, and then the IoT device sends a response to the server using the same token. This initial step of requesting the token allows the server to obtain the SK, which is used in encrypting the sent data to the IoT device. The next step is for the server to send an encrypted request with TS to the IoT device. Then, the IoT device side decrypts the data (Request, TS) to check its validation; if it is invalid, the IoT device checks the TS validation; otherwise, it ignores the request. Figure 7 shows the sequence diagram of the server-to-IoT data transmission.

The procedure for this phase is illustrated as follows:

• 1- The cloud server asks the IoT device to send the token:
• S→ IoT Device: Request Token.
• 1.1- The IoT device receives the request and sends its token to the cloud server.
• 2- The cloud server receives the token from the IoT device and sends the encrypted request to the IoT
• S→ IoT Device: Enc SK (Request, TS).
• 2.1- The IoT device decrypts the request.
• 2.2- Check TS validity.
• 2.3- IF Invalid TS,
• 2.4- The IoT device ignores the request.
• 2.5- Take action based on the request.

The main purpose of the IoT-to-cloud server data transmission phase is to protect the connection between the IoT device and the server from man-in-the-middle attacks by securing the IoT device request information using symmetric encryption. Moreover, in this phase, the TS is used to protect the IoT device from being hacked using a reply attack. The TS is used to replace the local authentication model needed by the IoT device to validate the cloud service authentication and identity. This model can be explained by the fact that the cloud service is the only platform that can decrypt the information inside the enhanced token. Therefore, the cloud server is the only entity that can send encrypted data with the correct SK key related to each IoT device. Moreover, the encrypted TS inside the packet sent by the server cannot be changed by hackers because changing it directly without decryption will corrupt the TS leading to ignoring of the request by the IoT device.

4. Proposed Security Framework Defense against Man-in-the-Middle attack and Reply Attack Test Cases

The standard IoT protocols do not provide sufficient built-in security procedures [16] such as data encryption or authentication even in more mature protocols such as a thread IoT protocol. The later protocol, which is originally inherited from the internet protocol suite, contains several simple security procedures, but these protocols do not contain IoT device identity verification.

Figure 5 and Figure 8 show different examples of IoT protocols connecting the client with the cloud server. In Figure 8, the client sends the login request with his client data (CD) to the cloud server without encryption to respond to the client. However, in the case of interruption due to man-in-the-middle attacks that present a new connection (hacker), in the connection between the client and the cloud server, the hacker receives the CD and sends it to the cloud server to log in to the system as a client. Figure 5 shows another case, where the client sends the login request with his data (CD) to the cloud server to respond to the client, but in this case the data are encrypted. In a man-in-the-middle attack, the hacker interrupts the connection and receives the packet from the client and sends it as it is to the cloud server, and the cloud server responds to the hacker as a client.

The proposed framework shown in Figure 5 prevents man-in-the-middle attacks by sending the login request with encrypted CD and RII. Thus, if the attacker tries to steal the data and send them to the cloud server, the attacker will not obtain access to the cloud because the RII is changed.

Figure 9 shows another type of attack, which is the reply attack. In this scenario, the cloud server sends a specific action command to the IoT device to take a specific action. When sending the command, the attacker captures the action command and waits for a specific time to resend the same action command to the IoT device to corrupt the normal operation of the IoT device.

Figure 10 shows how the proposed framework prevents the reply attack. The IoT device sends a token to the cloud server based on a request from the cloud server. This token contains a shared SK. The server then sends an encrypted SK with the request and TS to the IoT device. The IoT device decrypts the SK and checks the validation time of the TS by checking the sending time from the server. For example, if the sending time from the server to the IoT device is two minutes, the IoT device will accept the request if the sending time is within two minutes.

However, if the time is more than two minutes, the device will ignore it. The advantages of this approach are preventing any request sent by the reply attacker and reducing the load on the IoT device by removing the local identity verification and authentication procedures from the IoT device side.

Figure 11 shows that the server-side application’s main functionality is to respond to any request coming from the client and the IoT devices. The inputs of the server-side application are the received encrypted requests and the signed token, whereas the outputs of the server-side application can be classified into the public encryption key from the server, the generated token for the logged-in client or IoT device, the token validation result in case of validation failure, and the encrypted response data or commands from the server side combined with the TS.

The operation of the server-side application starts by implementing the first phase of the proposed IoT security framework, namely, generating the PK and PRKs for initial data exchange with the clients and the IoT devices during the registration and login stages. The application also generates the pre-shared key for encrypting the payload of the token and an extra secret key for hash generation used in signing the encrypted payload inside the token.

The PKs and PRKs are generated using the Rivest–Shamir–Adleman (RSA) asymmetric algorithm [17]. Moreover, the symmetric encryption algorithm used is the Advanced Encryption Standard (AES) 128-bit key [18]. AES is used because it is much more secure than either the Data Encryption Standard (DES) or 3DES given that it uses a 128-bit key instead of a 64-bit key such as that used in DES [19]. Moreover, the AES 128 is still considered a relatively lightweight encryption algorithm. In addition, a SHA-512 cryptographic algorithm [4] is used for hash code generation. The server-side application then initiates socket listeners to start receiving requests from the client-side application or the IoT-side application.

5. Results and Discussion: Security Analysis

In this section, the security requirements needed by the proposed IoT security framework to prevent attacks such as reply attacks, man-in-the-middle attacks, and brute force attacks are first investigated. Then, the proposed framework is compared with other previous secure IoT frameworks.

5.1. Security Requirements

Reply Attack:

A reply attack occurs when the attacker captures the requests and response packets between the clients, the IoT devices, and the cloud services and repeats the request when the session is ended. The proposed framework includes an enhanced token that contains an expiration date and identity verification information that eliminates such an attack. Moreover, on the IoT side, reply attacks cannot be established because the proposed security framework deploys a smart authentication mechanism using a pre-shared key and customized TS, which prevent such an attack and reduces the load on the IoT device by cancelling the need for local authentication on the IoT devices.

Man-in-the-Middle Attack:

This attack is considered one of the most effective attacks because it is implemented by a hacker by intercepting the communication between the clients, the IoT devices, and the cloud service. All sent requests and response commands between the IoT devices, clients, and cloud services are sent by the hacker itself, and this enables the hacker to manipulate the requests by changing the data inside the requests, stealing the credentials, or even stealing the tokens assigned with each request. The proposed IoT security framework can prevent such attacks because the sent data on all framework phases are encrypted and cannot be compromised. Moreover, the identity verification methods used by the proposed security framework disable the capability of reusing the intercepted requests. In addition, data manipulations or changes in the request information cannot be carried out because the sent requests of the framework are signed using a hash code, which allows the detection of any change in content.

Brute Force Attack:

This attack uses username and password generation tools that allow testing a large amount of credential patterns in a limited time to obtain a valid guess of IoT devices or client’s credentials. Despite defense mechanisms such as captcha codes, which force the clients to enter randomly generated patterns, the overall complexity of the attack time increases. New mechanisms including smart artificial intelligence tools such as OCR can break such protection mechanisms. The proposed security can defend from such attacks because it uses the FP biometric verification method, which cannot be broken by brute force attacks. Moreover, the framework has a special property that detects such attacks as a three-time login fail, which blocks the IoT device by its MAC address until it is released by the administrator.

Stolen Token Attack:

The reuse of stolen tokens can provide hackers access privilege as the authenticated client or IoT device, and this can lead to severe damage in a critical environment such as IoT networks. The proposed IoT security framework prevents such an attack type by using identity verification information injected inside the enhanced token.

5.2. Comparative Analyses between Different IoT Frameworks and the Proposed One

Table 1 shows the major added enhancements to the proposed framework such as time stamps, biometric verification support, and reducing the load on IoT devices by removing all complex calculations from them and restricting them on the cloud server side only. After that, a comparison between the proposed approach and the previous works are illustrated by showing the supported security techniques used in each related work through analyzing their methodologies as mentioned in Section 2.

Table 2. Attacks prevention comparison.

Attack Type	Author Name
	Trnka and Cerny	Polat, H. et al.	Sciancalepore et al.	Claeys et al.	Oh, Kim and Cho	Hasan alrefai et al.	Proposed Framework
Replay attack	No	No	Yes	Yes	No	No	Yes
Brute force attack	Yes	Yes	No	No	No	Yes	Yes
Man-in-the-Middle Attack	No	No	Yes	Yes	Yes	Yes	Yes
Phishing Attack	No	No	Yes	Yes	Yes	Yes	Yes
Token Reuse attack	No	No	Yes	Yes	No	No	Yes

compares the different types of attack defense capability of previous IoT security frameworks and the proposed one. The attack types were selected in a way to cover most of the major attack techniques, therefore covering all sub-attack types related to each technique. As shown in the table below, the proposed framework was the only one covering most types of attacks.

Table 3. Cryptographic Overhead (MS).

Cryptography Criteria	Cryptographic Overhead (MS)
	Proposed Framework
	Encrypt/Sign	Decrypt/Verify
Symmetric encryption (AES 128)	0.062	0.132
Asymmetric encryption	126	197
HASH (SHA 256)	0.322	N/A
Token generation	167	213
Key generation (Server side)	690	N/A
Key generation (AES 128) client, IoT side	96	N/A

illustrates the execution time overhead added to the IoT protocols for the types of cryptography methods used in the proposed framework based on the simulation results. The results show a low overhead for the token validation and symmetric encryption/decryption processes, which means that the proposed framework does not add high redundant computational time because the rest of the processes are used in very low frequencies and performed on the cloud service side only.

5.3. Simulation Test Using the Developed Windows Application

A Windows application was developed to simulate the IoT framework phases to test the attack prevention performance and extract the execution time overhead, as shown in Table 3. Figure 12 shows the simulation application receiving the request with the authentication token, the token validation, and the information extracted from the token containing the authorization permissions. Figure 13 shows the cloud server simulation with the initiated PK and request received from the client side.

Figure 12 shows the simulation of the client-side proposed framework operation. The simulation shows the received PK, the registration phase, and the received token from the server after a successful login. The figure also shows the requests generated by the framework to be sent to the cloud service.

As mentioned before, a Windows application was developed to simulate the phases of the proposed security framework and the methods and algorithms used inside each phase, to test and evaluate the proposed security framework performance through its normal operation, to test the framework behavior against several attacks such as man-in-the-middle attacks, reply attacks, and brute force attacks, and to verify the internal methods’ execution times and complexities.

The developed Windows application is split into two main categories. The first category is the server-side application, which simulates all the operations inside each phase of the proposed security framework related to the cloud service side. The second category is the client-side and the IoT-side Windows application. The second category shows the functions related to the client and the IoT side. Figure 13 shows the server-side Windows application implementation.

6. Conclusions

In this paper, an enhanced IoT security framework for authentication and authorization was proposed and developed. The IoT security framework uses an enhanced token authentication method that expands the standard token by adding identity verification information and an authorization permission level inside the token payload data. The token payload is then encrypted by the cloud service to prevent stolen token data from being compromised by hackers. The security framework restricts the token validation only on the cloud service side in order to reduce the framework load on the IoT devices. The cloud server requests sent to the IoT devices are authenticated using a smart technique based on encrypted modified TS that reflects the real time of the request sent from the cloud service to the IoT device in order to prevent reply attacks. The TS is generated from the cloud service using the pre-shared key received securely via asymmetric encryption from the IoT device during the login phase, which only exists inside the encrypted payload data of the token. Therefore, it cannot be decrypted by anyone but the cloud service itself. The IoT device can validate any request by decrypting the received requests using its pre-shared key using only this technique. Therefore, it ignores any mis-encrypted data using man-in-the-middle attacks. Moreover, reply attacks using stolen requests from the server will fail due to the TS embedded in the request that will be ignored if expired by the IoT device. The proposed protocol also uses an FP biometric signature to increase the authentication security level and prevent brute force attacks from being implemented in its standard model or even artificial intelligent approaches that are used to penetrate a captcha anti-brute-force-attack model.

The framework was evaluated using a security analysis use-case statistical model that justifies each property and defense technique used to prevent the issues mentioned in the problem statement section, especially the types of attacks such as man-in-the-middle attacks, reply attacks, and brute force attacks. Another evaluation was conducted using a developed Windows application that simulates the proposed IoT security framework, which was used to calculate the time load added to the IoT protocols because of the proposed framework. Moreover, real testing of attack types was deployed over the developed simulation to test the security framework and security efficiency. The testing results showed that the proposed security framework protected the IoT protocols and networks from different types of attacks while adding a very low load over the IoT device.