flexible iot security middleware for end-to-end cloud-fog...
TRANSCRIPT
Flexible IoT Security Middleware
for End-to-End Cloud-Fog Communication
Bidyut Mukherjeea, Songjie Wangb, Wenyi Lua, Roshan Lal Neupanea,Daniel Dunna, Yijie Rena, Qi Sua, Prasad Calyamb
a{bm346, wldh6, rlnzq8, dpdbp7, yry7d, qsn4c}@mail.missouri.edub{wangso, calyamp}@missouri.edu
Abstract
IoT (Internet of Things) based smart devices such as sensors have been ac-tively used in edge clouds i.e., ‘fogs’ along with public clouds. They providecritical data during scenarios ranging from e.g., disaster response to in-homehealthcare. However, for these devices to work effectively, end-to-end se-curity schemes for the device communication protocols have to be flexibleand should depend upon the application requirements as well as the resourceconstraints at the network-edge. In this paper, we present the design andimplementation of a flexible IoT security middleware for end-to-end cloud-fogcommunications involving smart devices and cloud-hosted applications. Thenovel features of our middleware are in its ability to cope with intermittentnetwork connectivity as well as device constraints in terms of computationalpower, memory, energy, and network bandwidth. To provide security duringintermittent network conditions, we use a ‘Session Resumption’ algorithm inorder for our middleware to reuse encrypted sessions from the recent past,if a recently disconnected device wants to resume a prior connection thatwas interrupted. In addition, we describe an ‘Optimal Scheme Decider’ al-gorithm that enables our middleware to select the best possible end-to-endsecurity scheme option that matches with a given set of device constraints.Experiment results show how our middleware implementation also providesfast and resource-aware security by leveraging static properties i.e., staticpre-shared keys (PSKs) for a variety of IoT-based application requirementsthat have trade-offs in higher security or faster data transfer rates.
Keywords: IoT Security Middleware, Mobile Edge Cloud, Cloud-FogCommunication, Secure IoT Applications
Preprint submitted to Future Generation Computer Systems December 28, 2017
1. Introduction1
Internet of Things (IoT) systems typically comprise of a network of con-2
nected devices or “things”. The term “thing” here can constitute any smart3
device ranging from sensor devices in automobiles, bio-chemical sensing de-4
vices in homeland security, to heart monitoring devices inside of a human5
body. In fact, any object that has the ability to collect and transfer data6
across the network to an edge or core cloud computing platform can be a7
part of an IoT system. As mentioned in [1], emerging IoT system trends are8
set to completely change the way businesses, governments, and consumers9
interact with each other, and transact in a data-driven economy.10
As a specific example, an IoT system of Geo Sensors could involve col-11
lection of various kinds of geographical information related to soil, forest12
terrains, and weather. The collected data is continually sent to nearby edge13
clouds or ‘fog computing platforms’ for aggregation and drill-down analy-14
sis/visualization. Similarly, smart devices in IoT systems can also provide15
critical data during e.g., disaster response scenarios or in-home healthcare.16
An exemplar application of an IoT system used for disaster response is17
Panacea’s Cloud [2, 3, 4]. Such systems aid in providing medical triaging18
and quick response during emergency disaster situations. The Panacea’s19
Cloud system involves many distributed IoT devices transmitting data from20
various locations in a disaster region to a responding personnel’s handheld21
device, which in turn utilizes a mobile cloud-fog setup that provides intelli-22
gent dashboard visualizations. Considering the in-home healthcare applica-23
tion scenario, IoT systems such as [5, 6] are aimed at providing emergency24
services to the elderly, if the need arises. These involve smart sensors and25
cameras using cloud-fog storage for keeping track of movements made by the26
elderly. The IoT system here could use cloud-fog computation for algorithms27
that help notify primary care contacts if an elder’s gait signature appears to28
contain certain types of anomaly events that suggest high fall risk.29
We can see that the above IoT-based applications can have broad use30
cases involving diverse infrastructure configurations and data/resource se-31
curity requirements. Consequently, ad-hoc communication protocol imple-32
mentations with undesirable security overheads are not suitable. Consider33
the aforementioned case of disaster response systems [3]; the edge network34
here comprises of IoT devices that typically operate in resource-constrained35
(compute, memory, storage, network, energy) environments. Such systems36
could become highly unstable and unreliable due to physical infrastructure37
2
damage or lossy edge links when there are extreme events such as hurricanes,38
tornadoes or earthquakes. The IoT system security in this case needs to be39
configured such that the security overhead of the communication protocols40
does not impede the already slow data transfer speeds due to constrained41
edge resources and infrastructure.42
Alternately, the above IoT systems for providing in-home healthcare, as43
in [5, 6] may have access to fully functional edge infrastructure including44
Gigabit fiber connections (e.g., Google Fiber) to user sites and a set of fog45
resources at a nearby hospital data center. In such cases, the available re-46
sources can be readily used to handle the big data generated from patient47
homes (typically up to 23GB/Person/Week). The IoT system security for48
this application case involving elderly patient data needs to be configured for49
maximum data confidentiality and integrity, even if data transfer speeds are50
affected due to security overhead of the communication protocols.51
In this paper, we address the wide-ranging IoT-based application secu-52
rity needs and diverse network-edge resource constraints by proposing a novel53
design of a flexible IoT security middleware for end-to-end cloud-fog commu-54
nication. Our goal is to primarily secure the network located at the user55
fogs, i.e., where the IoT devices are located. However, we also seek to main-56
tain security compatibility with an existing core cloud network using System57
Level or Application Level deployment considerations of our middleware.58
The salient features of our IoT security middleware, which form the main59
paper contributions of our work are in its ability to provide: (i) ‘Intermittent60
Security’, and (ii) ‘Resource-aware Security’ for smart devices and cloud-61
hosted applications. Pertaining to Intermittent Security, our middleware uses62
a Session Resumption algorithm in order to reuse encrypted sessions from63
recent past, if a recently disconnected device wants to resume a prior con-64
nection that was interrupted due to an unreliable network connection. With65
regards to Flexible Security, our middleware uses a novel Optimal Scheme66
Decider algorithm that allows users to configure the best possible end-to-67
end security scheme option that matches with a given set of device resource68
constraints. Through application resource-awareness obtained via supervised69
machine learning (versus blindly following a rigid/adhoc security configura-70
tion), our middleware enables users to configure either higher security or71
prioritize faster data transfer rates, via RESTful APIs for data collection at72
a cloud or a fog site.73
We validate our middleware implementation’s ability to provide robust,74
fast and resource-aware security through experiment results in an actual75
3
cloud-fog testbed, as well as through simulation results. Results also show76
that our work lays a foundation for promoting increased adoption of static77
properties such as Static PSKs that can handle the trade-offs in high security78
or faster data transfer rate requirements within IoT-based applications.79
The remainder of this paper is organized as follows: In Section 2, we dis-80
cuss related work. In Section 3, we provide an overview of our middleware81
and provide a detailed description of our approach with a corresponding refer-82
ence architecture. Section 4 elaborates on our Intermittent Security solution83
and details our Session Resumption algorithm. Next, Section 5 discusses84
our Resource-aware Security solution and details our Optimal Scheme De-85
cider algorithm. Section 6 evaluates the effectiveness of our middleware and86
compares the performance of an IoT-based application with-and-without our87
middleware. Section 7 concludes this paper and suggests future work.88
2. Related Work89
The core concepts of IoT related sensing and communication have been90
outlined in prior works such as [7] and [8]. Authors in [7] identify that IoT91
systems need to implement a shared understanding of the situation of users92
and their devices with context-awareness. Thus, a requirement for IoT-based93
sensing systems design including security needs to address adaptation re-94
quirements to cope with dynamic contexts and varied application platforms.95
Similarly, authors in [8] identify the high-level abstractions and interoperabil-96
ity needs to ensure proper security in the form of confidentiality, integrity97
and availability, as well as to bridge the gap between IoT (i.e., constrained98
edge) and enterprise (i.e., unconstrained core cloud) communications.99
From the perspective of frameworks that address IoT related sensing and100
communication issues, prior work such as [9] and [10] have focused on smart101
city applications. In [9], data service models to deal with real-time data102
analysis are presented along with a tiered security service to handle data103
transmissions. The proposed framework supposes that communication be-104
tween IoT sensors and the application back-end (i.e., in an agricultural data105
analysis use case) needs to be ad-hoc and fast, while security design needs106
to be flexible to handle time-sensitivity or content-sensitivity. In contrast,107
a case for scalability and plug-in components in IoT-based applications is108
presented in [10], and a flexible framework design similar to our security109
middleware is presented. The authors list challenges in handling differences110
in communication protocols between the IoT devices and the edge gateway.111
4
IoT-based application deployment is a relatively new trend, however meth-112
ods to secure networked IoT devices have been explored in the past. Work113
in [11] discusses security procedures for constrained IoT devices. An archi-114
tecture to offload computation intensive tasks to the gateway is proposed,115
which helps in reducing the cost of security encryptions at the IoT node side.116
However, offloading at a large scale is a tedious task as mentioned in [12].117
In [13] and [14], the authors propose lightweight authentication schemes that118
can be used in the context of IoT systems and constrained wireless sensor119
networks. In comparison, our work investigates a security middleware which120
makes use of static Pre-Shared Keys (PSKs) that is different from the multi-121
phase encryption and decryption used in earlier works. We phase down to122
just one iteration for lightweight authentication. Consequently, our approach123
reduces security overhead in the cloud-fog communication protocols and is124
less time consuming in an IoT-based application deployment.125
Work in [15] addresses issues in session key management for IoT-based ap-126
plications, particularly concerning health-care sensors. The authors devised a127
secure end-to-end protocol for resource-constrained devices by adapting secu-128
rity functionality used in unconstrained devices, but without computationally129
intensive operations. They offloaded heavy computation at constrained de-130
vices to neighboring trusted nodes/devices. Their session key creation, how-131
ever, was ephemeral. Similarly, authors in [16] provide methods to offload132
security computation from devices to the edge cloud. Our work builds on133
top of these works, and uses an easier, yet effective key management scheme.134
Specifically, we create static keys which are not short-lived, reducing the key135
exchange cost and time significantly.136
Our work is closely related to prior work in [17, 18], where the same137
authors developed security schemes for mobility-enabled healthcare IoT sys-138
tems. They outline architectures that are based on certificate-based DTLS139
handshake. In addition, their scheme utilizes the session resumption concept140
for communication, and proposes system mobility through interconnected141
smart gateways. Our work extends this highly relevant work to incorpo-142
rate flexibility and resource-awareness in the security scheme configuration143
for IoT-based applications that function in both austere and smart network144
environments.145
A comprehensive session resumption mechanism is discussed in [19]. The146
work uses HIP DEX i.e., Host Identity Protocol Diet EXchange which pro-147
vides secured end-to-end connections in IoT systems. Perfect forward se-148
crecy and non-repudiation properties of HIP result in significantly decreased149
5
protocol handshake overhead and reduced handshake run-time. Storage of150
session state after session tear-down enables efficient re-authentication and151
re-establishment of a secure payload channel in an abbreviated session re-152
sumption handshake. Our work utilizes the concept of session resumption153
but makes a few changes for broader compatibility. Instead of HIP, we utilize154
Device ID, which can additionally act as a static unique device property.155
We encountered use of different encryption techniques in earlier works. As156
an exemplar, work in [20] makes use of Physical Unclonable Functions (PUF)157
over public key cryptography, which takes advantage of existing physical158
properties of a device. They utilize Physical Key Generation (PKG) that159
use physical properties of the communication channel, and is lighter than160
common public-key cryptography. Along the same lines, work in [21] aims for161
lightweight user authentication and key agreement protocol implementation,162
but relies heavily on use of smart cards. Our work extends upon such works163
to use physical properties of the devices, and is able to forgo re-authentication164
by using session resumption.165
Authors in [22] give a standard security compliant framework to secure166
the IEEE 802.15.4 networks in low power lossy network (LLNs). The frame-167
work supports five different levels of security with their proposed security168
configurations (i.e., Fully Secured, Unsecured, Partial Secured, Hybrid Se-169
cured and Flexible Secured). Flexible secured configuration has the potential170
to change the level of security based on requirements when needed, and shifts171
from full secured state to hybrid secured state. However, the approach is not172
quite scalable since re-entry of device request is not supported. This is a gap173
that can be filled by the presence of a flexible, dynamic security middleware174
to act as an interface for fast or secure encrypted communication. Hence, our175
work takes the security framework, specifically the concept of Resource-aware176
Security, a step further towards practical use within IoT-based applications.177
3. IoT Security Middleware Overview178
In this section, we first describe our vision of the physical infrastructure179
necessary to deploy our middleware that builds upon our previous work [23].180
Following this, we list the various modules in our middleware and explain181
the interactions of our middleware with a cloud gateway and a smart device.182
Lastly, we discuss practical deployment considerations for the deployment of183
our middleware in an IoT system.184
6
GATEWAY
CORE CLOUD
WIRELESS NETWORK
MID
DLE
WA
RE
MID
DLE
WA
RE
EDGE CLOUD/FOG
Figure 1: IoT system architecture - Core Cloud along with the Gateway forms an un-constrained network, whereas Gateway along with the IoT devices forms a constrainednetwork segment [23]
.
3.1. Physical Infrastructure185
Figure 1 illustrates a physical infrastructure view to integrate our mid-186
dleware in an IoT system that involves cloud-fog communication. The in-187
frastructure primarily consists of a core cloud infrastructure, a gateway, and188
several edge IoT devices. The core cloud has a communication channel with189
gateways at the network-edge. The edge gateways form an interface to the190
network for the IoT devices. Parts of the primary middleware need to be191
installed on both the gateway and the fog IoT devices. The fog network192
can constitute any number or type of IoT devices, such as heart monitor,193
beacon, geo sensor, etc. The primary middleware allows secure and fast data194
transfer between the sensor devices and the gateway by using the “Intermit-195
tent Security” feature to ensure robustness against frequent disconnections,196
and by using security schemes chosen through our “Resource-aware Security”197
module. To realize these benefits, our middleware stores and tracks sessions,198
certificates, or keys, between both the fog and the gateway. Once data has199
been securely transferred to the gateway, it handles the translation of pro-200
tocols to allow compatibility between the core cloud protocols and the IoT201
device protocols.202
Optionally, secondary middleware can be integrated between the gateway203
and the core cloud to provide additional flexibility and robustness, if needed.204
There is a key benefit of having this integration setup. The presence of inter-205
7
mediate gateways allows for decoupling of services and protocols between the206
cloud-gateway and gateway-iot subnets, essentially paving way for end-to-end207
security via our intermediate middleware. Our ideal integration consists of208
a middleware piece in the core cloud network side, and another middleware209
piece at the fog network side. Each middleware piece consists of a server-210
client pair interacting with just each other. At the gateway, the client of the211
cloud interacts with the server of edge, allowing end-to-end secured communi-212
cation. Our middleware additionally supports device resource-aware security213
by accommodating different protocols for individual nodes in the fog net-214
work, in addition to being accessible to use static PSKs for quick encryption215
setup, and support for intermittent security through session resumption.216
We suppose in Figure 1 that smart applications that are based on IoT217
data from e.g., sensors collect contextual data at large scales from several218
geographically distributed fog/edge locations. Our middleware helps in se-219
cure integration and analysis of such data using cloud platforms and wireless220
communication networks for actionable insights. Our middleware can be221
useful in cases where custom application dashboards in e.g., public safety,222
transportation or rural healthcare require secure data import and export223
in a cloud and fog communications infrastructure to deal with IoT devices224
with varying trust, resource constraints and wireless network reliability. The225
middleware can be customized in rural areas or in the middle of areas with226
sparse/intermittent wireless connectivity, where strict security requirements227
might lead to channel bandwidth consumption overheads or fast drainage of228
constrained device resources. This in turn might block data access from IoT229
devices, or cause data integrity issues that lead to discarding of important230
data in some cases. Thus, our middleware addresses the lack of flexible trust231
management in today’s smart applications in a manner that can enable data232
collection with minimal viable security. Consequently, it helps with real-time233
IoT device data ingest into a cloud from both trusted and un/low-trusted234
devices to facilitate follow-up actions by decision makers at the fog sites.235
3.2. Logical Modules236
A modular diagram of our proposed middleware is shown in Figure 2.237
The involved devices keep track of (D)TLS sessions, PSKs, and the Device238
IDs. The security association occurs first by letting the Intermittent Se-239
curity module (see Section 4 for details on the background, algorithm and240
implementation) try and resume a past connection, by first verifying ses-241
sion existence and validity. If the resumption fails, Resource-aware Security242
8
Intermittent Security Module
SessionPSK*
Device ID
IoT Node
Gateway
Session Verifier
Session Serializer
Session Resumer
Resource-aware Security Module
AuthenticatorMAC Algorithm
Encryption Cipher
(D)TLS
SessionPSK*
Device ID
*Recommended, over Certificates
Middlew
are
Figure 2: End-to-End IoT Security Middleware Module Diagram
[23]
module (see Section 5 for details on the background, algorithm and imple-243
mentation) acts as an interface to allow configuration of required security244
schemes. These two modules in conjunction form the middleware.245
246
Our middleware allows flexibility of security through various available247
protocols. The reasoning behind providing flexibility is because all applica-248
tions and devices are not built with same level of security in mind. There is a249
trade-off between security and speed when it comes to a preset of a security250
protocol. High level of security is usually desired, but not always needed.251
Based on the application, it might be detrimental to have full-fledged secu-252
rity. For instance, if an edge beacon (based on e.g., iBeacon technology) is253
transmitting confidential medical information, the data security is a major254
priority. However, if the same beacon is to be reused for emergency medical255
triage, the priority for speed and low power consumption goes up, at the256
expense of high security.257
9
3.3. Deployment258
In practical IoT system deployments, the middleware can be installed at259
both the System Level and Application Level. A System Level installation260
could involve integrating the features of the middleware into the Operating261
System services of the device, ideally by the device manufacturer or software262
developer. This approach allows an application developer to incorporate the263
features of the middleware for customization by users. On the other hand,264
Application Level installation can allow an application developer to directly265
integrate the middleware features into the application logic. This approach266
could be useful if full device control is not available at the Application Level.267
4. Intermittent Security268
4.1. Solution Approach269
Intermittent security utilizes session resumption to quickly bring a discon-270
nected device back in the network when needed again. This concept closely271
follows the ideas proposed in [19], and but we consider a few modified fac-272
tors. Our middleware implements intermittent security using a “Device ID”,273
instead of using the Host Identity Protocol (HIP). This allows compatibility274
with a broader range of device types. The device IDs of the edge nodes are275
managed by the nearest hop gateway. (D)TLS sessions are stored by the276
devices on disconnection for future use. If such a recently disconnected edge277
node attempts to make a connection with the gateway, the gateway uses278
the client Device IDs to determine the session to resume for that requesting279
node. This module allows fewer security handshake steps that result in time280
savings, and the data to be transmitted can still successfully be transferred281
without compromising security.282
A possible major concern in a session resumption implementation is the283
possibility of Replay Attacks [24]. Given that the serialized sessions are tied284
to the property of the device, i.e., the Device ID, replaying using the same285
session is made extremely difficult by any malicious device, almost certainly286
having a different Device ID. To prevent an active session from being replayed287
by a spoofing device, a simple flag is sufficient to block such replay requests.288
Data Encryption is commonly done using keys established through Public289
Key Cryptography (PKC). Instead of using PKC, our middleware chooses to290
leverage static elements such as Static Pre-shared Key (PSK) or Certificates.291
This is because PKC can be quite slow, in addition to being intensive in292
terms of time, computation, bandwidth, and memory resources, [20]. Despite293
10
Resume Session
Resource-aware Security Scheme
Session
Data prep
Session Resumption Success?
Device Storage
No
Reuse session
Yes
Ser
ializ
e S
essi
onS
erialize S
ession
Data transmit
Figure 3: Illustration of Intermittent Security handling with Session Resumption [23]
lacking in nonce and entropy compared to ephemeral schemes, static PSKs294
still are capable of providing a reasonable level of encryption using the user’s295
choice of cipher, such as block or stream ciphers. Hence, it is a preferable296
scheme for most use cases, allowing a tradeoff balance between speed and297
security requirements of an IoT-based application [25].298
4.2. Logic Implementation299
Figure 3 shows a flowchart illustration of how our middleware leverages300
intermittent security with session resumption for quick data transmission.301
A contingent flexible security scheme is used to quickly establish lost con-302
nections with the fastest possible way, based on the security needs of an303
IoT-based application. Algorithm 1 shows our pseudocode for providing in-304
termittent security. The main() function gets executed first, to check whether305
the connection between the associated devices is being made for the very first306
time. Or, if there already is a valid session corresponding to these devices.307
If so, we can simply fetch the stored session from device storage and at-308
tempt to resume it, allowing quick reconnection between them. If not, a new309
connection has to be established with device resource-awareness i.e., based310
on chosen protocol, authentication scheme, encryption scheme, and message311
authentication code algorithm, a new session would be initiated.312
11
Once a session has been found (either new or resumed), two operations313
occur in parallel: First, serializeSession() ensures that the current session314
state is serialized to the device storage every few seconds, as represented315
by variable x. Based on the need, the value of x can be made higher or316
lower. Higher value of x would result in more frequent writes to the storage,317
providing more reliability for future session resumptions at the expense of318
using higher computation and storage. Conversely, less frequent writes would319
be less reliable, but faster and resource conservative. Second, transmit()320
keeps data flow active between the connected devices.321
12
Algorithm 1: Intermittent Security HandlerData: Device ID dID. Protocol p, either DTLS or TLSData: Authentication Scheme auth, Encryption Scheme enData: Message Authentication Code macData: session variable holds encrypted session infoData: stored session holds deserialized session fetched from device storageData: first connect is true if this is the first time connecting
Result: The latest session is stored on the respective devices to be quicklyresumable
function initSession ()/* Creates a new session from specified configuration */session ← flex security vector(dID, {p, auth, en, mac})
endfunction resume ()
/* Pulls the stored session and uses it as new session */session ← stored session
endfunction serializeSession (x)
/* Store the session in storage of member devices */while true do
sleep (x)stored session ← session
endendfunction main ()
/* Decide and create or resume a session */if firstConnect or stored session.isNull then
initSession()else
resume()endserializeSession()transmit()
end
322
13
Figure 4: Illustration of Resource-aware Security handling with Protocol Selection [23]
5. Resource-aware Security323
The first step for security association and communication initiation is324
selection of the security protocols to be used. Our middleware supports dif-325
ferent kinds of protocols and allows switching between them. The possible326
choices all select one of the options in each category. The categories include:327
(i) Protocol, (ii) Authentication Scheme, (iii) Bulk Encryption Scheme, and328
(iv) Message Authentication Code (MAC) algorithm as shown in Figure 4.329
330
Protocol Selection: The Protocol selection allows a choice between {TLS,331
DTLS}. TLS (Transport Layer Security) and DTLS (Datagram Transport332
Layer Security) are both extremely secure protocols enforcing network en-333
cryption between participants. Both of these protocols ensure confidentiality334
and integrity of data. DTLS is a better choice for stream-based applica-335
tions, and can work over UDP (User Datagram Protocol). For use with TCP336
based applications, TLS is the preferred choice. The difference in perfor-337
mance and bandwidth requirements of TLS and DTLS can get noticeably338
high when adding the impact of the ideal authentication, encryption, and339
MAC schemes.340
14
Authentication Scheme Selection: Authentication Scheme can be either {PSK,341
Certificate}. Furthermore, each of these entities can be either {Ephemeral,342
Static}. Ephemeral PSKs or Certificates require full security handshake343
and key exchange before use. On the other hand, Static authentication344
elements do not require repeated key exchange, and hence can save a sig-345
nificant amount of time and bandwidth. In our middleware, if PSK is found346
to be an ideal candidate, the default setup goes for Static PSK. In fact,347
Static PSK can exist as a device property on the IoT devices, allowing many348
benefits such as: quick connection, resumption, low memory footprint, low349
bandwidth consumption, and low CPU usage. If the requirement is for even350
higher security, ephemeral PSK or Certificate can be generated using Key351
Exchange algorithms, such as RSA, or DH (Diffie-Hellman).352
353
Bulk Encryption Scheme Selection: Once authentication is chosen, the Bulk354
Encryption scheme is the next option. Encryption can be done using ei-355
ther Block Ciphers, or Stream Ciphers. Block Ciphers are useful for sending356
large chunk of data, and can consume a significant amount of bandwidth and357
memory if the payload is small. This is due to the padding added to each358
block of data being sent. For example, AES uses 128-bit (16-byte) padding359
by default. If the data being transmitted is 1024-bit in length, then the total360
packets sent would be d1024/128e = 8. But, if the data size is 130-bit, the361
number of packets sent would be d130/128e = 2. The second packet would362
have 126 empty reserved bits. Hence, for small payload applications (such363
as video streams) it is better to opt for Stream Cipher, which encrypts small364
chunks of data before sending. The most common Stream Cipher is RC4,365
but ChaCha20 is starting to take over as the next generation of much faster366
and more secure stream ciphers. All ciphers can be configured to various key367
sizes (if applicable), including 128-bit, 224-bit, 256-bit, and so on.368
369
Message Authentication Code Selection: Lastly, the chosen Message Authen-370
tication Code algorithm is used to generate a checksum, to ensure integrity371
of data being sent. The available options are MD5, SHA {1/2/3}, and a372
few lesser-used options. SHA2 or SHA3 should be used whenever possible,373
since MD5 and SHA1 have been found to be vulnerable to various checksum374
attacks [26, 27] and collision attacks [28]. Through permutation and combi-375
nation, the possible choices for the security scheme can be a large collection.376
Tables 1 shows a subset of candidate security schemes, and Table 2 provides377
a brief description for each of these schemes.378
15
Table 1: A subset of candidate security schemes for resource-aware security
Security Scheme Protocol Authentication Encryption MAC
DTLS PSK WITH CHACHA20 SHA256 DTLS Static PSK ChaCha20 SHA2(256)
DTLS DHE WITH NULL SHA384 DTLS Certificate - SHA2(384)
DTLS DHE PSK WITH 3DES EDE SHA DTLS PSK 3DES (EDE) SHA1
TLS PSK WITH AES 128 CBC SHA TLS Static PSK AES128(CBC) SHA1
TLS PSK WITH CHACHA20 POLY1305 TLS Static PSK ChaCha20 POLY1305
TLS ECDHE WITH AES 256 GCM SHA384 TLS Certificate AES256(GCM) SHA2(384)
Table 2: Key use-cases and description of schemes in Table 1 for resource-aware securitySecurity Scheme Description
DTLS PSK WITH CHACHA20 SHA256 Very fast, secure. Excellent for secure video streaming
DTLS DHE WITH NULL SHA384 Fast scheme, high security
DTLS DHE PSK WITH 3DES EDE SHA Fast, but risk of integrity loss due to SHA1
TLS PSK WITH AES 128 CBC SHA Fast, highly secure, suitable for moderately heavy data
TLS PSK WITH CHACHA20 POLY1305 Fast, highly secure, suitable for quick bulk data transfer
TLS ECDHE WITH AES 256 GCM SHA384 Very high security, suitable for confidential data on a reliable network
5.1. Solution Approach379
As discussed in the previous subsection, our middleware allows picking380
and choosing of security protocol components (e.g., bulk encryption, message381
authentication) as per the user’s requirements. However, when it comes to382
actually choosing the best scheme option for an application context, the deci-383
sion process is quite difficult. It can be even more onerous given the fact that384
not every user might be well versed with the various security components, or385
have a strong understanding of the differences between the various schemes,386
their advantages or disadvantages. Consequently, users need to be presented387
with relevant information of suitable options to choose the best scheme op-388
tion. To assist in this difficult decision process, the Optimal Scheme Decider389
solution of our middleware becomes relevant. We found ∼200 possible secu-390
rity scheme choices (that result from combinations of various protocol com-391
ponents) that the Optimal Scheme Decider needs to be analyze to find the392
optimal choice of security scheme for a given IoT-based application context.393
As part of the solution approach, we use supervised machine learning that is394
done in two phases: (i) Offline Phase, and (ii) Online Phase.395
16
5.1.1. Offline Phase396
The Offline Phase is a step used to narrow down the searchable space397
of security schemes by filtering our ∼200 scheme set database. Although398
the schemes can be quite varied, there exist many schemes that have close399
similarities in practical aspects. Moreover, it is possible to find alternative400
schemes to any chosen scheme when the requirements and priorities are ad-401
justed according to the needs of the application. Hence, it turns out, every402
permutation or combination of protocol components is not a necessary option403
for IoT-based application developers. In fact, as shown in Figure 5, we are404
able to group security schemes based on their protocol choices.405
Application Requirements
TLS DTLS
No Session Resumption Session Resumption No Session
Resumption
Group-A Group-B Group-C
Figure 5: Scheme Groups formed based on various protocol component configurations; thegroups can be used to categorize future clusters of security schemes to choose the optimalscheme
As a proof-of-concept, we implemented three groups {Group-A, Group-B,406
Group-C} that are significant. Group-A represents all configurations utilizing407
TLS as the base protocol, and using no session resumption. Group-B repre-408
sents all configurations under TLS, but with support for session resumption.409
Group-C comprises of all DTLS schemes with no session resumption. Session410
Resumption can be an optional configuration because there are trade-offs in411
having this feature. The resumption feature itself requires some periodic disk412
I/O to serialize active sessions. In addition, the serialized files are stored on413
17
the device, utilizing notable disk space. This process also ends up consuming414
notable energy. Thus, in cases of highly constrained IoT devices, not having415
session resumption enabled within the middleware may be beneficial.416
Since our server is considered to be Full Function Device (i.e., a device417
that is enterprise data center grade and is generally not limited in terms418
of resources and function capabilities), it can be safely assumed that client419
benchmarks are the bottleneck, and hence sufficient for forming clusters.420
Since the clusters are to choose the optimal security scheme targeted for the421
IoT-devices involved, we are able to discard the benchmark values for the422
server side without any negative impact on the Optimal Scheme Decider.423
Table 3: Parameters used for client benchmark analysis and their descriptions. Theseparameters are utilized in Offline and Online phasesParameter Label Client Parameter Description Desired Level for RFD
P1 CPU Usage The security scheme’s CPU usage Smaller value
P2 Bandwidth Usage The bandwidth of the security schemes network usage Smaller value
P3 Peak Bytes The peak memory consumption on device Smaller value
P4 Connection Time The elapsed time to successfully connect with server Smaller value
P5 TX The speed of transmitting data Higher value
P6 RX The speed of receiving data Higher value
Table 3 shows the parameters used for client benchmark analysis in our424
database. The desired level represents whether high value is optimal, or425
lower, when operating on a Reduced Function Device (i.e., a sensor device426
that is highly constrained in terms of available resources and functioning427
capabilities). These 6 metrics under the ‘Client Parameter’ column in Ta-428
ble 3 can next be used to form the cluster of devices. By calculating the429
mean values of each variable for each cluster, we can classify them into inter-430
mediate categories. For instance, if the mean value of the bandwidth for a431
specific cluster is larger than other clusters, we classify this cluster as “secu-432
rity configuration with high bandwidth need”. The formation of the cluster433
of devices is thus fuzzy in nature, but aligns well with our approach for the434
security scheme selection. To move forward, we need to perform a set of435
operations on the raw data to successfully filter the schemes into appropriate436
clusters under each group. Hence, the following steps are followed:437
1. Scale the raw data438
Note: The parameter labels {P1, P2, P3, P4, P5, P6} can be col-439
lectively referred to as members of set “P”. This step is needed to440
18
decrease the correlation between each metric, in addition to decreas-441
ing the influence of units, i.e., Normalization. Hence, we perform data442
scaling on our raw data using the scaling formula:443
444
x′ =xij − xmj
σj(1)
where445
x′ : scaled valuexij : observations or row vectors of jth parameter, where j ∈ Pxmj : mean value of jth parameter, where j ∈ Pσj : standard variance for jth parameter, where j ∈ P
446
2. Identify principal components and generate weighted formula for clus-447
tering448
Next step involves applying principal component analysis (PCA) to449
decide the number of clusters that may exist in each for the groups450
{Group-A, Group-B, Group-C}. The needed number of clusters is451
selected by a commonly-used statistic testing index viz., cumulative452
proportion of variance explained. Usually, when this index is around453
80%, that number of clusters is the appropriate one. After deciding454
how many clusters we need to separate at a broad level, we apply the455
k-means clustering to see what security combinations should be dis-456
tributed to which cluster. After receiving the k-means outcome, we457
pick the security combination which best represents the property of a458
specific cluster based on: (a) our knowledge of the properties of each459
cluster, and (b) the mean values from the PCA result and the security460
combinations that are contained in each cluster. The formula for each461
potential cluster can be as below:462
zi1 = φ11 · xi1 + φ12 · xi2 + · · ·+ φ1p · xip (2)
zi2 = φ21 · xi1 + φ22 · xi2 + · · ·+ φ2p · xip (3)463
· · ·
zip = φp1 · xi1 + φp2 · xi2 + · · ·+ φpp · xip (4)
19
where464
zip : final adjusted data in ith row and pth parameter (∈ P ) that makeeigen vectors perpendicular to each other
φ : eigen vectors that make covariance matrix have length 1xip : value of element
465
3. Calculate the weight value for data elements466
Once we have the principal component formula, we need to calculate467
the value of weight φ of every element. This is an optimization problem468
to calculate the weight φ:469
maximizeφ11,··· ,φp1
1
n
n∑i=1
(p∑j=1
φj1 · xij
)2
subject to
p∑j=1
φ2j1 = 1.
(5)
Figure 6 shows our results for principal components of Group-A. Every470
column is now categorized as per metric value similarity. For example,471
PC1 might have all schemes with maximum CPU consumption, PC2472
might represent all schemes with maximum network bandwidth, and so473
on. Similarly, principal component analysis is generated for Group-B474
and Group-C.475
PC1 PC2 PC3 PC4 PC5 PC60.41360938 0.100293698 0.092052776 0.09619145 0.12976439 -0.202704800.36011693 0.135860875 0.379974741 0.15717643 0.19895004 0.412284360.34665052 0.014556344 -0.483856615 -0.09589430 0.21425282 0.301677440.41213841 0.094629048 -0.008309101 0.04835103 0.05232809 -0.784725380.36602790 0.139084453 0.363904173 0.14463286 0.17486990 0.204244880.28722876 -0.012811214 -0.615630188 -0.17073142 0.15632095 0.10162907
Figure 6: Group-A principal component raw results
4. Identify number of clusters needed per group476
The number of clusters that need to be generated per group can next477
be calculated using proportion of variance explained (PVE). We apply478
20
the following on the dataset:479
p∑j=1
Var (Xj) =
p∑j=1
1
n
n∑i=1
x2ij (6)
The PVE result for each group is shown in Figures 7, 8, and 9. Ana-480
lyzing Group-A PVE in Figure 7 indicates that 89.1% (∼90%) of the481
schemes in this group can be taken into consideration if we use three482
clusters. Any higher cluster count would provide only trivial advan-483
tage. For Group-B, the PVE in Figure 8 suggests taking four clusters484
to encompass 90.4% (∼90%) of the schemes. Similarly, Group-C can485
benefit by housing four clusters, i.e., 90.6% (∼90%) of the schemes.486
Hence, we accept 3 clusters in Group-A, and 4 clusters each in Group-487
B and Group-C, as shown in Figure 10. We remark that Figure 10488
illustrates a proof-of-concept method to create various categories of se-489
curity schemes, and for an optimal scheme to flexibly customize as per490
an application’s needs. In the specific case of Figure 10, the cluster491
formation is based on our proof-of-concept implementation with wolf-492
SSL [29] for crypto and authentication functions with ∼200 security493
schemes. We choose wolfSSL owing to its lightweight SSL/TLS li-494
braries that are small, portable and standardized for development with495
embedded system devices. However, our security framework can work496
with other categories of security schemes based on any other choice of497
implementation stacks (e.g., OpenSSL) suitable to cater to any appli-498
cation needs.499
[A] 0.493 0.766 0.891 0.966 0.989 0.996 0.998 0.999 1.000 1.000 1.000
[B] 0.424 0.769 0.861 0.904 0.946 0.967 0.982 0.992 0.995 0.997 0.998 0.999 0.999 0.999 0.999 0.999
[C] 0.495 0.698 0.825 0.906 0.961 0.981 0.991 0.995 0.998 1.000 1.000
Figure 7: Group-A proportion of variance explained results. Forming 3 clusters is sufficientto include ∼90% of the schemes
[A] 0.493 0.766 0.891 0.966 0.989 0.996 0.998 0.999 1.000 1.000 1.000
[B] 0.424 0.769 0.861 0.904 0.946 0.967 0.982 0.992 0.995 0.997 0.998 0.999 0.999 0.999 0.999 0.999
[C] 0.495 0.698 0.825 0.906 0.961 0.981 0.991 0.995 0.998 1.000 1.000Figure 8: Group-B proportion of variance explained results. Forming 4 clusters is sufficientto include ∼90% of the schemes
21
[A] 0.493 0.766 0.891 0.966 0.989 0.996 0.998 0.999 1.000 1.000 1.000
[B] 0.424 0.769 0.861 0.904 0.946 0.967 0.982 0.992 0.995 0.997 0.998 0.999 0.999 0.999 0.999 0.999
[C] 0.495 0.698 0.825 0.906 0.961 0.981 0.991 0.995 0.998 1.000 1.000
Figure 9: Group-C proportion of variance explained results. Forming 3 clusters is sufficientto include ∼90% of the schemes
Application Requirements
TLS DTLS
No Session Resumption Session Resumption No Session
Resumption
Group-A Group-B Group-C
Cluster 1
Cluster 2
Cluster 3
Cluster 4
Cluster 5
Cluster 6
Cluster 8
Cluster 9
Cluster 10
Cluster 7 Cluster 11
Figure 10: Number of clusters per group, calculated using proportion of variance explainedin Step 4
5. Final clustering500
Once we have decided on number of clusters in each group, we can use501
k-means clustering by calculating Euclidean distance for each observa-502
tion. This can be done by applying the following:503
W (Ck) =1
|Ck|∑i,i′εCk
p∑j=1
(xij − xi′j)2 . (7)
where504
22
W (Ck) : within-cluster variation, square Euclidean distanceCk : the amount by which observations within a cluster differ from
each otherxij − xi′j : the distance between different observations, Euclidean
distance
505
We want to cluster together the observations with minimum distance506
between them. Hence, we find the minimum distance in Equation 7:507
minimizeC1,··· ,CK
{K∑k=1
W (Ck)
}. (8)
where508
Ck : set of observations in cluster k509
In essence, clustering allows us to reduce the overhead of relying on use510
of hundreds of redundant security schemes in our database, and instead finds511
the best alternative from a smaller scope containing equivalent schemes. We512
are able to choose the most optimal cluster in each group, hence allowing a513
small subset of schemes to be used by our middleware in an Online Phase514
(i.e., in real-time application use context).515
5.1.2. Online Phase516
For the online phase, the non-redundant schemes shortlisted in the offline517
phase can be accessed using a set of RESTful APIs by our middleware inte-518
gration on an IoT device, gateway, or a core cloud. Figure 11 shows a tabular519
listing of available APIs for use in our middleware. The Optimal Scheme De-520
cider acts as our decision making engine which finds the optimal security521
scheme for a given application use case and resource awareness. The metrics522
for resource awareness that we consider are: Type of Data, Estimated size of523
data transfer, Energy available to the device, Computation power available,524
Memory available, and Session Resumption requirement.525
The options chosen by the user are each internally mapped to a value526
in the range {1, 2, · · · , 10}. The mapping has been done by surveying many527
devices ranging from lower end of the spectrum in the metric to the higher528
end. For example, CPU frequency of over 750 MHz can be safely categorized529
as a Level-4 device, considering it is higher than most IoT devices. A full530
description of the acceptable parameter values can be viewed in Figure 12.531
23
Figure 11: A subset of the RESTful APIs available during Online Phase; Connecteddevices in the IoT system may invoke the API methods to collect required target deviceor parameter information
5.2. Logic Implementation532
Once the internal map has been generated as detailed above, the Optimal533
Scheme Decider algorithm shown in Algorithm 2 is invoked to filter good534
candidate schemes from the cluster chosen in the Offline Phase. We can see535
the various filters applied in the algorithm to narrow down to a single security536
scheme from the input metrics. We decided to choose Stream Cipher as the537
preferred option over Block Cipher for all multimedia applications, as well as538
for general applications with smaller payloads. For further filtering, we have539
tied DTLS protocol with STREAM ciphers, and TLS protocol with BLOCK540
ciphers. This is because utilizing TLS with STREAM ciphers or DTLS with541
BLOCK ciphers would essentially undo the benefits offered by the protocol542
or cipher.543
24
Figure 12: RESTful API Parameter Values. The acceptable JSON values are mappedinternally as noted in the Description column
In the algorithm, once the data type and size have been used to fil-544
ter according to protocol and cipher type, subsequent decisions are based545
on the device specifications. Priority is given to energy level of the device546
in question, since IoT-based applications are almost invariably limited by547
energy consumption or availability to securely handle data. Hence, a low548
energy availability and extremely-high security scheme will not be combined549
together. Three major threshold variables have been set up to make cer-550
tain decisions, mapped on a scale of {1-10}. The threshold value to decide551
whether the device has enough energy available to support complex schemes552
can be set using the variable iotEnergyThreshold. E.g., a threshold of Level-4553
implies any device with energy value below 4 is not to be handed a heavy se-554
curity scheme. Similarly, lowCompMemThreshold & medCompMemThresh-555
old are used to filter low or medium security requirements. The best scheme556
is picked based on the limiting value between available CPU and Memory.557
For instance, a Level-2 CPU in conjunction with Level-9 Memory will still558
be incapable of running high security schemes. The same would be true if559
the CPU and Memory levels are reversed. Finally, the result is the choice of560
scheme that gets used by the middleware to initiate a secure session.561
25
Algorithm 2: Optimal Security Scheme DeciderData: Data to be transmitted, dataData: Protocol to be used for transmission, protocolData: Cipher to be used for encryption, macData: Energy Level classification of the device, energyLevelData: CPU level classification of the device, cpuLevelData: Memory level classification of the device, memLevelData: On a scale of 1-10, threshold used to decide low energy availability,
iotEnergyThresholdData: On a scale of 1-10, threshold used to decide low memory/computation
availability, lowCompMemThresholdData: On a scale of 1-10, threshold used to decide medium memory/computation
availability, medCompMemThreshold
Result: The best security scheme is chosen
/* data.PACKET SIZE in bits */if data.TYPE = MULTIMEDIA or data.PACKET SIZE < 128 then
protocol ← DTLScipher.TYPE ← STREAM
elseprotocol ← TLScipher.TYPE ← BLOCK
end
if energyLevel < iotEnergyThreshold thenEliminate heavy encryption schemes
end
if min (cpuLevel,memLevel) < lowCompMemThreshold thenChoose low-level security scheme
else if min (cpuLevel,memLevel) < medCompMemThreshold thenChoose medium-level security scheme
elseChoose high-level security scheme
end
26
6. Performance Evaluation562
In this section, we compare the performance of various schemes accessible563
on our middleware to randomly selected schemes. This allows us to check564
the difference in impact caused by a better selection. Since the middleware565
has multiple submodules capable of working independently, we perform our566
middleware evaluation using two sets of experiments: (i) Validation of Inter-567
mittent Security, and (ii) Validation of Resource-aware Security.568
6.1. Intermittent Security Validation Results569
Our first set of experiments aim to check the impact of utilizing the570
middleware to switch from ephemeral, high security protocol schemes to using571
static properties such as PSK for secure session. For this, we use a prototype572
implementation of our middleware based on wolfSSL [29] within a GENI [30]573
Cloud testbed as shown in Figure 13. Live video stream is supported using574
OpenCV [31]. The application itself is built completely using C/C++, using575
GCC compiler. Our implementation consists of a client and server prototype.576
The server is hosted on core cloud and gateway, and listens for client requests577
from gateway and IoT nodes. The client side of the system provides an578
interactive interface where one can choose from five different levels of security.579
The image representing the server side shows the server when DTLS-PSK580
cipher scheme is being used. In general case, we choose and recommend the581
static PSK scheme.582
The first step for security association and communication initiation is583
selection of the security protocols to be used. Our middleware supports584
different kinds of protocols and allows switching between them. The possible585
choices all select one of the options in each category. The categories include586
Protocol, Authentication Scheme, Bulk Encryption Scheme, and Message587
Authentication Code (MAC) algorithm. Our experiments account for: (i)588
Memory Footprint, including number of memory allocations and total size589
of allocation, and (ii) Time taken for security association, for initial session590
establishment and session resumption scenario.591
Figure 14(a) gives the graph generated by comparing different cipher592
schemes. The schemes we compared are Datagram TLS (DTLS), and TLS.593
The schemes were evaluated using Pre-shared Keys (PSKs) and certificates.594
Likewise, Figure 14(b) shows how much memory allocation size it takes to595
have the connection established. DTLS-PSK comes out to be low, by order596
of millions. We can see that certificate generation takes more size. Hence,597
27
Figure 13: Testbed setup over the GENI Cloud Infrastructure
choosing PSK for the resumption can be quite an excellent choice. Even598
better results are obtained using Static PSK, if high security is not critical599
to the use case.600
Figure 15 shows results for the connection and resumption time for the601
four different schemes we compared in our experiments with our prototype602
middleware. Even though using DTLS-certificate gives consistently low time603
spent, we see that DTLS-PSK is the fastest scheme. DTLS can offer speed-604
up of over a few hundred times, regardless of cases where there is a fresh605
handshake or resumed session. Hence, our results show how useful Intermit-606
tent security in IoT systems can be, all the while without compromising the607
security, by allowing flexibility in configuration.608
6.2. Resource-aware Security Validation Results609
In our first set of experiments describe above, we established the useful-610
ness of utilizing Session Resumption, as well as having the option to choose611
from a few different security schemes. In our second set of experiments, we612
aim to expand on our results and investigate our middleware’s ability to613
form clusters from almost 200 security schemes. To test the offline phase614
detailed in Section 5.1.1, we check validity of: (i) the clusters formed using615
our method, (ii) the optimal cluster chosen, and (iii) whether limiting scope616
is a safe and accurate way of choosing the optimal scheme.617
28
(a) Number of memory allocations (b) Memory allocated (in bytes)
Figure 14: Memory footprint for different encryption schemes. Our chosen scheme utilizingDTLS-PSK shows the most promising result in terms of memory consumption
Figure 15: Time for connection vs. resumption for different encryption schemes. Ourchosen scheme DTLS-PSK has very fast connection, and the fastest reconnection, due toSession Resumption support
In the offline phase, we attempted forming clusters to narrow down the618
choices to a few viable ones. Following the logic and analysis described in619
Section 3, the optimal clusters were formed. For our statistical threshold, the620
within-cluster sum of squares ratio of at least 60% proves that the cluster621
formed is valid and successful. Figures 16, 17, and 18 show the within-622
cluster sum of square ratio for the optimum cluster chosen in Group-A, B623
and C, respectively. As can be observed, the ratios 61.1%, 69.4%, and 62.1%624
are generated, and hence, the clusters are successful. This increases the625
certainty of optimal schemes being made available to be sifted through in626
the online phase. The schemes in the chosen cluster for Group-A are shown627
in Figure 19. Similarly, Group-B and Group-C have their own schemes for628
their corresponding chosen cluster.629
29
Clustering vector:2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64 661 1 1 3 1 1 1 3 1 1 1 3 3 1 3 3 2 2 2 1 1 1 3 3 2 2 2 3 3 1 1 1 1
Within cluster sum of squares by cluster:
(between_SS / total_SS = 61.1 %)[A] 71.84645 17.85738 47.12641
Figure 16: Within-cluster sum of squares for Group-A. Value of 61.1%(>60%) showssuccessful clustering
Clustering vector:1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 63 652 2 2 4 2 2 2 4 2 2 2 4 4 4 3 3 1 1 1 2 2 2 4 4 1 1 1 4 4 4 2 2 2
Within cluster sum of squares by cluster:
(between_SS / total_SS = 69.4 %)[B] 42.004220 56.013587 4.281206 54.327632
Figure 17: Within-cluster sum of squares for Group-B. Value of 69.4%(>60%) showssuccessful clustering
Clustering vector:67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 992 2 2 4 2 2 2 4 2 2 2 4 4 3 3 3 1 1 1 2 2 2 3 3 1 1 1 4 4 4 2 2 2
Within cluster sum of squares by cluster:
(between_SS / total_SS = 62.1 %)[C] 20.94528 46.51529 44.52632 21.46218
Figure 18: Within-cluster sum of squares for Group-C. Value of 62.1%(>60%) showssuccessful clustering
Figures 20, 21, and 22 show the selection of best cluster in each category,630
as chosen by the Optimal Scheme Decider’s offline phase. We can see the631
clusters in each group that are formed after normalization of the computation632
index. The computation index is a compilation of the benchmark metrics633
used for clustering and decision making. Each of the chosen clusters have634
their advantages and disadvantages, which can be filtered in the online phase635
by the Optimal Scheme Decider.636
To verify that clustering and choosing a narrow scope is still able to637
provide us an optimal scheme, a visual representation through Dendrogram638
can be used. The dendrogram portrays the relationship between various639
schemes in a group. As can be observed in Figure 23, multiple schemes in640
30
# Security Scheme Cluster #2 TLS-DHE-RSA-AES128CBC-SHA 38 TLS-PSK-AES128CBC-SHA 310 TLS-DHE-RSA-AES256CBC-SHA 316 TLS-PSK-AES256CBC-SHA 318 TLS-DHE-RSA-AES128CBC-SHA256 324 TLS-PSK-AES128CBC-SHA256 326 TLS-DHE-PSK-AES128CBC-SHA256 340 TLS-DHE-RSA-AES256GCM-SHA256 346 TLS-PSK-AES256GCM-SHA384 348 TLS-DHE-PSK-AES256GCM-SHA384 3
Figure 19: Chosen cluster’s security schemes categorized in Group-A
each group have siblings at the same level. This implies extreme similarities641
in the sibling schemes, and an absence of considerable performance benefit.642
This redundancy can be easily handled by randomly picking one of the leaves643
in the dendrogram and discarding the other scheme.644
Cluster 3 is chosen, due to collectively lowest bandwidth usage, lowest CPU usage, fastest connection speed, and data exchange speed
Figure 20: Chosen cluster in Group-A, by the Optimal Scheme Decider
Finally, the online phase requires collecting software requirements for the645
IoT-based application to be utilized. The current requirement collection646
can be done by making an API call to /api/gateway/:device_id service647
endpoint. The application user may send the required information using a648
parameter list to the gateway. The response from these queries help form the649
metrics that are later used by the Optimal Scheme Decider. In our related set650
31
Cluster 4 is chosen, due to collectively lowest bandwidth usage, lowest CPU usage, fastest connection speed, and data exchange speed
Figure 21: Chosen cluster in Group-B, by the Optimal Scheme Decider
of experiments, we tested the Optimal Scheme Decider by using random val-651
ues as input requirements to check the scheme chosen by our middleware. As652
expected, for a low-security and low-resource multimedia application, PSK-653
CHACHA20 combination was found to be the optimal choice. To analyze the654
trade-off characteristics for various use-cases of IoT-based applications, we655
utilize radar diagrams for visual representation of the results. For instance,656
as shown in Figure 24(a), PSK-CHACHA20 scheme demands substantial657
memory resources, and exhibits fast re/connection speed but at the expense658
of a lower level of security.659
Similarly, results were analyzed to highlight a contrasting case. The new660
requirement priority being high security on a low-resource multimedia ap-661
plication, Epehemeral (DHE) PSK-CHACHA20 combination was found to662
be the optimal choice. A radar diagram in Figure 24(b) shows the security663
mapping of the same. In this case, security was found to be the most impor-664
tant criteria, even if at the expense of re/connection speed. Hence, public665
key cryptography scheme was chosen for key exchange, along with a highly666
reliable integrity check MAC algorithm (POLY1305).667
In many other experiment results, we observed the radar diagram to668
visualize the trade-offs and analyze when session resumption is useful, and669
when it is not. For instance, Figure 25(a) shows the specifications for a670
chosen scheme for an application requiring high reconnection speed through671
32
Cluster 11 is chosen, due to collectively lowest bandwidth usage, lowest CPU usage, fastest connection speed, and data exchange speed
Figure 22: Chosen cluster in Group-C, by the Optimal Scheme Decider
session resumption, having lower memory and security requirements. This672
application appears to be a good candidate for ‘austere-edge‘ (constrained673
network-edge with limited resource availability) IoT-based application use-674
cases. Contrasting this application to a ‘smart edge’ (unconstrained network-675
edge with enterprise data center resource availability), Figure 25(b) shows676
the corresponding application’s chosen scheme trade-off specifications. We677
can observe that a very high level of security can be obtained at expense of678
faster reconnection.679
Similarly, for another austere-edge IoT-based application, chosen scheme’s680
specifications are visualized in Figure 26(a). Very high reconnection speed681
appears to be a requirement, hence speed is preferred over security. And682
finally, for a similar application without session resumption support, the683
chosen scheme specifications can be visualized in Figure 26(b). This applica-684
tion represents another ‘smart-edge‘ IoT-based application, as an all-rounded685
security scheme is needed, with a higher priority for security and initial con-686
nection speed.687
33
Heigh
t
Lower value of height difference implies similarity between different schemes
These schemes are very similar. Hence, if decider traverses to this branch, we can safely ignore the other schemes for further analysis
Figure 23: Group-A Dendrogram depicting reasoning for safely narrowing scope of searchof optimal scheme in Offline Phase
Transfer Speed
Secure
Memory
Connection SpeedReconnection Speed
(a) Scheme DTLS-PSK-CHACHA20-
POLY1305
Transfer Speed
Secure
Memory
Connection SpeedReconnection Speed
(b) Scheme DTLS-DHE-PSK-CHACHA20-
POLY1305
Figure 24: Radar representation of chosen schemes in two contrasting IoT applications
34
Transfer Speed
Secure
Memory
Connection SpeedReconnection Speed
(a) Scheme TLS-DHE-PSK-AES256-GCM-
SHA384 w/ Session Resumption
Secure
Memory
Connection SpeedReconnection Speed
Transfer Speed
(b) Scheme TLS-DHE-PSK-AES256-GCM-
SHA384 w/o Session Resumption
Figure 25: Radar representation of two very similar schemes, chosen for ‘Austere-Edge’and ‘Smart-Edge’ respectively. Presence/Absence of resumption support allows differentuse-cases
Secure
Memory
Connection SpeedReconnection Speed
Transfer Speed
(a) Scheme TLS-PSK-AES256-CBC-SHA
w/ Session Resumption
Secure
Memory
Connection SpeedReconnection Speed
Transfer Speed
(b) Scheme TLS-PSK-AES256-CBC-SHA w/o
Session Resumption
Figure 26: Radar representation of two more schemes, chosen for ‘Austere-Edge’ and‘Smart-Edge’ respectively. In certain cases, lack of resumption might prove more useful,as shown in (b)
35
7. Conclusion688
In this paper, we developed a flexible IoT security middleware that can be689
used in end-to-end cloud-fog communications involving smart devices at the690
network-edge and a cloud-hosted application. The end-to-end feature is pos-691
sible due to the middleware’s task of translating protocols between two dif-692
ferent network segments (i.e., cloud-to-gateway and gateway-to-edge), hence693
resulting in full security without being limited by protocol compatibility be-694
tween the networks. Our middleware features two major modules, the first of695
which is the ‘Intermittent Security’ module that offers quick re-connections696
to aid in situations of unreliable network conditions within cloud-fog commu-697
nication platforms. The second module handles ‘Flexibile Security’, which698
provides flexibility in choosing an optimal security scheme that is suitable for699
securing an IoT-based application depending upon user’s requirements and700
edge-resource constraints.701
Our results from testbed experiments with a prototype implementation702
of our middleware validate its benefits. We showed that whenever feasible703
and acceptable, the use of static properties such as Static PSK can notably704
speed-up secure communications. Static PSKs in prior literature have not re-705
ceived much attention. However, our work demonstrated that they could be706
a valuable tool for low-resource, moderate-security applications within IoT707
systems in both ‘austere’ and ‘smart’ network-edges, even for unreliable net-708
works with frequent disconnections. Our investigations have also shown that709
it is possible to find equivalence amongst various kinds of security schemes710
available, and there is potential to have real-time advice to select the opti-711
mal scheme for a given set of constraints in an IoT application. Towards this712
end, we have developed an optimal scheme decider which is capable of using713
a security scheme database to find and use the optimal security scheme for a714
given set of constraints. This has been done by using a new set of RESTful715
APIs that we created, which allows our middleware to collect information716
about data and devices involved in the network. We also used supervised717
machine learning to narrow down on subsets of appropriate security schemes718
by considering different trade-offs involved in IoT-applications.719
Future work can involve extending our middleware with a transient repu-720
tation scheme that can collect and use short-term knowledge about the con-721
necting devices to build a short-lived reputation. This would alleviate the722
need to maintain trust states in the network-edge amongst the IoT devices.723
36
Acknowledgement724
This material is based upon work supported by the National Science725
Foundation under Award Number: CNS-1647182. Any opinions, findings,726
and conclusions or recommendations expressed in this publication are those727
of the author(s) and do not necessarily reflect the views of the National728
Science Foundation.729
References730
[1] IoT Trends - Tech Insider, 2016. http://www.businessinsider.com/731
top-internet-of-things-trends-2016-1.732
[2] J. Gillis, P. Calyam, O. Apperson, S. Ahmad, “Panacea’s Cloud:733
Augmented reality for mass casualty disaster incident triage and co-734
ordination”, IEEE Annual Consumer Communications & Networking735
Conference (CCNC) (2016).736
[3] J. Gillis, P. Calyam, A. Bartels, M. Popescu, S. Barnes, J. Doty, D. Hig-737
bee, S. Ahmad, “Panacea’s Glass: Mobile Cloud Framework for Com-738
munication in Mass Casualty Disaster Triage”, IEEE International Con-739
ference on Mobile Cloud Computing, Services, and Engineering (2015).740
[4] J. Burchard, D. Chemodanov, J. Gillis, P. Calyam, “Wireless Mesh741
networking Protocol for sustained throughput in Edge Computing”, In-742
ternational Conference on Computing, Networking and Communications743
(ICNC) (2017).744
[5] M. Rantz, M. Skubic, C. Abbott, C. Galambos, M. Popescu, J. Keller,745
E. Stone, J. Back, S. J. Miller, G. F. Petroski, “Automated in-home fall746
risk assessment and detection sensor system for elders”, The Gerontol-747
ogist 55 (2015) S78–S87.748
[6] P. Calyam, A. Mishra, R. Bazan Antequera, D. Chemodanov, A. Berry-749
man, K. Zhu, C. Abbott, M. Skubic, “Synchronous Big Data Analytics750
for Personalized and Remote Physical Therapy”, Elsevier Pervasive and751
Mobile Computing (2015).752
[7] J. Gubbi, R. Buyya, S. Marusic, M. Palaniswami, “Internet of Things753
(IoT): A vision, architectural elements, and future directions”, Future754
generation computer systems 29 (2013) 1645–1660.755
37
[8] M. Ali, N. Ono, M. Kaysar, Z. Shamszaman, T. Pham, F. Gao, K.756
Griffin, A. Mileo, “Real-time data analytics and event detection for IoT-757
enabled communication systems”, Web Semantics: Science, Services and758
Agents on the World Wide Web 42 (2017) 19–37.759
[9] C. Perera, A. Zaslavsky, P. Christen, D. Georgakopoulos, “Sensing as a760
service model for smart cities supported by internet of things”, Trans-761
actions on Emerging Telecommunications Technologies 25 (2014) 81–93.762
[10] S. Sicari, A. Rizzardi, L. Grieco, A. Coen-Porisini, “Security, privacy763
and trust in Internet of Things: The road ahead”, Computer Networks764
76 (2015) 146–164.765
[11] R. Bonetto, N. Bui, V. Lakkundi, A. Olivereau, A. Serbanati, M. Rossi,766
“Secure Communication for Smart IoT Objects: Protocol Stacks, Use767
Cases and Practical Examples”, IEEE World of Wireless, Mobile and768
Multimedia Networks (WoWMoM) (2012).769
[12] X. S. Huber Flores, V. Kostakos, A. Y. Ding, P. Nurmi, S. Tarkoma,770
P. Hui, Y. Li, “Large-scale Offloading in the Internet of Things”, in:771
International Conference on Pervasive Computing and Communications772
Workshops, PerCom WS.773
[13] H. Khemissa, D. Tandjaoui, “A novel lightweight authentication scheme774
for heterogeneous wireless sensor networks in the context of Internet775
of Things”, in: Wireless Telecommunications Symposium, WTS 2016,776
London, United Kingdom, April 18-20, 2016, pp. 1–6.777
[14] M. Turkanovi, B. Brumen, M. Hlbl, “A novel user authentication and778
key agreement scheme for heterogeneous ad hoc wireless sensor networks,779
based on the Internet of Things notion”, Ad Hoc Networks 20 (2014)780
96 – 112.781
[15] Md. A. Iqbal, M. Bayoumi, “Secure End-to-End Key Establishment782
Protocol for Resource-Constrained Healthcare Sensors in the Context of783
IoT”, International Conference on High Performance Computing and784
Simulation (HPCS) (2016).785
[16] C. Stergiou, K. E. Psannis, B. G. Kim, B. Gupta, “Secure integration786
of IoT and Cloud Computing”, Future Generation Computer Systems787
(2016).788
38
[17] S. R. Moosavi, T. N. Gia, E. Nigussie, A. M. Rahmani, S. Virtanen,789
H. Tenhunen, J. Isoaho, “Session Resumption-Based End-to-End Secu-790
rity for Healthcare Internet-of-Things”, IEEE International Conference791
on Computer and Information Technology (2015) 581–588.792
[18] S. R. Moosavi, T. N. Gia, E. Nigussie, A. M. Rahmani, S. Virtanen, H.793
Tenhunen, J. Isoaho, “End-to-end security scheme for mobility enabled794
healthcare Internet of Things”, Future Generation Computer Systems795
64 (2016) 108 – 124.796
[19] R. Hummen, H. Wirtz, J. H. Ziegeldorf, J. Hiller, K. Wehrle, “Tailoring797
End-to-End IP Security Protocols to the Internet of Things”, 21st IEEE798
International Conference on Network Protocols (ICNP) (2013).799
[20] C. Huth, J. Zibuschka, P. Duplys, T. Guneysu, “Securing Systems on800
the Internet of Things via Physical Properties of Devices and Communi-801
cations”, Systems Conference (SysCon), 9th Annual IEEE International802
(2015).803
[21] R. Amin, G. P. Biswas, “A secure light weight scheme for user au-804
thentication and key agreement in multi-gateway based wireless sensor805
networks”, Ad Hoc Networks 36, Part 1 (2016) 58 – 80.806
[22] G. Piro, G. Boggia, L. A. Grieco, “A standard compliant security frame-807
work for IEEE 802.15.4 networks”, IEEE World Forum on Internet of808
Things (WF-IoT) (2014).809
[23] B. Mukherjee, R. Neupane, P. Calyam, “End-to-End IoT Security Mid-810
dleware for Cloud-Fog Communication”, IEEE Cyber Security and811
Cloud Computing (CSCloud) (2017).812
[24] P. Syverson, “A Taxonomy of Replay Attacks [cryptographic proto-813
cols]”, Computer Security Foundations Workshop VII. (1994).814
[25] F. C. Kuo, H. Tschofenig, F. Meyer, X. Fu, “Comparison Studies be-815
tween Pre-Shared and Public Key Exchange Mechanisms for Transport816
Layer Security”, IEEE International Conference on Computer Commu-817
nications. Proceedings (INFOCOM) (2006).818
39
[26] J. A. Dev, “Usage of Botnets for High Speed MD5 Hash Cracking”, In-819
ternational Conference on Innovative Computing Technology (INTECH)820
(2013).821
[27] D. Lee, “Hash Function Vulnerability Index and Hash Chain Attacks”,822
IEEE Workshop on Secure Network Protocols, NPSec (2007).823
[28] M. Stevens, E. Bursztein, P. Karpman, A. Albertini, Y. Markov, “The824
first collision for full SHA-1”, Accessed June 2017. https://shattered.825
io/static/shattered.pdf.826
[29] wolfSSL SSL library, Accessed June 2017. https://www.wolfssl.com/827
wolfSSL/Home.html.828
[30] NSF-supported GENI Cloud Infrastructure, Accessed June 2017. https:829
//www.geni.net.830
[31] OpenCV library, Accessed June 2017. http://opencv.org.831
Bidyut Mukherjee received his MS degree in ComputerScience from University of Missouri-Columbia in 2017, andBE degree in Computer Technology from RTM Nagpur Uni-versity, India in 2015. His current research interests in-clude: Cloud Computing, Computer Networking, Internetof Things, and Cyber Security. He is a student member of
IEEE.
Songjie Wang is currently a graduate student pursuing MSdegree in the Department of Computer Science at the Uni-versity of Missouri-Columbia. His current research interestsinclude: Cloud Computing, Internet of Things and Data Sci-ence.
40
Wenyi Lu received her MS degree in Statistics from Uni-versity of Missouri-Columbia in 2015. Currently, she is aPhD student in the Department of Computer Science at MU.Her current research interests include: Serious-game Designand Development, Deep-Learning analytics and Data Min-ing technologies.
Roshan Lal Neupane received his BE degree in ComputerScience and Engineering from Visvesvaraya TechnologicalUniversity, Karnataka, India. He is currently a graduatestudent at University of Missouri-Columbia, pursuing MS inComputer Science. Cloud Computing, Computer Network-ing, Internet of Things, and Cyber Security. He is a studentmember of IEEE.
Daniel Dunn received his BS degree in Computer Sciencefrom the University of Missouri-Columbia in 2017. He re-mains a student there with the expectation to receive hisMS degree in Computer Science in 2018 as a student in the5-year BS/MS Computer Science Fast Track Program. He
is a member and the Vice President of Upsilon Pi Epsilon Computer ScienceHonors Society. His current research focus is in Cyber Security.
Yijie Ren is now earning her MS degree in Computer Sci-ence at University of Missouri-Columbia. She also receivedher BS Degree in Computer Science at MU, and BE Degreein Software Engineering at Taiyuan University in China. Herresearch interests include: Big Data Analytics and Cloud
Computing.
41
Qi Su received her bachelor’s degree in Communicationsfrom University of Missouri-Columbia in 2014. She is cur-rently a MS student in the Department of Computer Scienceat MU. Her current research interests include: Cloud Com-puting and Bioinformatics.
Prasad Calyam received his MS and PhD degrees fromthe Department of Electrical and Computer Engineering atThe Ohio State University in 2002 and 2007, respectively.He is currently an Assistant Professor in the Department ofComputer Science at University of Missouri-Columbia. Pre-viously, he was a Research Director at the Ohio Supercom-
puter Center. His research interests include: Distributed and Cloud comput-ing, Computer Networking, and Cyber Security. He is a Senior Member ofIEEE.
42