A Mechanism for Securing IoT-enabled Applications at Fog Layer

: The Internet of Things (IoT) is an emerging paradigm branded by heterogeneous 10 technologies composed of smart ubiquitous objects that are seamlessly connected to the Internet. 11 These objects are deployed as Low power and Lossy Networks (LLN) to provide innovative services in various application domains, such as smart cities, smart health, smart communities. The LLN is a form of a network where the interconnected devices are highly resource-constrained (i.e., 14 power, memory, and processing) and characterized by high loss rates, low data rates and 15 instability in the communication links. Additionally, IoT devices produce a massive amount of 16 confidential and security-sensitive data. Various cryptographic-based techniques exist that can effectively cope with security attacks, but are not suitable for IoT as they incur high consumption of 18 resources (i.e., memory, storage and processing). One way to address this problem is by offloading the additional security-related operations to a more resourceful entity such as a fog-based node. Generally, fog computing enables security and analysis of latency-sensitive data directly at the 21 network’s edge. This paper proposes a nov el Fog Security Service (FSS) to provide end-to-end 22 security at fog layer for IoT devices, using two well-established cryptographic schemes, 23 identity-based encryption and identity-based signature. The FSS provides security services, such as 24 authentication, confidentiality, and non-repudiation. The proposed architecture is implemented 25 and evaluated in OPNET simulator using a single network topology with different traffic loads. 26 The FSS performed better when compared with the APaaS and the legacy method. 27 of the end devices,


30
The Internet of Things is an emerging paradigm that provides seamless and ubiquitous connectivity intensive processing and big data storage. However, in the cloud-based IoT applications, there remain unresolved issues such as the requirement of high capacity client access link, variable such as real-time monitoring, industrial automation (Industry 4.0), sensor and actuators networks,  Implementation and evaluation of the proposed FSS to demonstrate the appropriateness of 96 the proposed mechanism.

141
The fog computing layer in both architectures can be leveraged by the security services such as FSS 142 to cope with security attacks which can compromise the confidentiality, integrity, and availability of 143 IoT devices. The FSS can be further extended to provide secure communication between cloud and fog services, but this feature is not the focus of this paper.

156
 Integrity: Integrity refers to the completeness and accuracy of data. It ensures that data have 157 not been changed and hence received as accurately as sent.

158
 Availability: It guarantees provisioning of network services and data to authorized users 159 when required.

160
 Non-repudiation: It refers to ownership of data. It ensures that sender cannot deny having 161 sent the data and the receiver cannot deny having received the data.

162
There is a great computation and storage overhead involved in existing security protocols such as 163 SSL/TSL based communication. For example, it is not worth to apply existing PKI-based systems on 164 all IoT devices due to their excessive computation and storage. PKI and CIA protocols provide hard 165 security in terms of fixed and predefined large sized keys, therefore, causing memory and 166 processing overhead. Therefore, we proposed a fog-based security service for preserving security 167 concerns against authentication, confidentiality, and non-repudiation for fog-based IoT systems.

168
Our scheme is effective against several attacks made on these security attributes. A list of some of 169 those attacks is given in Table 1 along with their description.

Brute Force
The attacker guesses a person's password, user name, secret key (e.g., used for encryption and decryption) and credit card number by each and every possible combination using automated trial and error process [23].

Authentication
Allow invaders to access a website that contains sensitive and important contents. These websites are not directly addressable without the user's necessity to accurately verify their identity [23].

Man-in-the-Middle
The adversary devises access the networks and insert themselves in between the server and User to gain unauthorized control [25].

Replay attacks
The identity of IoT devices is spoofed, altered, or replayed in order to intercept or retransmit the data [26].

Dictionary
All possible words from a dictionary are used to make an attack on authentication data [27].

Eavesdropping
Malicious invaders capture the packets and read its content by listening the communication channels. If the encryption and decryption algorithms are not used in data, then this attack may be quite effective [28].
Session Hijacking TCP session is hijacked to steal session tokens to gain the unauthorized access to a server [31].
Key and/or Certificate

Replication attack
Duplicate keys or certificates of identification proof are used to create ambiguity to disrupt the identification and authentication process [32].

Packet Capturing
Attacker captures the data and information packets from Ethernet frames during communication. They can also read the (Packet Sniffing sensitive information such as passwords, usernames and credit card numbers, if the traffic of the network is not encrypted [33].

Wiretapping
One or more edges may get affected in such attacks to compromise the transient data confidentiality. Adversaries wiretap a links to obtain a part of data for decoding a packet [35].

Non-repudiation
Repudiation Attack Either false information is spread or real event or transaction denial is attempted by the attacker to prove themselves as legitimate participants [36].

Masquerading
It is a kind of impersonation attack where adversary may attempt to impersonate the identity of other nodes for communication and transaction processing [36].

236
In the proposed mechanism, we assume that the input security parameters (params) are assigned to every IoT device, such as a unique identifier, username, and password. A sender is authenticated by 238 the verifier at the fog layer through the provided params: denoted by IDrec. Furthermore, we used 239 asymmetric encryption for getting symmetric keys from the fog layer after node authentication. We 240 used Rivest-Shamir-Adleman (RSA) algorithm for the public key encryption. Our FSS service 241 comprises a Verifier, a private-key-generator (PKG), and a hashing algorithm at fog layer. The

242
Verifier verifies the IDrec that comes from the sender for the authentication (e.g., email address, 243 password, and device ID). Besides, the Verifier also maintains a

245
The PKG is used to generate private keys, which will be used for secure communication between fog 246 layer and IoT layer. The steps are given below to elaborate on how the proposed approach works: 1. The device, which wants to communicate with the fog layer, provides security params 248 denoted by IDrec, which can be any string such as an email address (e.g., abc@gmail.com), 249 a unique identifier (e.g., 3211214687423), or password (e.g., ******).      shown in Figure 7. The device can then apply the fog layer's public key to ensure that the

311
Although a complete evaluation of the proposed security mechanism is underway, some 312 preliminary results for the execution of the proposed FSS features will be presented in this section.
For implementing the FSS service, we used Visual Studio 2017. We first developed a real 314 client-side environment, which consists of a login page and a webmail page. The login page comprises 315 different functions (random secret key generation function, private key encryption and decryption We ran and tested our service on a small fog-based server (a laptop) and IoT devices (4 mobile 318 phones). By using this setup, we obtained benchmark values to be used in OPNET-based network 319 simulator to evaluate our proposed method. Table 2 lists the benchmark values obtained during the 320 experiment, such as the execution time of various key generation functions. Table 2 also provides the 321 technical specification of all the devices used. based on a complete cycle from the client to the server, and then back from the server to the client.

336
The parameters we considered in this calculation are: client-side key generation, client-side message 337 encryption, client-side key encryption, server-side verification, server-side PK generation, 338 server-side PK encryption using the secret key, and server-side PK encryption using the fog private In the OPNET simulator, we considered the network topology shown in Figure 8. In this 348 topology, we used a wireless network, which consists of wireless nodes, a router and a gateway.

349
However, one fog server was used to measure the performance of the proposed service. The

350
benchmark values that we obtained from the real environment were used in the simulator and 351 applied to wireless nodes and the fog server.

352
After applying all benchmark values on the connected nodes and server, we ran and measured     Table 2), the 370 processing time vary accordingly. Furthermore, the fog server's processing time is ~1.1s that 371 depends upon on certain parameters: the fog server-side verification time, the fog server PK 372 generation time, the fog server PK encryption and decryption time using secret key, and the fog 373 server PK encryption and decryption time using the fog private key as well. The fog server 374 processing time is constant as we used the same server for all the IoT devices.
375 Figure 10 demonstrates the correlation between the total time for getting the PK generated by 376 the fog server and E2E processing time in blue and orange lines, respectively. The blue line depicts 377 the total time for getting the PK that starts when a request is sent to the fog server. The fog server 378 node in return, responds with the private key. The IoT device then, applies the received PK for 379 encryption. Despite that, the E2E time represents the time to access a webpage after a node is 380 authenticated. As shown in Figure 10, E2E time varies for each IoT device relying on their processing 381 capabilities. However, total time for getting the PK from the fog server fluctuates due to two main

389
E2E processing times and a difference of 1.72s for the total time in getting PK generated by fog server 390 due to processing and different network connection types.

566
Secure signature-based authenticated key establishment scheme for future IoT applications.