censor: cloud‐enabled secure iot architecture over sdn...

Received: 6 June 2018 Revised: 20 July 2018 Accepted: 6 August 2018

DOI: 10.1002/cpe.4978

S P E C I A L I S S U E P A P E R

CENSOR: Cloud-enabled secure IoT architecture over SDNparadigm

Mauro Conti1 Pallavi Kaliyar1 Chhagan Lal2,3

1Department of Mathematics, University of

Padova, Padova, Italy2University of Padova, Padova, Italy3University of Manipal, Jaipur, India

Correspondence

Chhagan Lal, University of Padova, Padova,

Italy; or University of Manipal, Jaipur, India.

Email: [email protected]

Funding information

European Commission, Grant/Award Number:

PCIG11-GA-2012-321980; EU TagItSmart!

Project, Grant/Award Number:

H2020-ICT30-2015-688061; EU-India REACH

Project, Grant/Award Number:

ICI+/2014/342-896; Cisco University

Research Program Fund and Silicon Valley

Community Foundation, Grant/Award Number:

2017-166478 (3696); CNR-MOST/Taiwan

2016-17

Summary

The cyber-security threats to low-cost end-user devices could severely undermine the expected

deployment of Internet of Thing (IoT) solutions in a range of real-world applications such as envi-

ronment monitoring, transportation, and manufacturing. Additionally, the huge amount of data

generated by these devices posses new challenges concerning tasks such as efficient information

acquisition and analysis, decision making, and action implementation. In this paper, we propose

CENSOR, a novel cloud-enabled secure IoT network architecture based on SDN paradigm. We dis-

cuss the significant benefits as well as challenges that are inherent while performing integration

of SDN and IoT in CENSOR. We show that the emerging software-based networking features

combined with the cloud computing solutions can significantly improve the security and com-

munication reliability in the target IoT scenarios. In particular, to provide the adequate security

measures in the network, CENSOR uses a lightweight and scalable software remote attestation

scheme, which ensures the integrity of the software that is being executed by the IoT devices to

achieve the application specific goals in the network. We further discuss the improvements in data

communication and data overhead that can be achieved in CENSOR due to its convergence with

the cloud computing (at back-end) and fog computing services (at edge routers or front-end). A

Smart City use-case has been considered as a target IoT scenario to analyze the feasibility and

effectiveness of CENSOR concerning the communication security and the network scalability

parameters. Additionally, we provide future research directions along with the recent industry ini-

tiatives that include open issues in the integration and deployment of cloud-enabled SDN-based

IoT networks.

KEYWORDS

cloud computing, internet of things, remote attestation, security, software defined networks

1 INTRODUCTION

With the advancements in the hardware and the functionalities of smart-devices, a vast array of smart applications are being deployed to create

an Internet of Things (IoT) ecosystem. As millions of devices are connecting every day to the Internet, securing and managing such exponentially

growing networks is becoming a challenge for network managers. In this context, the Software Defined Networking (SDN),1 a new networking

paradigm, introduces features such as ubiquitous accessibility, dynamic resource management, robust open programmable interfaces, and logically

centralized control, to overcome various management and security issues in future generation networks such as Information Centric Networking

(ICN)2 and 5G. SDN separates the control plane and the data plane. The network intelligence and state are logically centralized (by using distributed

controllers), and the underlying network infrastructure is abstracted from applications, hence it enables support for heterogeneous device com-

munication. SDN design helps in enhancing network security through global visibility of the network state where the logically centralized control

plane can efficiently resolve a conflict. Thus, the SDN paradigm empowers networks to monitor traffic actively, diagnose threats to facilitates the

network forensics, and perform dynamic security policy alteration and service insertion.3

To deploy an IoT network, a large number of devices which can provide functions such as sensing, actuating, processing, and storage are required.

Thus, the cost becomes a crucial acquiring factor. The deployment cost of an IoT network for an application domain dictates various constraints

Concurrency Computat Pract Exper. 2019;31:e4978. wileyonlinelibrary.com/journal/cpe © 2018 John Wiley & Sons, Ltd. 1 of 14https://doi.org/10.1002/cpe.4978

https://doi.org/10.1002/cpe.4978

http://orcid.org/0000-0002-0051-1551

http://crossmark.crossref.org/dialog/?doi=10.1002%2Fcpe.4978&domain=pdf&date_stamp=2018-11-28

2 of 14 CONTI ET AL.

concerning resource availability such as the number of sensing devices deployed, the memory and computational power device exhibits, and the

energy limitations for unattended devices. Therefore, it becomes essential to investigate, design, and adapt, the required communication and secu-

rity technologies that will be capable of providing the needed functionalities efficiently and reliably. It will eventually lead to the deployment of

well-suited resource constrained sensing platforms. We argue that the state-of-the-art security protocols such as firewalls, distinct prevention sys-

tems, and intrusion detection systems that are usually deployed at the edge or gateway routes of a network can only protect the network from

external attacks. However, in the border-less architecture such as IoT and cloud, an attack could come from a malicious device connected to the net-

work. For instance, during the M2M communication in IoT ecosystem a single malicious device could adversely affect the large part of the network

devices.

The various advantages of SDN such as enhanced security and control over the network activities, makes it a desirable choice for being con-

sidered as a platform for developing and implementing future network architectures. These architectures include cellular networks (eg, 5G)4 and

Internet-of-Things (IoT) ecosystem,5 two of the most significant networks concerning the number of consumers involvement. However, the decou-

pling of the data plane and the control plane introduces new security challenges such as denial of service attacks, man-in-middle attacks (ie, replay

attack, wormhole, and jamming), and saturation attacks. These security challenges in SDN exists at each of its three planes (ie, application, control,

and data).

1.1 Contributions

In this paper, we propose CENSOR, an efficient integration of cloud data centers (CDCs)and IoT network(s) over SDN paradigm to develop a secure

and scalable ecosystem of smart connected objects. In particular, this paper presents design of a cloud-enabled IoT architecture based on SDN

paradigm. To show the correctness of CENSOR, we analyze it against various significant aspects which includes its deployment feasibility, scalability,

interoperability, and security. To this end, the major contributions of our work are as follow.

• We propose CENSOR, a new cloud-enabled IoT architecture over SDN paradigm, and we discuss and analyze its feasibility and working

methodology. We show that the CENSOR is able to effectively provide the adequate level of security and performance enhancement for data

communication in large and heterogeneous IoT networks.

• To show that using CENSOR architecture ensures the reliable and smooth communication between heterogeneous network domains within

an IoT network. To this purpose, CENSOR includes specific components called IoT controller and IoT agent. Additionally, to achieve secure data

communication, CENSOR is equipped with an efficient hierarchical (two level) software remote attestation component. CENSOR also propose

the use of distributed (Fog) computing at edge SDN switches, which enables pre-processing of data (ie, reduces the bandwidth consumption)

and its potential use in real-time (ie, reduces the communication latency). To the best of the our knowledge, CENSOR is the first proposal that

suggests an efficient integration of fog computing and remote attestation techniques for a secure and scalable IoT architecture.

• Finally, we show the deployment feasibility, security analysis, and limitations of CENSOR with the help of a Smart City use-case, which also depicts

its benefits and challenges. We analyze CENSOR against an array of security threats. The analysis shows that the CENSOR is resistant to various

security threats. It is due to its use of centralized control and global networking knowledge at SDN controller along with the new security related

components. Our research highlights that for a massive amount of data collection, storage, processing, and forwarding, which is essential in

future IoT networks, the traditional network tools are inefficient. Whereas, SDN can significantly improve the network control and simplify the

management required by the future networks such as 5G ones.

1.2 Organization

The rest of the paper is organized as follows. Section 2 presents the background to understand IoT and SDN architectures and technologies. The

state-of-the-art on SDN-based IoT architectures along with their benefits and limitations are given in Section 3. In Section 4, we present the details

about various components and working methodology of our proposed IoT architecture (ie, CENSOR). In the same section, we also present the secu-

rity, communication reliability, and deployment feasibility analysis of CENSOR architecture. Section 5 discusses the opportunities and research

challenges in the realization of SDN-based IoT architectures including the CENSOR. Finally, Section 6 concludes our work along with the possible

directions for future work.

2 BACKGROUND

In this section, we present a brief overview of the Internet of Things (IoT) and the Software Defined Networking (SDN) which is required to under-

stand the working methodology of CENSOR. For a detailed description of these networks, we direct the interested readers to the comprehensive

surveys presented in the works of Al-Fuqaha et al6 and Kreutz et al.1

CONTI ET AL. 3 of 14

FIGURE 1 IoT application domains

2.1 Internet of things

The rapid development of communication technologies, resource-constrained devices, nano-electronics, physical objects, cloud and pervasive

computing technologies enables peoples, places, and things to connect anytime and anywhere to the Internet. In recent years, billions of the het-

erogeneous devices are connected to the Internet, and much more are intend to do the same. An IoT network could be seen as a network of

heterogeneous smart devices which are connected to each other and with end users through wired and wireless infrastructures. Due to the het-

erogeneity and scalability, securing and managing these devices becomes a challenging task. To facilitate communication between these devices,

the IoT community proposes various concepts such as Wireless Sensor Networks (WSN), Low-power Wireless Personal Area Networks (LoWPAN),

Machine to Machine (M2M) communication, and communication technologies like Routing Protocol for Low power and Lossy networks (RPL),

Radio-Frequency Identification (RFID), and Near Field Communication (NFC). The availability of right service at right time is a crucial factor for the

success of an IoT application deployment.

Figure 1 depicts the desired IoT ecosystem where a set of IoT application domains are built on top of an application domain independent services

(ie, cloud platform). As it can be seen in Figure 1, all application domains share their services with the other IoT applications running on the differ-

ent domain through the cloud computing platform, which acts as a much needed horizontal market. To ensure the desired and efficient working in

such an IoT ecosystem, comprehensive security and identity management techniques in IoT, which can manage and orchestrate the IoT components

horizontally (from device to service and service user) and vertically (from device hardware to applications) becomes an essential requirement. In

particular, horizontal (aka cross-domain) security is needed at two levels that includes connectivity and application. For instance, depending on the

connectivity type, security schemes such as mutual authentication and data encryption in transit are provided at the connectivity level. While verti-

cal security (ie, hardware to application) should be provided in every domain to enable hardware based root of trust, thus ensures the integrity of the

specific application domain. Although, the application domains are built on trusted software and hardware, depending upon the practical require-

ments of the use-cases, the trust is anchored to hardware. Furthermore, the domains include security and privacy functions to handle authentication

and authorization management, privacy preservation, network security, key/certificate management, and platform security. Depending upon the

results obtained from the risk management, the level of security functions must be set high for critical IoT services. In contrast, a lower level may

suffice for less critical IoT services.

2.1.1 IoT architecture

A high level view of an IoT architecture is shown in Figure 2; it includes a minimum set of functional blocks, divided into various levels in the hierarchy.

At the lowest level of the hierarchy is the local network of smart objects (or devices) that are configured to perform a set of specific tasks in a specific

application domain. The sensing data generated by these devices are collected at sink nodes which store, process, and use it for decision-making

purpose to enhance the quality of life for end users. For efficient storage and processing of such vast amount of data, cloud computing architec-

tures are expected to play a significant role. Based on the received information from the IoT objects various services are composed at the cloud to

serve the end-user requirements. The backbone network which transfer data from the IoT devices to the cloud platform could be a wired network

(ie, traditional Internet) or a wireless network (ie, a cellular network). An additional layer consisting of static or dynamic sink nodes might be used


FIGURE 2 IoT architecture overview

on top of the device layer to control the massive sensing data generated by large number IoT devices. These sink nodes could perform limited data

aggregation and processing functions, such as removing redundant information and low-quality data.

2.2 Software defined networking

Managing a large-scale, heterogeneous, and dynamic network such as IoT is a critical task, as one needs to implement new policies or make changes

across the whole network by configuring each device manually using system specific commands. Such network-wide updates are very complex

and time-consuming, and performing the same in continually changing environment makes it more difficult. Software Defined Networking (SDN)1

paradigm seems to provide a feasible and practical solution to this age-old problem. From the security perspective, the network manager could

define a set of security policies at SDN controller which could be changed later, if required, based on the change in adversary model of the underlying

network or requirements of the business applications.3 Along with security, the controller offers several other benefits such as:

• It helps to enhance the reliability in data communication7 by means of global visibility of the network state where a conflict can be easily resolved

from the logically centralized control plane,

• The centralization of the control plane makes the development and deployment of sensitive network functions easier, and

• It consumes less time in service or device reconfiguration and makes system more error prone. Thus, empowers network providers to actively

monitor traffic and diagnose threats to facilitates network forensics, security policy alteration, and security service insertion.8,9

2.2.1 SDN architecture

The hierarchical architecture of SDN consists of three planes namely Application plane, Control plane, and Data plane. The brief details for these

planes are as follow.

• Application or Service Plane (AP): The application plane is the top-most plane in the SDN infrastructure. It contains business and SDN applications

to support various application domains and functionalities. This plane communicates with the control plane using the northbound APIs.

• Control Plane (CP): The control plane contains physically separated but logically centralized controllers that run the networking operating system

(NOS), maintains the global view of the network infrastructure, and provides hardware abstractions to business and SDN applications. The mul-

tiple controllers in the distributed environment at this plane communicate with each other through eastbound and westbound interfaces, while

the control plane and the data plane communicates with each other through southbound APIs (such as OpenFlow and PCEP).

• Data Plane (DP): The data plane contains networking devices such as routers, switches, gateways, and access points, which take actions on the

incoming packets (such as forward to specific port, drop, and forward to the controller) based on the forwarding rules to which the packet

matches. The SDN controller calculate the forwarding rules using the global view of the network along with the network services such as security

and QoS defined by the business applications.


3 RELATED WORK

In this section, we discuss the major motivations that makes the SDN paradigm based techniques a desirable choice for enhancing communication

reliability and security aspects in IoT networks. First, we present the key challenges that IoT faces in its existing implementation scenarios, and then

we discuss the state-of-the-art SDN-based IoT architectural proposals along with their advantages and limitations.

There is a set of significant IoT challenges6 that needs to be addressed for realizing the true vision of IoT, and enabling the application

programmers and service providers to implement IoT services efficiently are as follow.

• Security, Privacy, and Trust: In IoT systems, billions of devices communicate with each other over different underlying communication networks.

The device and data heterogeneity makes it hard to apply security and privacy mechanisms across the whole ecosystem.

• Scalability: With the existence of diverse hardware platforms, communication standards, and networking protocols, it is hard to add new functions

and their corresponding devices on top or alongside an existing IoT infrastructure.

• Availability and Reliability: Availability and reliability10 of the subscribed IoT services are vital from the consumer's point of view as they are the

one who pays for the services.11

• Interoperability: Handling a large number of heterogeneous devices with different communication protocols and platforms is a critical task.

To address these challenges, the research community is exploiting the use of SDN technologies as a potential candidate as it offers various oppor-

tunities to secure the network infrastructure more efficiently and flexibly. To this end, various existing proposals12,13 explore the SDN functionalities

and their mapping on the IoT architecture to develop a secure and scalable IoT ecosystem. We also believe that the unique benefits of employing

SDN techniques in IoT environment can make the IoT simpler to protect, manage, and reconfigure.

In the work of Sydney,14 authors developed a robust control and communication platform using SDN in a smart grid setting. Similar efforts have

been explored in the smart home domain where IoT devices are heterogeneous, ranging from traditional smartphones and tablets to home equip-

ment and appliances with enhanced capabilities. One other effort was to design a software-defined approach for IoT environments to dynamically

achieve differentiated quality levels for different IoT tasks,15 the focus was to develop a layered SDN controller in IoT setting and achieve QoS

performance for individual data flows.

In the work of Jararweh et al,16 authors propose a SDN-based framework for IoT, which provides simple, flexible, and scalable solutions to con-

trol and manage data from IoT devices collected from heterogeneous underlying networks. The proposal called SDIoT, an architectural model which

receives data from the physical layer sensors, aggregates it, and send it to the SDSec controller for security check. The architecture mainly focuses

on data protection and storage security issues in IoT networks as large amount of data collected in IoT environment is vulnerable and their collec-

tion is highly insecure. In the work of Sahoo et al,17 authors propose a secure architecture for SDN-based IoT networks. The design is based on the

authentication of IoT devices by the controller. The authors create an ad-hoc-network which consists with the IoT devices and connect the network

with one Border Controller. Each device that is part of the ad-hoc network must establish a connection with the border controller through an authen-

tication process. The border controller could be an OF-switch, and it controls all the inter-domain communications between the connecting IoT

devices. If a device is authorized, than only it can transmit messages, thus the technique makes the overall networking environment more secure.

However, the proposed design suffers from the internal attacks such as sybil, blackhole, eavesdropping, jamming, to name a few. A similar solution

is proposed in the work of Flauzac et al,18 which presents an SDN-based IoT architecture for infrastructure as well as infrastructure-less networks

with distributed controllers across the network.

The work of Chakrabarty and Engels19 proposes a secure IoT architecture for smart cities based on SDN paradigm. The architecture provides

security and privacy by including black networks, secure routing through trusted SDN controllers, identity management, authorization, and authen-

tication by using the unified registry and a secure key management system for communication. These four components mitigate the vulnerabilities of

basic IoT networks. However, for IoT networks, the security is the main issue due to missing infrastructure and reactive connection establishments

that are not addressed in the proposed framework. In the work of Balfour,20 authors propose a security architecture for the IoT environment using

Software Defined Perimeter (SDP) protocol. In this, authors integrate SDP with fourDscape technology to secure the IoT environment. The SDP cre-

ates its domain and collects the IP addresses of all the M2M capable devices. Whenever a new device wants to communicate, first it must configure

the SDP by using the authentication credentials. This process brings trust and privacy to the IoT environment and in the M2M communication. In

the work of Ukil et al,21 authors propose an SDN-based secured IoT framework for embedded systems. It uses IoT agents as a module running on the

IoT devices. These agents are registered with IoT controllers. The IoT controller is responsible for their connection with the SDN controller, which

collects routing information and performs authentication of the IoT agents. The IoT network is divided into segments with its SDN controller. Every

IoT device connects to an OpenFlow enabled switch, which coordinates with segment controller. The inter-segment communication is performed

through gateway controller.

Ensuring reliable and real-time data communication between the cloud data centers and the IoT networks is the key to provide the desired

services efficiently to the end-users in any IoT domain. This data communication can be greatly improved by using software-defined cloud data

centers. Tajiki et al22 propose CECT, which is an approach that provides computationally efficient congestion-avoidance and traffic engineering in

software-defined cloud data centers. CECT technique maximizes the network throughput and guarantees the requested QoS level to end-users,

which is a key requirement in critical IoT applications.On the similar note, recently, Vinueza Naranjo et al23 present FOCAN, a multi-tier structure

in which the IoT applications are running on things to jointly compute, route, and communicate with one another. The effectiveness of the proposal


has been demonstrated through smart-city use-case. Additionally, we believe that the use of SDN-based cloud computing could significantly reduce

the energy consumption at cloud data centers without compromising with the performance of the system.24

In summary, while there is a significant interest in managing IoT networks, many of the efforts in this direction are isolated to specific domains

or a specific system layer. In May 2015, Huawei unveiled the world's first SDN-based IoT solution named AgileIoT. It consists of Agile IoT gateways,

operating system, and an Agile controller. Our proposed work employs a layered SDN methodology to bridge the semantic gap between abstract

IoT task descriptions and low-level network or device specifications.

4 PROPOSED ARCHITECTURE: CENSOR

In this section, first we present the major components along with their functionalities and interactions of our proposed cloud-enabled secure IoT

architecture over SDN paradigm (CENSOR). Then, we will present a detailed analysis of CENSOR concerning its security and communication reli-

ability features. Finally, we discuss the benefits and challenges of employing SDN techniques in IoT infrastructures specifically in terms of security,

scalability, and deployment feasibility.

In an application domain, the IoT network intends to cover all the objects by connecting through wireless or wired networks. Therefore, the

objects that are linked to application domains such as military, smart homes, medical devices, and airplanes, wherein security threats can pose a

risk to human life is a matter of higher concern. Furthermore, due to the absence of specific quality-of-service (QoS) control mechanisms for mobile

devices, the user-perceived quality-of-experience (QoE) can only be guaranteed to users locating close to the application servers. In the context of

IoT network, billions of devices will be connected to other devices. However, many of these devices will build their sub-networks which could be a

sensor/ad-hoc network or a wifi network. Hence, there is a need for a secure communication system to ensure that the packets exchanged between

devices residing in different sub-networks are risk free. In such scenarios, if one object in a sub-network is infected by a malicious application, it may

also compromise other connected devices via M2M communications. Furthermore, these heterogeneous networks might be using heterogeneous

devices and communication protocols. Hence, a gateway router is also required to facilitate the communication between these sub-networks.

4.1 CENSOR: architecture description and working methodology

In this section, we illustrate how SDN paradigm can be adapted to support the primary requirements and resolve the challenges of IoT networks.

Figure 3 shows a detailed overview of our proposed architecture called CENSOR. As it can be seen from Figure 3, the CENSOR architecture is com-

posed of four planes where planes 2 and 3 are mapped on the control and data planes of SDN. The design and functionalities of all the four planes

involved in our CENSOR architecture are as follow.

• Object/Device Plane: The lowest plane called device plane, which consists of IoT devices to be controlled such as sensors and actuators. These

devices executes a tiny software called IoT agent that is needed to enforce the security and specific service related directives coming from the IoT

controller. To ensure that the IoT agent is not malicious, it is executed in Trusted Platform Module (TPM), which is remotely attested periodically

by the OF-Switches or the IoT controller(s). The heterogeneous IoT devices at this plane collect and transmit a large volume of raw data, possi-

bly in different formats, and from various application domains towards the OF-switches. Some of the devices at this plane also act as actuators

(ie, receiving commands from the network to carry out specific tasks) or sinks (ie, resourceful devices that collects data from sensors to perform

data aggregation and low-level data processing). As shown in Figure 3, device plane consists of many local and wide area networks (LANs and

WANs) operating with different communication technologies such as WiFi, RFID, IEEE 802.15.4, Z-wave, and LTE-advanced. In particular, depend-

ing on the requirements of the IoT application domain, a number of LANs are deployed at device plane, which might contain heterogeneous

devices and communication protocols, and different data collection policies and data structures.

• Data Plane: As it is seen in Figure 3, all the devices at this plane works under the control of SDN controller(s) (IC1, IC2, … , ICn). This plane con-

sists of Open-Flow enabled network switches (OF-switches). The OF-switches are connected to each other with high-speed communication

links. The OF-switches communicate with the upper plane (ie, control plane) by using Open-Flow protocols knows as Southbound application

programmable Interfaces (SBIs). This plane has similar functions and structure as of the Internet backbone plane in traditional inter-network infras-

tructure. The OF-switches contains an Open-Flow module to communicate with the controller and a forwarding table which consists of a set

of message forwarding rules installed by the SDN controller. Due to the resourceful nature of OF-switches, we equip these with the capabil-

ity to perform periodic software remote attestation of the IoT devices residing in their respective domain. To ensure the correct behaviour of

attestation module at these OF-switches, the switches are attested by the SDN-IoT controller. In this way, we create an attestation hierarchy

(ie, SDN-IoT controller attest the OF-switches and OF-switches attest the IoT devices), which reduces the network overhead and attestation

time in the overall architecture. The details about our attestation module is given in Section 4.2.

An IoT network could consists of a large number of heterogeneous devices as it can be seen from Figure 3. Therefore, it is simply ineffective to

send all the data generated by these tiny devices to the cloud data centers for processing and analysis purposes. It is because transmitting such as

huge amount of data consumes a significant amount of bandwidth, and all these non-essential back-and-forth communication between the IoT

devices and the cloud can adversely impact the overall network communication performance. Hence, there is a need for distributed intelligence


FIGURE 3 Secured IoT architecture over SDN paradigm

and the so-called fast Big Data processing. To this end, the OF-switches in CENSOR are enabled with Fog computing services. The main aim of

these services are two folded: (i) real time processing of the selected data at edge OF-switches, instead of sending it to the cloud for analysis, and

(ii) keep the data close to the IoT devices and end-user for delay sensitive operations.

• Control Plane: This plane has multiple number of logically centralized controller(s) and a set of instruction to apply on data plane according to the

IoT applications. The controller executes various network control techniques that are required to facilitate efficient and reliable communication

services in our proposed architecture. The primary aim of this plane is to create an abstraction for the application services running on the upper

plane of the architecture. The abstraction should hide the heterogeneity of the hardware devices and their communication protocols that are

used at the lower planes for data collection process.

As shown in Figure 3, apart from installing the data forwarding rules in underlying network devices (ie, OF-switches), the controller performs

action based on the requirements of different IoT applications running on top of it. These actions include various network management functions

such as security management, topology management, resource management, IoT service management, traffic management, and device manage-

ment. The SDN-IoT standard controller at this plane uses the northbound interface APIs to provide a required interface between various IoT

applications running on the upper plane. The SDN-IoT standard controller controls and configures the required functions and services on the

IoT devices (ie, sensors and actuators) installed at device plane. In particular, the SDN-IoT standard controller takes specific task requirements

from application plane, and it can dynamically configure the underlying network infrastructure using the controller(s), to execute these tasks on

behalf of the requesting IoT application(s). Specifically, the IoT controller can talk to the IoT applications as well as the IoT devices to gather the

required context information about a task, and it can take the necessary decisions and reflect them into the underlying network. The data gener-

ated by the billions of IoT devices at device plane is processed at cloud platform (or IoT Cloud), which resides at this plane. The cloud computing

applications handle the received data and compose services thata are promised by the IoT applications.

In our proposed architecture, we are creating an attestation hierarchy, which starts from the SDN-IoT controllers that resides at the control

plane. For attestation process, we perform a set predefined steps, which are shown in Figure 5. By following these steps, we can validate the

software-integrity of any connected OF-switch and IoT device. When a device's software got compromised by an adversary, it starts to perform

malicious activities in the network caused by the software alteration. Later, whenever such a device is asked to perform the attestation challenge

on its software and then send its report to the verifier, than due to the alteration in the software, the attestation report comes disrupted, which

leads the SDN-IoT controller to find the adversarial device.


• Application or Service Plane: The IoT service developers and different operators build IoT applications at the application plane. Individual appli-

cations running at this plane can enforce various IoT service manipulations such as addition, deletion, and modification of IoT services by

communicating with the SDN-IoT standard controller. Based on the importance of the service offered by the application domain, adequate secu-

rity policies can be dynamically enforced in the underlying communication system. The end user or customer can register for a new IoT service

in an IoT application domain at this plane. The application will pass this new requirement to the underlying SDN-IoT standard controller, which

then (re)configures the IoT devices to collect suitable data that can be used by the cloud platform to compose the requested service. Information

for instructing how the SDN-IoT controller should communicate with the underlying network elements at device plane is passed through a set

of APIs called North Bound Interfaces (NBIs).

The IoT applications send the following information to SDN-IoT controllers: (i) IoT service logic and its operations, (ii) mechanisms and policies

for data storage and processing, and (iii) policies related to scalability, interoperability, protocol conversion rules, security, and accounting. The

processing of all the data is done with the help of IoT cloud present at the control plane.

The plane also manages the business of all the IoT system activities and services. In particular, this plane evaluates the outcome of all the

underlying planes and compare it with the expected output to maintain and enhance the performance of the whole architecture. The use of

growth graphs at the application layer by the IoT domains reflects various statistics related to the efficiency of the underlying network con-

cerning resource consumption and management, QoS perceived by the end users, security level achieved by the operations performed in the

network, and communication reliability and bandwidth requirements. Based on the results on the growth graph additional measures related to

design, implement, monitor, and develop new IoT systems, could be taken to improve the specific areas, in which the IoT application is lacking

in performance. Thus, this layer is also known as business (management) layer because it manages the overall IoT applications system activities

and services. The application layer makes it feasible to support the decision making techniques based on results of Big Data analysis. In partic-

ular, the monitoring and management of the underlying three layers is done at this layer. Furthermore, application layer compares the output of

underlying layers with their expected outputs, and it enhances services and maintain users' privacy when required.

4.2 Security module of CENSOR

In this section, we briefly explain the security features that we include in CENSOR to provide security and reliable data communication in large

scale IoT networks. Previously, few of the research articles25 have already proved that the secure hardware-software co-design is more suitable for

advanced computing platforms as a low-cost security solution.

To apply hardware security features in the overall network, we assume that the SDN-IoT controllers, OF-switches, and IoT devices are equipped

with minimal secure hardware protection unit.25 For our architecture, we are considering the SMART26 based implementation. The SMART based

hardware support makes remote attestation and message communication between the controllers, OF-switches, and devices secure and reliable.

After a specific time-interval the Remote Attestation (RA) procedure is performed in the CENSOR architecture. Here the RA is completed in two

phases. First IoT devices behave as prover and the OF-switches will play the role of the verifier. It check the IoT agent software installed at all the

devices for any possible maliciousness. In the second phase, all the OF-switches will behave as prover and the SDN-IoT controllers will play the role

of verifier. It ensures that the OF-switches are running the non-malicious SMART enabled attestation module to attest the underlying IoT devices.

Any event of malicious activity will be notified at the time of remote-attestation process because only the owner will have the read and write access

to the hardware executing the attestation software. The previous results of remote attestation on IoT devices show that it is a very well formulated,

optimum, faultless, and best security solution for today's IoT environment.27 The detailed discussion on attestation process is out of the scope of

this paper, therefore we refer interested readers to more comprehensive works given by Ibrahim et al28 and Kohnhäuser et al.29

The main components of the SMART integrated CENSOR architecture are as follow.

• a Read-only Memory (ROM): ROM provides exclusive hardware-enforced ability to access the key. It stores the key and attestation algorithm.

During attestation process, ROM need to ensure: (i) Key Isolation (ie, avoid key leakage), (ii) Memory Safety (ie, ensure that key leakage and

temporary memory exposure should not result due to software bugs, and (iii) Atomic Execution (ie, while attestation algorithm execution should

be atomic and complete). The attestation key (Akey) is shared between the prover and verifier. The key can be pre-loaded in prover's ROM or it can

programmed on the ROM latter.

• a Memory Protection Unit (MPU): execution aware MPU makes sure the use of key and attest algorithm by verified and trusted user as it is shown

in Figure 4.

Figure 4 shows that we have includes a optimized SMART-based security module for CENSOR architecture. The main reason behind adopting

SMART26 backed security architecture is to secure the internal network communications among controllers and OF-switches (forwarders). We

knew that in SDN and IoT networks, a remote or local adversary can modify, delete, and eavesdrop on any network communication between the

controller and the OF-switches. Therefore, it is indeed required to secure these messages, which are essential to maintain the data communication

reliability in the whole network. In the event of an adversarial attack during the attestation process, the SDN-IoT controller or OF-switch can quickly

detect whether the message(s) are from the legitimate source or not. It is because the messages are encrypted using keys, which are stored securely

in SMART based hardware of controllers or OF-switches, and the unauthorized entities will not have access to these keys.


FIGURE 4 SMART-enabled security module in CENSOR

FIGURE 5 Working steps of attestation process in CENSOR

In particular, the CENSOR's SMART-based attestation uses a challenge based protocol, which is initiated by a verifier (eg, SDN-IoT controller or

OF-switch) that make use of a special purpose hardware (aka Trusted Platform Module, TPM) at the prover (eg, IoT device). To start the attestation

process, the verifier (V) sends a set of parameters to prover (P), such as attestation region boundaries [x, y], and a nonce n to prevent replay attacks.

A ROM-resident code (RRC) segment on P calculates (using nonce n) a cryptographic checksum (CC) of a memory area [x, y] in prover's ROM. After

execution P returns CC to V. Later, V verifies the correctness of the received CC by re-calculating the CC using the same parameters and Akey.

Figure 5 shows the steps used in the CENSOR attestation process. In step 1, the verifier initiates the attestation process, the verifier could be the

SDN-IoT controller (for OF-switches attestation) or the OF-switch (for IoT devices attestation). In step 2, the verifier send a challenge with a nonce

to the prover. In particular, the verifier asks prover to perform its software attestation using the key and algorithm that exists in the prover's SMART

enabled hardware as it is shown in Figure 4. In step 3, prover performs the calculation (ie, executes the attestation algorithm) with the hash value

of its own software. In step 4, prover send the calculated hash of its own software with time stamp and nonce to the verifier. Here, the time stamp

is used to make the calculated value process time bound or to know: (i) when the attestation has been performed, and (ii) when the nonce is used.

It is done to keep the freshness of the resultant value. In step 5, the verifier compares and validates that whether the received hash is equals to the

stored hash or not. After validation, if values of both the hashes is equal, it indicates that their is no compromise is done with the prover's software.

The another case indicates towards a possible compromise of the prover's software.

The security arguments that we have presented for the attestation process of CENSOR are based on the following assertions:

• X1: Cryptographic checksum (Csum) computed by prover (P) cannot be forged. It is because Csum is a result of a secure message authentication

code function (eg, HMAC-SHA), hence for any adversary that observes a polynomial number for Csum, it is not feasible to find HMAC collisions

or learning bits of the attestation key.

• X2: We assume that physical attacks on P are beyond attackers capabilities.

• X3: The attestation key (Akey) is only accessible by ROM-resident SMART code, and the SMART code is not modifiable as it resides on ROM.

• X4: During the execution of attestation algorithm all interrupts will remain disabled.

• X5: Akey cannot be extracted by any software-based adversary internal to prover. Upon completion of SMART execution, Akey is no longer

accessible. Additionally, memory area [x, y] is securely erased, and only the value Csum which is based on Akey will remain as output.


• X6: For each invocation of attestation process, Csum is calculated based on the contents of the memory area [x, y]. Although Csum is guaranteed

to be computed correctly, it may or may not result in prover passing attestation test, if memory area [x, y] is previously tempered by the adversary.

Given the above assertions of CENSOR's attestation process, which shows that the key protection is guaranteed, and it assumes that verifier

receive and verify Csum successfully, we argue that the attestation process is performed securely. In any IoT network or IoT application domain,

security and privacy are the two major driving factors to ensure trust and allowing successful operations to satisfy end user services. To provide

security means providing data integrity, verification, and access control at various layers of the IoT architecture, while privacy includes the protec-

tion of the sensitive user data and the context around which the IoT data is collected. The CENSOR's attestation process provides authentication

of IoT devices along with the external verification that provide the integrity guarantees about the software running on the IoT devices. Therefore,

CENSOR ensures that the data sent by the IoT devices to the cloud data centers are collected using the non-malicious software installed in it. The

attestation of IoT devices and OF-switches also ensures that the data communication between the lowest level (IoT devices in IoT sub-networks)

to the highest level (ie, cloud data centers). Additionally, the availability of global topology at SDN-IoT controller can help the security applications

running on top of it to ensure the data communication security in the whole network. Finally, the security and privacy of the data that is stored and

processed at cloud data centers can be improved using various data anonymization and deduplication techniques.30

4.3 Security and communication reliability analysis of CENSOR

In this section, we present a discussion on the effectiveness of our secure CENSOR architecture, for tackling security and communication reliability

of the networking infrastructure in a large IoT network.

For analysis purposes, we consider a Smart City use-case as it is depicted in Figure 6. The security support in this case study is provided by

the SDN-IoT controllers {IC1, IC2, … , ICn} at control plane and OF-switches {OF1, OF2, … ,OFn} at the data plane. The SDN-IoT controller ICn,

OF-switches OFn, and IoT devices embeds and communicates using the “SMART aka security agent” based security module installed at both the

communication ends to ensure that the IoT devices at the device plane are secure from various external and internal attacks. To ensure that an

adversary does not temper the IoT device's sensing and transmitting modules, the OF-switches run periodic attestation process (similar to one we

proposed in our previous work31) that is well suited for such large-scale IoT networks.

Apart from the intra network security within an IoT sub-network, the primary use of the ICN is to provide inter-network security, ie, controlling

and analyzing the data communication in between different IoT sub-networks. For instance, the smart city use-case in Figure 6 consists of three

different IoT sub-networks (ie, smart home, smart car, and smart office) that might use heterogeneous devices and communication technologies

within their networks. Figure 6 shows that three networks are connected with each other through our CENSOR architecture.

In Figure 6, when a device from N3 such as a positioning system wants to communicate with the device(s) in network N1, then it first sends a

request to its edge OF-switch OFN3. After that, the OFN3 sends a message to the ICN3 and ask for a route to send the message(s) to an appliance

FIGURE 6 Use-Case: smart city


in N1. The ICN3 on receiving such a message checks the following: (i) Is the device asking route is registered to the OFN3 by checking the results of the

recent attestation process, and does the device has adequate permissions to send packets in network N1; (ii) Is the request message is legitimate

or not (based on the recent software and hardware integrity check done through remote attestation technique for OFN3 ); and (iii) whether the two

IoT devices are using the same communication protocols or not. If the OFN3 is secure and has the required permissions for this communication, but

both the networks are using different communication protocols, then the ICN3 (ie, the IoT controller) will create a set of rules that will convert the

messages received from N3 to the format understandable by N1. The ICN3 will provide these conversion rules to the other controller, ie, ICN1 of the

network, which then, with the help of the available global topology of the underlying IoT network (ie, in this case, smart city network) calculates a

set of message forwarding rules. The ICN3 and ICN1 will then install the conversion rules along with the forwarding rules on all the OFN3 and OFN1

that are part of the calculated route between N3 to N1 edge.

As it can be concluded from the example mentioned above that with the help of CENSOR architecture, we can achieve not only hierarchical

level of communication and data security, but also the communication reliability concerning scalability and hardware/software heterogeneity with

ease. Additionally, the use of SDN-IoT controller facilitates the required level of abstraction to the various IoT applications from the large-scale

heterogeneous IoT device plane networks.

The major design goals behind CENSOR can be summarized as follows.

• Facilitate the reuse of various IoT devices, which allow the rapid design and deployment of new IoT application domains and additional IoT

services within an existing domain;

• Increase the data, device, and communication security;

• Enable the networking between the heterogeneous networks, which will increase the scalability as well as communication reliability in the

large-scale IoT networks.

The CENSOR exhibits a hierarchical structure due to three main reasons: (i) it helps in efficient organization and improves utilization of the net-

work resources because each plane can be configured with clear set of responsibilities; (ii) it increases the modularization in the services which

leaves room for their expansion in future; and (iii) it abstract and hide the complexity and functionalities of lower plane, hence the data acquisi-

tion and processing can be significantly simplified as different applications can use the same data to provision different or new IoT services.32 The

openness and programmability are the main design principles of SDN-IoT, which it provides clearly by specifying the open programmable interfaces,

functionalities, and IoT services. We believe that the proposed architecture expands the horizontal marketplace, hence it will increase the inter-

operability and scalability in the overall IoT ecosystem. In the next section, we will discuss the feasibility of CENSOR concerning a set of research

challenges that need to be addressed while deploying it for practical IoT scenarios.

5 OPPORTUNITIES AND RESEARCH CHALLENGES

In this section, we discuss the benefits of using CENSOR and a set of research challenges that needs addressing for the design and development of the

integration mechanism, and the architecture in general. The benefits of using SDN paradigm along with fog-computing services in IoT infrastructure

can be summarized as follows.

• The device plane of IoT produces a massive amount of sensing data, and this data shares the existing Internet bandwidth to reach to the cloud

platform for processing, and thereafter be used for various IoT service compositions. In such a scenario, fog-computing services along with the

efficient and adaptive traffic engineering and routing techniques are required, to handle the big data generated by these billions of tiny devices,

and to utilize all the resources intelligently without creating any strain in the network. The SDN technology provides centralized access to dynam-

ically configure and control the network devices based on the intelligence gathered from the global network view. Hence it seems to be best

suited for such large scale IoT networks. Furthermore, with the integration of IoT and SDN paradigm, the essential services such as data security,

data acquisition, data analysis, decision making, and action implementation process becomes much simpler and faster.

• SDN paradigm helps in developing a scalable distributed system, which can easily manage billions of devices in IoT network. The control plane in

SDN can use multiple controllers (physically distributed but virtually connected with each other) each covering a number of sub-networks that

consists of IoT devices. The application developers can control all the IoT devices at once as the control services of each controller is still logically

centralized.

• The data plane of SDN can be easily used to provide the required hardware and data format abstraction to the IoT applications. It will improve

the resource utilization as multiple operators and IoT applications can use or reuse, the existing IoT network infrastructure to develop future

IoT services. It will further expand the much needed horizontal market which provides IoT services that are independent of a specific application

domain. Thus, it provides a better vision to next-generation IoT architectures.

• The logically centralized SDN controller can be effectively used for applying the much needed security policies on all or some of the networking

devices at once. In particular, SDN enhances security in network infrastructure with the centralized control of network services (such as routing,

security policies, and traffic engineering), global visibility of the network state, and the dynamic manipulation of traffic forwarding rules. In SDN,


updating security policies only require updating the security applications or adding new security services at control plan, rather than changing

the underlying network hardware or updating its firmware.

Being in the list of still developing architectures, SDN has its own set of communication challenges and limitations concerning scalability, security,

and deployment feasibility. From these, security has been on the forefront. The most vulnerable entities in the SDN are the centralized controller and

the communication channel between the data plane and the control plane. Since the centralized controller is responsible for managing the entire

network infrastructure, security attacks on the controller can adversely affect the whole network. Furthermore, security lapses in controller-to-data

communication channel due to the optional use of transport layer security (TLS) can lead to unwanted access and unauthorized usage of network

resources. To this end, the following research challenges that need to be addressed for driving an effective integration of SDN and IoT networks are

presented below.

• Security: In SDN, the logically centralized controller is responsible for managing and configuring the OpenFlow switches (OF-switches) at data

plane. These OF-Switches forward incoming packets based on match-action criteria. Thus, the matching process should be very fast to avoid any

delays in the communication process. The controller calculates and installs forwarding rules in routing tables of OF-switches which are usually

implemented using an expensive and power-hungry memory called TCAM. Therefore, the size of the routing table is limited, and in practice, it

cannot scale beyond few hundreds entries/rules.33 As a result, the OF-switch can only be able to process a limited number of flows per time

period. This limited size of the routing table is a potential weakness of SDN, and it is vulnerable to attackers. A sudden burst consisting of high

volume traffic can quickly consume the table capacity and overflow it. The continuing high amount of traffic can also make the switch to go down

permanently for certain period. Later, as a result of the shutdown, all the arriving packets will be discarded by the switch. In this way, the attackers

can quickly halt the functionalities of the OF-switches, ie, cripple the network services by mounting distributed denial of service (DDoS) attack.34

Furthermore, enhancing the controller's intelligence software may increase its vulnerability and attack surfaces for hackers. Because If attackers

have access to the controller, they can damage most of the major aspects of the network and eventually able to shut down the complete network.

Our proposed secure IoT architecture basically works with a main motive, which is to increase the data, device, and communication security

between the heterogeneous networks. Further, it will help to increase the scalability as well as communication reliability in the large-scale IoT

networks. As show in Figure 3, the SMART enabled SDN-IoT controller (IC) at control plane and the OpenFlow (OF) switches at data plane are

responsible to manage the complete process of data communication (from IoT devices to cloud data centers) in the proposed architecture. Dis-

tributed computing infrastructure (or fog computing) services connected with every IC are handled at the network edges. The goal of using the

fog nodes directly attached with the IC(s) is to improve efficiency and reduce the amount of data that needs to be transported to the cloud data

centers for processing, analysis, and storage. Use of fog computing services is often done for improving the efficiency (ie, reduce the bandwidth

consumption and end-to-end delay) of the network, but it could also be implemented for security and compliance reasons. The SMART enabled

fog computing supported SDN-IoT controller has the ability to act as IoT gateways, which applies the security policies and services through the

SMART enabled OF-switches. The fog enabled IC controller shall be able to support the OF-switches to control the flow tables, meters, and actions

to make communication in architecture more secure. A clear North Bound Interface (NBI) of the IC controller is described in order to ease the

integration of higher level applications. The IC is responsible for end-to-end security application and for monitoring of the current flows. Finally,

we can say that the proposed architecture is able to apply the desired security policies with regard to the detected adversarial behaviour in order

to mitigate them.

• Routing algorithm: In IoT, the communication is required between various entities such as: (i) machine-to-machine (M2M) communication, in which

an IoT device communicates with another IoT device on same or different network; and (ii) device to application communication, in which data

collected at device plane is routed to the cloud platform for service composition purposes. The CENSOR architecture requires a routing algorithm

that examines the state of two separate but overlapped topologies, ie, the underlying SDN topology consists of OF-switches and OF-gateways,

and the overlay IoT topology, ie, the network infrastructure consists of IoT devices at device plane. The routing algorithm needs to consider

various aspects such as control policies, security services, and resource availability. In particular, the routing protocol used should be resilient to

the multiple routing attacks such as blackhole, wormhole, sybil attack, relay attack, jamming, and eavesdropping. Therefore, a suitable algorithm

that effectively deals with these security threats and fulfills other requirements of the above IoT application has to be designed and evaluated,

to determine, how it fits with the overall objectives of the integrated communication system proposed in SDN-IoT architecture.

• Forwarding rules calculation: In M2M communications, the IoT controller has to entertain the communication requests received from the source

IoT devices. For such requests, the controller need to ensure that it calculates forwarding rules based on the nature of IoT services that the

underlying communicating IoT devices are providing. In particular, the integrated IoT controller(s) has to ensure that the formulation of these for-

warding rules is not direct, and it has to consider the different adaptations, mappings, underlying protocols, matching fields, and general actions

necessary to correctly forward a packet towards its destination. To this end, proper communication interfaces (ie, Northbound APIs) for the

integrated controller of IoT and SDN needs to be defined.

• Network scalability: IoT networks are sensitive to bandwidth due to resource contained IoT devices, and thus, the scalability of IoT networks is a

point of concern. While analyzing the scalability of IoT network, it is essential to consider the following: (i) network topology; (ii) controller pro-

cessing capacity; (iii) average arrival rate of forwarding rules installation requests; and (iv) the path inflation factor that depends on the distance

of the distributed controllers, channel capacity, and flow size. Another research challenge for integrated SDN and IoT architecture with respect

to scalability is the optimum controller placement. This has practical implications for software design, and it affects whether the controllers can


respond to events in real-time or they must push forwarding actions to OF-switches in advance. A reliability-aware controller placement problem

has been proposed in the work of Lange et al.35 In the work of Heller et al,36 authors propose a latency-aware controller placement problem with

the objective to provide an initial analysis for the further study of the formulation of fundamental design problems.

• Deep packet inspection: A limitation of OpenFlow is that it does not support the deep packet inspection (DPI).37 This is because it uses only the

packet header fields to process and evaluate a packet. The common usage of DPIs includes the lawful intercept, targeted advertising, and copy-

right enforcement. In IoT infrastructure, it is sometimes essential to thoroughly investigate the data part of the packet (as it contains the sensor

readings) as it passes an inspection point. Searching for protocol non-compliance or defined criteria to decide whether the packet may pass or

if it needs to be routed to a different destination are critical and essential to security. Also, to distinguish the suspicious flows for the purpose

of collecting statistical information needs DPI. Therefore, more advanced firewalls may need to sometimes examine and act on fields that are

not available to OpenFlow match and action. These concerns are not unique to IoT networks, and the research community38 should address the

same.

6 CONCLUSION

In this paper, we present a cloud-enabled secure IoT architecture based on the SDN paradigm. In support of the proposal, we argue that the flexibility

that SDN technologies offers can be used efficiently, to allow a large number of IoT devices from various heterogeneous networks to communicate

with each other reliably and securely. Resource-constrained nature of IoT devices and its limited communication abilities are significant factors that

will determine the shape of the future IoT networks and the protocols they use. In current scenarios, the IoT network requires specific protocols for

specific services which are incompatible with each other. Thus, it does not permit the IoT devices to interact efficiently. To address this problem, SDN

offers solutions in which new network services can be easily integrated with the underlying communication system. However, we have discussed

that this integration might expose the network to a new set of research challenges that must be resolved before advancing with the design of our

proposed architecture. These new challenges and research objectives could be seen as trivial when compared to the opportunities (ie, security,

scalability, and interoperability) that the integration will provide. Therefore, resolving the integration issues presented in the design of our proposed

CENSOR architecture would be a reasonably good starting point for the researchers working in this area.

ACKNOWLEDGMENTS

Mauro Conti is supported by a Marie Curie Fellowship funded by the European Commission (agreement PCIG11-GA-2012-321980). This work

is also partially supported by the EU TagItSmart! Project (agreement H2020-ICT30-2015-688061), the EU-India REACH Project (agreement

ICI+/2014/342-896), and by the projects “Physical-Layer Security for Wireless Communication”, and “Content Centric Networking: Security and Pri-

vacy Issues” funded by the University of Padua. This work is partially supported by the grant n. 2017-166478 (3696) from Cisco University Research

Program Fund and Silicon Valley Community Foundation. This work is also partially funded by the project CNR-MOST/Taiwan 2016-17 “Verifiable

Data Structure Streaming.”

ORCID

Chhagan Lal http://orcid.org/0000-0002-0051-1551

REFERENCES

1. Kreutz D, Ramos FM, Verissimo PE, Rothenberg CE, Azodolmolky S, Uhlig S. Software-defined networking: a comprehensive survey. Proc IEEE.2015;103(1):14-76.

2. Conti M, Droms R, Hassan M, Lal C. Fair-RTT-DAS: a robust and efficient dynamic adaptive streaming over ICN. Comput Commun. https://doi.org/10.1016/j.comcom.2018.07.033

3. Ahmad I, Namal S, Ylianttila M, Gurtov A. Security in software defined networks: a survey. IEEE Commun Surv Tutor. 2015;17(4):2317-2346.

4. Akyildiz IF, Wang P, Lin S-C. SoftAir: a software defined networking architecture for 5G wireless systems. Comput Netw. 2015;85:1-18.

5. Bera S, Misra S, Vasilakos AV. Software-defined networking for internet of things: a survey. IEEE Internet Things J. 2017;4(6):1994-2008.

6. Al-Fuqaha A, Guizani M, Mohammadi M, Aledhari M, Ayyash M. Internet of things: a survey on enabling technologies, protocols, and applications. IEEECommun Surv Tutor. 2015;17(4):2347-2376.

7. Nehra A, Tripathi M, Gaur MS, Battula RB, Lal C. TILAK: token-based prevention plan for threats against topology discovery using random KeyâAI. Int JCommun Syst. 2018. In press.

8. Ambrosin M, Busold C, Conti M, Sadeghi A-R, Schunter M. Updaticator: updating billions of devices by an efficient, scalable and secure software updatedistribution over untrusted cache-enabled networks. Paper presented at: 19th European Symposium on Research in Computer Security; 2014; Wroclaw,Poland. 2014.

9. Ambrosin M, Conti M, De Gaspari F, Poovendran R. Lineswitch: tackling control plane saturation attacks in software-defined networking. IEEE/ACM TransNetworking. 2016;25:1206-1219.

10. Conti M, Kaliyar P, Lal C. REMI: a reliable and secure multicast routing protocol for IoT networks. In: Proceedings of the 12th International Conferenceon Availability, Reliability and Security; 2017; Reggio Calabria, Italy.

http://orcid.org/0000-0002-0051-1551

http://orcid.org/0000-0002-0051-1551

https://doi.org/10.1016/j.comcom.2018.07.033

https://doi.org/10.1016/j.comcom.2018.07.033


11. Macedo D, Guedes LA, Silva I. A dependability evaluation for Internet of Things incorporating redundancy aspects. In: Proceedings of the 11th IEEEInternational Conference on Networking, Sensing and Control; 2014; Miami, FL.

12. Bizanis N, Kuipers FA. SDN and virtualization solutions for the internet of things: a survey. IEEE Access. 2016;4:5591-5606.

13. Gonzalez C, Flauzac O, Nolot F, Jara A. A novel distributed SDN-secured architecture for the IoT. Paper presented at: 2016 International Conference onDistributed Computing in Sensor Systems (DCOSS); 2016; Washington, DC.

14. Sydney A. The evaluation of software defined networking for communication and control of cyber physical systems [Ph.D. dissertation]. Manhattan, KS: KansasState University; 2013.

15. Qin Z, Denker G, Giannelli C, Bellavista P, Venkatasubramanian N. A software defined networking architecture for the internet-of-things. Paperpresented at: IEEE Network Operations and Management Symposium (NOMS); 2014; Kraków, Poland.

16. Jararweh Y, Al-Ayyoub M, Darabseh A, Benkhelifa E, Vouk M, Rindos A. SDIoT: a software defined based internet of things framework. J Ambient IntellHumaniz Comput. 2015;6(4):453-461.

17. Sahoo KS, Sahoo B, Panda A. A secure SDN framework for IoT. Paper presented at: 2015 International Conference on Man and Machine Interfacing(MAMI); 2015; Bhubaneswar, India.

18. Flauzac O, Gonzalez C, Nolot F. New Security Architecture for IoT Network. Procedia Comput Sci. 2015;52:1028-1033.

19. Chakrabarty S, Engels DW. A secure IoT architecture for smart cities. Paper presented at: 13th IEEE Annual Consumer Communications and NetworkingConference (CCNC); 2016; Las Vegas, NV.

20. Balfour RE. Building the Internet of Everything (IoE) for first responders. In: Systems, Applications and Technology Conference (LISAT); 2015; IEEE LongIsland.

21. Ukil A, Sen J, Koilakonda S. Embedded security for Internet of Things. Paper presented at: 2nd National Conference on Emerging Trends and Applicationsin Computer Science; 2011; Shillong, India.

22. Tajiki MM, Akbari B, Shojafar M, et al. CECT: computationally efficient congestion-avoidance and traffic engineering in software-defined cloud datacenters. 2018. arXiv preprint arXiv:1802.07840.

23. Vinueza Naranjo PG, Pooranian Z, Shojafar M, Conti M, Buyya R. FOCAN: a fog-supported smart city network architecture for management ofapplications in the internet of everything environments. 2018. arXiv preprint arXiv:1710.01801.

24. Chiaraviglio L, D'Andreagiovanni F, Lancellotti R, Shojafar M, Melazzi NB, Canali C. An approach to balance maintenance costs and electricity consump-tion in cloud data centers. IEEE Trans Sustain Comput. 2018.

25. Brasser F, El Mahjoub B, Sadeghi A-R, Wachsmann C, Koeberl P. TyTAN: tiny trust anchor for tiny devices. In: Proceedings of the 52nd Annual DesignAutomation Conference; 2015; San Francisco, CA.

26. El Defrawy K, Perito D, Tsudik G, Francillon A. SMART: secure and minimal architecture for (establishing dynamic) root of trust. In: Proceedings of the19th Annual Network and Distributed System Security Symposium; 2012; San Diego, CA.

27. Ambrosin M, Conti M, Lazzeretti R, Rabbani M, Ranise S. PADS: practical attestation for highly dynamic swarm topologies. In: Proceedings of the 7thInternational Workshop on Secure Internet of Things (ESORICS 2018 Workshop: SIoT 2018); 2018; Barcelona, Spain. In press.

28. Ibrahim A, Sadeghi A-R, Zeitouni S. SeED: cure non-interactive attestation for embedded devices. In: Proceedings of the 10th ACM Conference onSecurity and Privacy in Wireless and Mobile Networks; 2017; Boston, MA.

29. Kohnhäuser F, Büscher N, Gabmeyer S, Katzenbeisser S. SCAPI: a scalable attestation protocol to detect software and physical attacks. In: Proceedingsof the 10th ACM Conference on Security and Privacy in Wireless and Mobile Networks; 2017; Boston, MA.

30. Pooranian Z, Chen K-C, Yu C-M, Conti M. RARE: Defeating Side Channels based on Data-Deduplication in Cloud Storage. In: Proceedings of the 7thInternational Workshop on Cloud Computing Systems, Networks, and Applications (IEEE INFOCOM 2018 Workshop: CCSNA 2018); 2018; Honolulu,HI. In press.

31. Moreno A, Conti M, Ibrahim A, Neven G, Sadeghi A-R, Schunter M. SANA: secure and scalable aggregate network attestation. In: Proceedings of the2016 ACM SIGSAC Conference on Computer and Communications Security; 2016; Vienna, Austria.

32. Thubert P, Palattella MR, Engel T. 6TiSCH centralized scheduling: when SDN meet IoT. Paper presented at: IEEE Conference on Standards forCommunications and Networking (CSCN); 2015; Tokyo, Japan.

33. Sood K, Yu S, Xiang Y. Software-defined wireless networking opportunities and challenges for internet-of-things: a review. IEEE Internet Things J.2016;3(4):453-463.

34. Mohammadi R, Javidan R, Keshtgary M, Conti M, Lal C. Practical extensions to countermeasure DoS attacks in software defined networking. Paperpresented at: IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN); 2017; Berlin, Germany.

35. Lange S, Gebert S, Zinner T, et al. Heuristic approaches to the controller placement problem in large scale SDN networks. IEEE Trans Netw Serv Manag.2015;12(1):4-17.

36. Heller B, Sherwood R, McKeown N. The controller placement problem. In: Proceedings of the First Workshop on Hot Topics in Software DefinedNetworks; 2012; Helsinki, Finland.

37. Finnie G. The role of DPI in SDN work. 2012. QOSMOS Technology. White Paper.

38. Mekky H, Hao F, Mukherjee S, Zhang Z-L, Lakshman TV. Application-aware data plane processing in SDN. In: Proceedings of the Third Workshop on HotTopics in Software Defined Networking; 2014; Chicago, IL.

How to cite this article: Conti M, Kaliyar P, Lal C. CENSOR: Cloud-enabled secure IoT architecture over SDN paradigm. Concurrency

Computat Pract Exper. 2019;31:e4978. https://doi.org/10.1002/cpe.4978

https://doi.org/10.1002/cpe.4978

censor: cloud‐enabled secure iot architecture over sdn...

Documents