Internet of Things: A Survey On The Security of Iot Frameworks

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/322864555
Internet of Things: A survey on the security of IoT frameworks
Article in Journal of Information Security and Applications · February 2018

DOI: 10.1016/j.jisa.2017.11.002
CITATIONS READS
341 7,732
3 authors:
Mahmoud Ammar Giovanni Russello

KU Leuven University of Auckland
18 PUBLICATIONS 403 CITATIONS 133 PUBLICATIONS 1,628 CITATIONS
SEE PROFILE SEE PROFILE
Bruno Crispo
Università degli Studi di Trento and KU Leuven
266 PUBLICATIONS 4,761 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Security and Privacy in Distributed Systems View project
Privacy Protection and DRM View project
All content following this page was uploaded by Mahmoud Ammar on 05 November 2018.
The user has requested enhancement of the downloaded file.

Journal of Information Security and Applications 38 (2018) 8–27
Contents lists available at ScienceDirect
Journal of Information Security and Applications

journal homepage: www.elsevier.com/locate/jisa
Internet of Things: A survey on the security of IoT frameworks

Mahmoud Ammar a,∗, Giovanni Russello b, Bruno Crispo a
a
Department of Computer Science, KU Leuven University, Heverlee, 3001, Belgium
b
Department of Computer Science, University of Auckland, Private Bag 92019, Auckland 1142, New Zealand
a r t i c l e i n f o a b s t r a c t
Article history: The Internet of Things (IoT) is heavily affecting our daily lives in many domains, ranging from tiny wear-
able devices to large industrial systems. Consequently, a wide variety of IoT applications have been devel-
Keywords: oped and deployed using different IoT frameworks. An IoT framework is a set of guiding rules, protocols,
Internet of Things and standards which simplify the implementation of IoT applications. The success of these applications
IoT mainly depends on the ecosystem characteristics of the IoT framework, with the emphasis on the security
Framework mechanisms employed in it, where issues related to security and privacy are pivotal. In this paper, we sur-
Platform vey the security of the main IoT frameworks, a total of 8 frameworks are considered. For each framework,
Security we clarify the proposed architecture, the essentials of developing third-party smart apps, the compati-
ble hardware, and the security features. Comparing security architectures shows that the same standards
used for securing communications, whereas different methodologies followed for providing other security
properties.
© 2017 Elsevier Ltd. All rights reserved.
1. Introduction Very recently, several IoT frameworks have been launched by

the major shareholders in the IoT domain and by the research
The Internet of Things (IoT) plays a remarkable role in all as- community in order to support and make it easy to develop, de-
pects of our daily lives. It covers many fields including healthcare, ploy and maintain IoT applications. Each player built his approach
automobiles, entertainments, industrial appliances, sports, homes, depending on his vision towards the IoT world [1]. In this survey,
etc. The pervasiveness of IoT eases some everyday activities, en- we compare the properties of a subset of IoT frameworks, targeting
riches the way people interact with the environment and sur- in particular their security features. The selected set of IoT plat-
roundings, and augments our social interactions with other peo- forms1 includes: AWS IoT from Amazon, ARM Bed from ARM and
ple and objects. This holistic vision, however, raises also some con- other partners, Azure IoT Suite from Microsoft, Brillo/Weave from
cerns, like which level of security the IoT could provide? and how Google, Calvin from Ericsson, HomeKit from Apple, Kura from Eclipse,
it offers and protects the privacy of its users? and SmartThings from Samsung.
Developing applications for the IoT could be a challenging task We selected the above frameworks based on the following cri-
due to several reasons; (i) the high complexity of distributed com- teria: (i) the reputation of the vendors in the software and elec-
puting, (ii) the lack of general guidelines or frameworks that han- tronics industries, (ii) the support of rapid application development
dle low level communication and simplify high level implementa- and the number of applications on the store, (iii) the coverage and
tion, (iii) multiple programming languages, and (iv) various com- usage of the framework, and it’ s popularity in the IoT market.
munication protocols. It involves developers to manage the in- The objectives of this survey are manifold:
frastructure and handle both software and hardware layers along
with preserving all functional and non-functional software require- • Giving a picture of the current state of the art IoT platforms and
ments. This complexity has led to a quick evolution in terms of in- identifying the trends of current designs of such platforms.
troducing IoT programming frameworks that handle the aforemen- • Providing a high level comparison between the different archi-
tioned challenges. tectures of the various frameworks.
• Focusing on the models designed and approaches developed for
ensuring security and privacy in these frameworks.
∗
Corresponding author.
E-mail addresses: [email protected] (M. Ammar),
1
[email protected] (G. Russello), [email protected] (B. Crispo). In this paper, the terms Framework and Platform are used interchangeably.
https://doi.org/10.1016/j.jisa.2017.11.002
2214-2126/© 2017 Elsevier Ltd. All rights reserved.
M. Ammar et al. / Journal of Information Security and Applications 38 (2018) 8–27 9
• Illustrating the pros and cons of each framework in terms of

fulfilling the security requirements and meeting the standard
guidelines.
• Exploring the design flaws and opening the door for more in
depth security analysis against potential threats.
The remainder of this paper is structured as follows:

Section 2 describes the general concept of the IoT framework. Re-
lated works are presented in Section 3. Section 4 is the backbone
of this paper which provides a horizontal overview of the various
IoT frameworks and focuses on the related security features. A dis-
cussion is provided in Section 5. Finally, Section 6 concludes this
study.
2. Background
The very rapid growth of Internet-connected devices, ranging

from very simple sensors to highly complex cloud servers, shapes
the Internet of Things, where Things, in this context, refers to a
wide variety of objects (e.g. smart bulbs, smart locks, IP cameras,
thermostats, electronic appliances, alarm clocks, vending machines,
and more). The resemblance between all IoT objects is the ability
to connect to the Internet and exchange data. The network connec-
tivity feature allows controlling objects remotely across the exist- Fig. 1. A high level system model of IoT.
ing network infrastructure, resulting in more integration with the
real world and less human intervention. The IoT transforms these
objects from being classical to smart by exploiting its underlying (CoAP) [9], Message Queue Telemetry Transport (MQTT) [10], Exten-
technologies such as pervasive computing, communication capabil- sible Messaging and Presence Protocol (XMPP) [11], Advanced Mes-
ities, Internet protocols, and applications. Protocols are required in saging Queuing Protocol (AMQP) [12], and Data Distribution Service
order to identify the spoken language of the IoT devices in terms of (DDS) [13].
the format of exchanged messages, and select the correct bound- The system model, presented in Fig. 1, helps to gain a better in-
aries that comply with the various functionality of each device. Ap- sight into the real meaning of IoT, and understand the importance
plications determine levels of granularity and specialty of the IoT of having a framework, in which, hiding the complexity and bring-
device and how big are the data generated for analytics purposes. ing simplicity to application development are axial. The IoT frame-
They also indicate the general scope of the IoT framework covering work should handle the life cycle of sensing, computing, delivering,
the context of the applied domain. and presenting data. Depending on their capabilities, some IoT de-
The concept of IoT framework entails identifying a structure vices can reach the outside world (e.g. the cloud) directly and some
which coordinates and controls processes being conducted by the others must connect to a hub or a gateway in order to connect to
various IoT elements. This structure is a set of rules, protocols the external world. For the IoT frameworks considered in this sur-
and regulations that organize the way of processing data and ex- vey, the cloud is the backbone, which offers databases for storing
change messages between all involved parties (e.g. embedded de- data, services for data analytics, security modules for preserving
vices, cloud, end-users). Also, it should support the high level im- confidentiality and supports privacy, and other services. Customers
plementation of IoT applications and hide the complexity of infras- use their smart phones, tablets, or laptops to interact with other
tructure protocols. There are several approaches that can be fol- IoT devices indirectly through either a cloud backend or a gateway.
lowed to build an IoT framework depending on the requirements In spite of targeting the same objective, different approaches
of the target business [2]. have been designed and followed by vendors in order to build their
In this survey, we are targeting IoT frameworks based on the IoT frameworks. In particular, the following questions arise regard-
public cloud approach, as they are the most commonly used and ing the design details of such frameworks:
widely available in the IoT market. The main building blocks of any
cloud-based IoT framework are the physical objects and the pro-
• How each IoT framework handles the communication processes
tocols. Physical objects include: (i) smart devices such as sensors,
between IoT devices and cloud? Between cloud and end-users?
actuators, etc., (ii) servers act as a cloud-backend or hubs/gateways
What are the protocols and techniques used?
for routing, storing, and accessing various pieces of data, and (iii)
• What are the hardware and software dependencies in each
end-users represented by the applications they use to access data
framework?
and interact with IoT devices. Protocols run on different layers and
• To which extents these frameworks use the common security
provide end-to-end communication. To the best of our knowledge,
standards?
there is no a standard IoT architecture yet. For simplicity, we are
• What are the security-related functionality offered by each ele-
considering the basic one which is a 3-layer architecture [3] com-
ment/layer in each IoT framework?
posed of Application, Network, and Perception layers. The Perception
• How each framework solves the challenge of preserving secu-
layer belongs to the physical devices that identify and sense ana-
rity and privacy among all involved parties? what are the tech-
log data and then digitize it for transportation purposes. Infras-
niques used for providing authentication, authorization, access
tructure protocols such as ZigBee [4], Z-Wave [5], Bluetooth Low
control, cryptography, and other security features?
Energy (BLE) [6], WiFi, and LTE-A [7] run in the Network layer. The
Application layer is the interface for end-users to access data and
talk to their IoT devices. It supports standard protocols such as Hy- Section 4 answers the above questions for each framework con-
per Text Transfer Protocol (HTTP) [8], Constrained Application Protocol sidered in this study.
10 M. Ammar et al. / Journal of Information Security and Applications 38 (2018) 8–27
3. Related work
Several survey papers have been published covering various

topics of the IoT domain. Al-Fuqaha et al. [14] surveyed the IoT
in general, mentioning various IoT architectures, market opportu-
nities, IoT elements, communication technologies, standard appli-
cation protocols, main challenges and open research problems in
the IoT area. Derhamy et al. [2] presented a number of commercial
IoT frameworks and provided a comparative analysis based on uti-
lized approaches, supported protocols, usage in industry, hardware
requirements, and applications development. A brief overview of
the current IETF standards for the Internet of things is provided
in [15].
Security and privacy issues in IoT had a lot of attention by
the research community and addressed at different levels. In [16],
the authors surveyed the security and privacy issues in IoT from Fig. 2. AWS IoT architecture.
four different perspectives. First, they highlight on the limitations
of applying security in IoT devices (e.g. battery lifetime, comput-
The Device Gateway acts as an intermediary between connected
ing power) and the proposed solutions for them (e.g. lightweight
devices and the cloud services, which allows these devices to talk
encryption scheme designed for embedded systems). Second, they
and interact over the MQTT protocol. In spite of being an old
summarize the classifications of IoT attacks (e.g. physical, remote,
protocol, in comparison with other IoT protocols, Amazon uses
local, etc.). Third, they focus on the mechanisms and architectures
MQTT [10] due to several features; (i) fault tolerance property, (ii)
designed and implemented for authentication and authorization
excellent for intermittent connectivity, (iii) small footprint in terms
purposes. Last, they analyse the security issues at different layers
of the space needed in the device memory, (iv) very efficient in
(e.g. physical, network, etc.). Authors in [17,18] addressed the se-
terms of the network bandwidth requirements, and (v) depends on
curity and privacy issues in IoT at each layer identified in the 3-
the publish/subscribe programming model to allow one-to-many
layer architecture [3,19] surveyed most of the security flaws exist-
communication between various devices [27]. The latter feature
ing in IoT, resulted from the various communication technologies
means that sensors and other embedded devices that are moving
used in wireless sensor networks. An authorization access model
and talking to the Device Gateway do not need to know who is
is proposed in [20] as a security framework for the IoT in order
sending data to them. They just send the data route and those who
to ensure controlling access and authorizing legitimate users only.
subscribe to the data will receive it. This enables a scalable en-
Authors in [21] reviewed the challenges and approaches proposed
vironment for low-latency, low-overhead, and bi-directional com-
to overcome the security issues of the IoT middleware, where a
munication. Under the hood, the Device Gateway is built in a fully
large number of existing systems inherit security properties from
managed and highly available environment controlled by the com-
the middleware frameworks. Depending on the well-known secu-
munity of Amazon in order to simplify the development of appli-
rity and privacy threats, authors analyse and evaluate the available
cations and provide unified security measures to all users. Secure
middleware approaches and show how security is handled by each
communication between IoT devices and applications is guaranteed
approach. The work concludes with illustrating a set of require-
because MQTT messages are carried out over TLS (Transport Layer
ments to have a secure IoT middleware.
Security), the successor of SSL (Secure Socket Layer) [28]. Further-
All of the aforementioned surveys review the IoT security with
more, the Device Gateway supports WebSockets and HTTP 1.1 pro-
regards to one element of the common IoT standards (e.g. network
tocols [29].
protocols or middleware employed). To the best of our knowledge,
On the other hand, the Device Gateway is teamed up with an-
this survey is the first one of addressing the IoT security at the
other component called Rules Engine. The Rules Engine processes
programming level by evaluating the security features of a subset
incoming published messages and then transforms and delivers
of commercially available IoT programming frameworks.
them to other subscribed devices or AWS cloud services, as well as
to non-AWS services via AWS Lambda [30] for further processing or
4. IoT Frameworks analytics. This enables the possibility to build IoT applications that
orchestrate, collect, process, analyze, and act on data generated and
4.1. AWS IoT published by connected devices globally without having to pay at-
tention to the low level network protocols or manage any infras-
AWS (Amazon Web Services) IoT [22] is a cloud platform for the tructure. In order to maintain usability, developers can author rules
Internet of things released by Amazon. This framework aims to let and add them to the Rules Engine by writing SQL-like statements
smart devices easily connect and securely interact with the AWS or using the AWS Management Console service [31]. Considering the
cloud and other connected devices. With AWS IoT, it is easy to example shown in Listing 13 , the rule consists of two main seg-
use and utilize various AWS services like Amazon DynamoDB [23], ments: the SQL statement and the actions list. The SQL statement
Amazon S3 [24], Amazon Machine Learning [25], and others. Fur- identifies the publish/subscribe topics to apply the rule on, and the
thermore, AWS IoT allows applications to talk with devices even conditions under which the rule should be executed. The actions
when they are offline.2 list specifies a set of actions that should be performed when the
SQL statement is executed. The rule definitions use a JSON-based
4.1.1. Architecture schema.
As shown in Fig. 2, the AWS IoT architecture consists of four ma- Rules behave differently depending on the content of each in-
jor components: the Device Gateway, the Rules Engine, the Registry, coming message. Apart from this, the Rules Engine offer dozens of
and the Device Shadows [26]. built-in helping functions and calculations to aggregate, transform,
2 3
Using Device Shadows as discussed later in the Architecture. This example has been taken from the online Amazon tutorials.
Fig. 3. AWS IoT security mechanism.
of libraries to help connecting hardware devices, authenticating

Listing 1. Example of a defined rule in the rules engine.
with the cloud, installing mobile applications, and exchanging mes-
sages easily. It supports different programming languages including
C and JavaScript.
concatenate, and process data and build very sophisticated rules.
Developers can create their own functions and define others us- 4.1.2. Smart applications specifications
ing AWS Lambda. the Rules Engine can receive data from multiple The AWS IoT has no restrictions regarding either the program-
sources, different devices, and even from the AWS cloud. It inte- ming languages of developing smart applications or operating sys-
grates and routes this information to other IoT devices and AWS tems running them. Users can use various platforms (e.g. mobiles,
cloud services such as Amazon Kinesis [32], Amazon S3, Amazon Dy- laptops, etc.) to interact with their cloud-connected IoT devices
namoDB, etc. via REST APIs. In general, there are two types of smart applica-
The Registry unit is responsible for assigning a unique Id to each tions in AWS IoT;companion and server apps. The latter are de-
connected device regardless the device type, vendor, or the way of signed and implemented to monitor, manage, and control a large
connection. Also, it stores the metadata (e.g. device name, Id, at- number of connected devices at the same time. An example of a
tributes, etc.) of connected devices in order to have the capability server application would be a fleet management website that plots
of tracking them. If the device is not active anymore and did not thousands of trucks on a map in real-time. Companion apps are
show up in the network for a period of 7 years, the metadata will mobile or web-based applications that allow end-users to inter-
be expired and removed from the Registry. Either AWS IoT Manage- act with their cloud-connected devices. As stated previously, com-
ment Console or the AWS Command Line Interface [33] can be used panion and servers apps can access and communicate with device
to interact with the Registry and configure it manually. shadows in the cloud via uniform Restful APIs.
AWS IoT instantiates each connected device by creating a virtual
image called Device Shadow. This shadow is persistent and stored 4.1.3. Hardware specifications
in the cloud to be available and accessible all the time. It repre- AWS IoT provides an open-source client libraries and device
sents the last state of the device when it was online, and enforces SDKs that make the framework available for several embedded op-
the future state over the physical device once it shows up again in erating systems and microcontroller platforms. To the best of our
the network. This means that cloud services and other devices can knowledge, the device SDKs supports C, Node.js, and the Arduino
integrate, communicate, and read the current state of a certain de- platform. Any IoT device can connect to the AWS IoT cloud if it has
vice through its shadow even if the device is offline. They can up- the ability to be configured using one of the aforementioned pro-
date the state of the device as well. Updates are applied once the gramming languages. Even those devices that connect to private IP
device gets online. Reading the last reported state and setting the networks or communicate using non-IP protocols, e.g. ZigBee, can
desired future state is done by interacting with Device Shadows via access the AWS IoT cloud as long as they are connected to a physi-
REST API or by using the Rules Engine. This functionality helps in cal hub, which serves as an intermediary gateway for the external
easily controlling devices and performing actions over them with- world (e.g. AWS cloud).
out having to know about the low level of connectivity. This means
that the shadow accelerate applications development by providing
4.1.4. Security features
a uniform and available interface to devices, even when they use
Amazon leverages a multi-layer security architecture for the
different IoT communication and security protocols, or even when
AWS IoT, in which, the security is applied at every level of the
they are constrained by intermittent connectivity, limited band-
technology stack. The design of the security architecture is based
width, limited computing ability, or limited power. From a pro-
on teaming up the Message Broker service with the Security and
gramming point of view, the Device Shadow is a JSON document,
Identity service as shown in Fig. 3 4 .
which used to store and retrieve the current state of a certain de-
vice. • Authentication: In order to connect a new IoT device to the
Optionally, applications can communicate directly to the con- AWS IoT Cloud, the device has to be authenticated. The AWS
nected physical devices using only the Device Gateway and the IoT supports mutual authentication at all points of connection,
Rules Engine. This means ignoring the Registry and Device Shadow. so that the source of the transmitted data is always known. In
Nevertheless, it is not recommended since the user has to focus general, AWS IoT provides three ways of verifying identity:
on maintaining the underlying communication protocols and solv- • X.509 certificates [34].
ing synchronization issues between the connected devices and the • AWS IAM users, groups, and roles [35].
cloud. • AWS Cognito identities [36].
AWS IoT provides a Device SDK which makes it easy for the de-
vice to synchronize its state with its shadow, and accept the de-
sired future states. In particular, The AWS IoT Device SDK is a set 4
The figure has been taken from Amazon documentation.
The most commonly technique used for authentication, in AWS

IoT, is X.509 certificates [37]. They are digital certificates, de-
pend on the public key cryptography, and should be issued by
a trusted party called a certification authority (CA). In our case,
the security and identity unit in the AWS IoT cloud acts as a CA.
These certificates are SSL/TLS-based to ensure secure authenti-
cation. Utilizing the authentication mode in the SSL/TLS proto-
col, AWS IoT verifies the certificate of any object by asking the
client for his ID (e.g. AWS account) along with the correspond-
ing X.509 certificate to check validity against a registry of cer-
tificates. AWS IoT then challenges the client to prove the owner-
ship of the private key that belongs to the public key provided
in the certificate. Optionally, the user can use his own certifi-
cate issued by his preferred CA. However, he must register this
certificate in the registry.
HTTP and WebSockets requests sent to the AWS IoT are authen-
ticated using either AWS Identity and Access Management (AWS
IAM) [38] or AWS Cognito [39]. Both of which support the AWS
method of authentication. It’s called AWS Signature Version 4
(SigV4) [40]. For HTTP protocol, it is optional to use one of
these methods for authentication, but using MQTT requires au-
thenticating using only X509 certificates. In contrast, connec-
tion using WebSockets is limited only to the use of SigV4 for
authentication.
To sum up, each IoT device, connected to the AWS IoT, is au-
thenticated using one of the methods discussed, chosen by the
end-user. It is the responsibility of the message broker to au- Fig. 4. mbed OS architecture.
thenticate and authorize all actions in the user’s account. In

particular, it is responsible to authenticate all attached devices,
securely ingest device data, and adhere to the access permis- 4.2. ARM mbed IoT
sions applied by the user on his devices using policies.
• Authorization and access control: The authorization process ARM mbed IoT is a platform to develop applications for the
in AWS IoT is policy-based. It can be applied by either map- IoT based on ARM microcontrollers [42]. It provides all require-
ping authored rules and policies to each certificate or apply- ments through it’ s ecosystem to build either an IoT standalone
ing IAM policies. This means that only devices or applications applications or networked ones [43]. ARM mbed IoT platform aims
specified in these rules can have access to the corresponding to provide scalable, connected, and secure environment for IoT
device, that this certificate belongs to. This can be ensured by devices by integrating mbed tools and services, ARM microcon-
the use of the Rules Engine since the communication through trollers, mbed OS, mbed Device Connector, and mbed Cloud.
AWS IoT follows the principle of least privilege. The Rules Engine ARM mbed IoT framework has the advantage over the vast ma-
has the responsibility to leverage the AWS access management jority of frameworks by providing a common OS foundation for de-
system to securely access and transfer data to its final destina- veloping IoT. It supports the most important communication pro-
tion according to the predefined rules/policies. So, the owner tocols for connecting devices with each others and with the cloud.
of a cloud-connected device can write some rules in the Rules Furthermore, it supports automatic power management in order to
Engine to authorize some devices or applications to access his solve the power consumption problem.
device and prevent others. The use of AWS policies or IAM poli-
cies offers a complete control over own devices and regulates
other’s right to access their capabilities and perform operations 4.2.1. Architecture
over them [41]. The key building blocks of the ARM mbed IoT platform are mbed
• Secure communication: All traffic to and from AWS IoT is OS, mbed client library, mbed cloud, mbed device connector, and
encrypted over SSL/TLS protocol. TLS is used to ensure the hardware devices based on ARM microcontrollers. The mbed OS
confidentiality of the application protocols (MQTT, HTTP) sup- represents the backbone of this platform. Therefore, discussing it’ s
ported by AWS IoT. For both protocols, TLS encrypts the con- architecture helps in simplifying the architecture of the ARM mbed
nection between the device and the Message Broker. Many IoT platform and clarifying it.
TLS cipher suites are supported in AWS IoT including: ECDHE- ARM mbed OS [44] is an open source and full stack operating
ECDSA-AES128-GCM-SHA256, AES128-GCM-SHA256, AES256- system designed for embedded devices, specifically, ARM Cortext-
GCM-SHA384, etc. Furthermore, AWS IoT supports Forward Se- M microcontrollers, used to power smart homes and smart cities.
crecy, a property of secure communication protocols, in which It is built in a modular fashion, so that developers can use it as
compromising long-term keys does not compromise temporary a complete operating system or just pick what meets their needs
session keys. This means that a malicious user who learns the from its modules. The mbed OS represents the device-side com-
private key of an IoT device should not be able to decrypt any ponent and stands on the top of a device security module, called
communication protected under this key unless learning the mbed uVisor.
temporary key of each session. Fig. 4 presents the various modules of the architecture of the
AWS IoT cloud assigns a private home directory for each legiti- mbed OS. It is an event-driven architecture and does not support
mate user. All private data are stored encrypted using symmet- multi-threaded environment. mbed OS provides a core operating
ric key cryptography (e.g. AES128). system, drivers that simplify the connectivity with the hardware
layer, security and device management functionality, a suite of
Fig. 5. ARM mbed IoT architecture.
standard communication protocols, and multiple APIs for integra-

tion and interaction purposes.
The mbed device interface layer supports a wide variety of com- Fig. 6. ARM mbed IoT security architecture.
munication protocols including Bluetooth low energy (BLE), WiFi,
Ethernet, ZigBee IP, 6LoWPAN, and many others. In particular, the
TLS/DTLS sub-layer represents mbed TLS security module and en- The top layer of the mbed IoT architecture is the third-party ap-
sures the end-to-end security across the communication channels. plications. Developers can implement various web and smart ap-
Also, multiple application protocols are supported in the architec- plications to manage cloud-connected IoT devices via REST API.
ture such as CoAP, HTTP, and MQTT.
mbed OS is designed to work in concert with mbed Device Con- 4.2.2. Smart applications specifications
nector, mbed Device Server, and mbed Client. Together, they form the Using the mbed IoT platform involves implementing embedded
platform that delivers comprehensive IoT solutions. applications for IoT devices as well as smart apps for end-users.
A high level view of the mbed IoT architecture is provided in Developers have to use C++ programming language at the device
Fig. 5. The hardware layer, at the base, represents mbed IoT-enabled side. At the user side, there is no prior requirements, any program-
devices. One level up, the mbed OS takes a place with all it’ s com- ming language supports REST API can be used (e.g. Java) [48].
ponents.
The mbed client Library is the key to communicate with the up- 4.2.3. Hardware specifications
per layer in the architecture. In particular, it encapsulates a sub- ARM mbed IoT platform is mainly dedicated to ARM Cortex-M
set of the mbed OS functionality in order to be able to connect based 32-bits5 microcontrollers supporting advanced RISC architec-
physical devices to the mbed Device Connector Service. Practically, ture. Other microcontrollers are not supported.
the mbed Client Library is a C++ API which implements a commu-
nication stack with low power consumption based on CoAP, and
supports security measures (e.g. mbed TLS) that comply with con-
The security architecture of mbed IoT platform is applied at
strained networks and devices. Furthermore, it is portable to var-
three different levels:
ious operating systems (e.g. RTOS and Linux) and supports OMA
Lightweight Machine to Machine (LWM2M) compliance [45]. • The device itself (as a hardware & mbed OS).
The mbed Device Connector is a web service that helps devel- • The communication channels.
opers to connect IoT devices to the cloud without taking care of • The lifecycle of developing embedded and smart applications in
the infrastructure [46]. It is full compatible with the mbed OS and terms of device management, firmware updates, etc.
can be accessed via the mbed Client Library. Also, it works with
REST APIs, making it easy to integrate and transit to the various Fig. 6 provides an overview of the security architecture [49].
commercial service providers. Moreover, the mbed Device Connec- The core components are:
tor provides end-to-end trust and security using TLS/DTLS, and
supports a wide range of standard protocols including CoAP/HTTP, • The mbed uVisor [50]: the device-side security solution, which
TLS/TCP, DTLS/UDP and OMA Lightweight M2M. has the ability to isolate various pieces of software from each
Recently, ARM community announced about mbed Cloud [47], others and from the operating system.
and integrated it into the IoT ecosystem. It is a Software as a Ser- • The mbed TLS [51]: for securing communication, confidentiality,
vice (SaaS) solution for managing IoT devices. The mbed Cloud al- and authentication purposes.
lows users to securely update, provision, and connect devices. It
The following security properties are provided by the aforemen-
aims to provide all security guarantees in terms of cryptography
tioned security components.
modules, trusted zones, keys management, etc. Because of being a
SaaS, the mbed Cloud can be shipped out and configured by end
users depending on their business needs. In practice, the mbed De- 5
8-bits and 16-bits architectures can be used without selecting security modules
vice Connector is a hosted instance of the mbed Cloud services. in mbed OS.
• Authentication: There is no specific way of authentication.

ARM mbed IoT provides a wide variety of cryptography stan-
dards, key exchange mechanisms, certificate-based signatures,
and symmetric and public/private key encryptions through the
mbed TLS software block [51]. Developers can pick from this
basket what is suitable for them to perform the authentication
process efficiently e.g. X.509 certificates.
• Authorization and access control: Arm mbed IoT devices sup-
port multiprogramming, so memory is not a single unprotected
space, but it’s organized into compartmentalized blocks, result-
ing in good security levels. Therefore, in order to control access
to resources and preserve levels of authorization, the mbed IoT
platforms depends on the ARMv7-M architecture in terms of
having MPU and uVisor components.
The Memory Protection Unit (MPU) is a hardware module, which
enforces memory isolation. The uVisor is a self-contained soft-
ware hypervisor, which represents the basis of the kernel of
mbed OS security architecture. It acts as a sandbox and uses
the MPU to enforce isolated security domains within the mi-
crocontroller itself (Cortext-M3, M4, or M7). Forming isolated
domains protect sensitive parts of the system, as each part is
located in a different portion of the memory. In other words,
the application will be composed of some non-intersected sec-
tions. Attacking any section does not violate others. Moreover,
having any bug or security flaw in some sections of the system
does not threaten others.
In summary, the uVisor secures software running on Cortex-M3, Fig. 7. Azure IoT architecture.
Cortex-M4, and Cortex-M7 processors by segmenting mem-

ory into insecure (public) and secure (private) memory spaces
based on the MPU. Stream Analytics) or offered immediately to some services for real-
• Secure communication: End-to-end security is ensured be- time analytics. The output of both tracks is presented and visual-
tween all involved parties in the communication channel by ized in a customized way that fits the desires of customers and
implementing the TLS/DTLS protocol. It is the cornerstone of suites their business.
securing all communications. Azure IoT Hub [54] is a web service that enables bi-directional
In mbed OS, the mbed TLS provides security mechanism in order communication between devices and the cloud backend services
to secure and protect communication, by supporting Transport taking into account all security requirements. The cloud sends
Layer Security (TLS) and the related Datagram TLS (DTLS) pro- messages to devices in terms of either commands or notifications.
tocol. Both protocols are the state of the art standards for se- Commands are orders to devices to perform actions, whereas no-
curing communication over the World Wide Web. This means tifications are information needed in some cases during the lifecy-
preventing eavesdropping, tampering and message forgery and cle of the execution of some commands. For each command being
ensuring integrity. sent, the cloud backend should receive a feedback from the de-
The mbed TLS also includes reference quality software imple- vice as a confirmation message of successful delivery, or a deliv-
mentations of a wide range of popular cryptographic primitives, ery fault message to warn about the delivery failure status. Simi-
secure key management, certificate handling, and other crypto- larly, devices send messages to the cloud backend in two formats:
graphic functionality. In addition, ARM benefits from the hard- telemetry data or commands outcome. Azure IoT hub has an iden-
ware cryptography block in some microcontrollers to encrypt tity registry for holding the identity and authentication related in-
sensitives parts of data. formation of each device. Also, it has device identity management
unit to manage all connected and authenticated devices.
4.3. Azure IoT Suite There are two classes of IoT devices: IP-capable and PAN. IP-
capable devices have the ability to communicate with Azure IoT
Microsoft has released Azure IoT Suite [52], a platform composes Hub directly by implementing one of the supported communica-
of a set of services that enable end-users to interact with their IoT tion protocols [55]. Azure IoT Hub natively supports communication
devices, receive data from them, perform various operations over over AMQPs, MQTT or HTTP protocols. Support for additional pro-
data (e.g. aggregation, multidimensional analysis, transformation, tocols is possible via Azure IoT protocol gateway [56]. The gateway
etc.), and visualize it in a suitable way for business. Azure IoT Suite allows for protocol adaptation. Some devices and field gateways
addresses the challenge of having a full-featured IoT framework as might not able to use one of the supported protocols by Azure IoT
a combinations of three different sub-problems: scaling, telemetry Hub. In this case, they can communicate with Azure IoT Hub via
patterns, and big data. Azure IoT supports a wide range of hardware Azure IoT protocol gateway which acts as a bidirectional bridge. It
devices, operating systems, and programming languages. reduces the gap between the different communication protocols,
and tries to find a common language between all involved parties.
4.3.1. Architecture From one side, the protocol gateway uses MQTT/AMQP protocol to
A high level overview of Azure IoT’ s architecture is provided communicate with Azure IoT Hub directly. From the other side, it
in Fig. 7 [53]. IoT devices interact with Azure cloud through a is adaptable to support a variety of communication protocols de-
predefined cloud gateway. The incoming data from these devices pending on the connected device standards.
is either stored in the cloud for further processing and analytics The Field Gateway is simply an aggregation point for PAN (per-
by Azure cloud services (e.g. Azure Machine Learning and Azure sonal area network) devices. Since these constrained devices do
not have enough capacity to run secured HTTP sessions, they send
their data to the field gateway to aggregate, store, and forward it
securely to Azure IoT Hub.
The IoT solution backend layer represents a wide range of Azure
cloud services [57] (e.g. Azure Machine Learning, Azure Stream An-
alytics, etc.).
The top layer of Azure IoT architecture is the presentation layer.
Users are free to visualize their data as they want. Microsoft pro-
vides the Business Intelligence (BI) service to present data in an
effective and attractive way [58].
4.3.2. Smart application specifications

Microsoft provides various SDKs to support different IoT devices
and platforms. IoT device SDKs along with IoT service SDKs are
provided in order to make developers able to connect to Azure IoT Fig. 8. Azure IoT security architecture.
Hub and let users manage their devices. The IoT device SDKs en-
able developers to implement client applications for a wide vari-
ety of devices ranging from simple network-connected sensors to the handshaking process. The cloud service is authenticated by
a powerful standalone computing devices. Up to now, C, Node.js, sending an identity proof in terms of X.509 certificate to the
Java, Python, and .NET programming languages are supported in targeted IoT device. Azure IoT issues a unique device identity
such SDKs [59]. key for each device at deployment time. The device then au-
thenticates itself to Azure IoT Hub by sending a token contains
an HMAC-SHA256 signature string which is a combination of
4.3.3. Hardware specifications
the generated key along with a user-selected device Id.
Azure IoT supports a wide range of operating systems and
• Authorization and access control: Azure IoT takes benefits of
hardware devices. The following conditions must be satisfied in
Azure Active Directory (AAD) [63] to provide a policy-based au-
each device in order to have the ability interact with Azure IoT
thorization model for data stored in the cloud, enabling easy
cloud [59]:
access, management, and auditing. This model also enables
• TLS support: for secure communication. near-instant revocation of access to data stored in the cloud,
• SHA-256 support: for authentication purposes. and of connected IoT devices. Azure IoT Hub identifies a set of
• Memory footprint: the memory footprint mainly depends on access control rules to grant or deny permissions to either IoT
the SDK and the protocol used, in addition to the platform tar- devices or smart apps. System-level authorization makes access
geted (e.g. the minimum requirement of RAM used by C SDK is credentials and permissions near-instantly revocable. Therefore,
64KB). The access control policies include activation and dis-activation
• Real time clock: having a real time clock or being able to con- of the identity of any IoT device.
nect to an NTP server is important for establishing TLS connec- • Secure communication: SSL/TLS protocol is used to encrypt
tions and generating secure tokens for authentication. communication and ensure the integrity and confidentiality of
data. The identity registry in Azure IoT Hub provides a secure
Only IP-capable devices can communicate directly with Azure storage of the identities of devices and security keys. Further-
IoT Hub (see Fig. 7). Other low-power constrained devices are able more, data is stored in either DocumentDB [64] or in SQL
to connect via a field gateway if they satisfy the aforementioned databases, ensuring a high level of privacy.
conditions.
Compatible operating systems and platforms include Windows,
Android, Debian, mbed OS, Windows IoT Core, Arduino, TI-RTOS, 4.4. Brillo/Weave
and many others. A complete list of the compatible operating sys-
tems, platforms and hardware devices exists in the Azure Certified Google released Brillo/Weave platform for the rapid implemen-
for IoT device catalog6 . tation of IoT applications. The platform consists of two main back-
bones: Brillo [65] and Weave [66]. Brillo10 is an android-based oper-
ating system for the development of embedded low power devices,
whereas Weave acts as a communication shell for interactions and
Azure IoT takes the advantage of the security and privacy built
message-passing purposes. The main role of Weave is to register
into the Azure platform, along with Security Development Lifecy-
a device over the cloud and send/receive remote commands. Both
cle (SDL)7 [60] and Operational Security Assurance (OSA)8 [61] pro-
components complement each other and together form the IoT
cesses for secure development and operation of all Microsoft soft-
framework. Brillo/Weave is mainly targeting smart homes and ex-
wares. In the architecture of Azure IoT, security is embedded into
panding to support general IoT devices.
every layer and enforced in each component of the ecosystem.
Fig. 8 gives an overview of Azure IoT security architecture9 [62].
4.4.1. Architecture
• Authentication: In order to establish a connection between Fig. 9 provides an overview of the architecture of Brillo/Weave
IoT devices and Azure IoT Hub, mutual authentication is re- framework, which includes two sub-architectures belonging to
quired. Transport Layer Security (TLS) protocol is used to encrypt Brillo and Weave respectively.
Brillo is a light-weight embedded operating system based on
6
https://catalog.azureiotsuite.com/.
Android stack and fully implemented in C/C++ programing lan-
7
SDL is a software security assurance process that helps developers to address guages. It does not support any Java framework or runtime.
security requirements and build more secure software along with reducing devel-
opment cost.
8 10
OSA is a framework incorporates a variety of security capabilities including SDL. Recently, Google released a rebranded version, called AndroidThings but it still
9
The Figure has been taken from Microsoft Azure documentation. does not support Weave to create a fully featured IoT framework.
thermore, Weave exists as a mobile SDK for smart phones and a

cloud-based web services for the cloud. Mobile SDK runs on ei-
ther Android or iOS phones in order to connect mobile apps to the
Brillo-powered IoT devices. Once the connectivity gets established,
mobile apps can use either the local APIs, if they are located in the
same network, or the cloud APIs to control and manage the con-
nected IoT devices. As shown in Fig. 9, Weave supports multiple
communication and application protocols.
To sum up, the underlying architecture illustrates the key build-
ing blocks of Brillo/Weave IoT framework. The last three layers rep-
resent the operating system, whereas the top layer includes the
core services which composes of OTA Updates, Weave, and Metrics
and Analysis services. Figuratively, the Brillo developer kit (BDK) is
a necessary building block of the IoT platform [69] which is based
on Android.mk build architecture. Using DBK, developers can per-
form local unit tests, integration tests, and build entire packages.
4.4.2. Smart applications specifications

Weave comes with a mobile SDK for both iOS and Android to
build apps to control and enhance the connected device experi-
ence for mobile users. Any Android- or iOS-based mobile phone
can run smart apps able to talk to Brillo-powered embedded de-
vices. The smart app should include the Weave SDK as a commu-
nication module. In general, third party developers can implement
applications in any platform using any programming language sup-
ports Weave. On the other side, IoT devices should run Brillo in
Fig. 9. Brillo/Weave architecture. order to interact with smart apps with no further requirements.
Currently, only Google Cloud supports Weave and no other profes-
sional cloud (e.g. Amazon, Microsoft, etc.) does that.
The bottom layer represents the platform of IoT devices. The
Kernel layer is located at the top of the Hardware layer. It is Linux 4.4.3. Hardware specifications
based and it has the responsibility to provide basic architectural Brillo operating system is compatible only with Microprocessor
model for managing system resources, process scheduling, com- (MPU)12 devices that have a minimum memory footprint of at least
munication with external devices when needed and so on. Also, It 35 MB of RAM. ARM, Intel (X86), and MIPS are the only supported
provides drivers and libraries to control displays, cameras, power, architectures [69].
WiFi, keypads, and many other resources over the physical device. In particular, the minimum hardware requirements [69,71] of
However, no graphics or GNU libraries are supported. The android the smart device to host Brillo are:
HAL (Hardware Abstraction layer) is a middleware, which bridges • 32 MB RAM.
the gap between the hardware and the software. It allows android • 128 MB ROM.
applications to communicate with hardware specific device drivers • support one of the following architectures: ARM, X86, or MIPS.
by handling system calls between the kernel and the top android- • WiFi 802.11n.
based layers. Not shown in the architecture, Brillo uses Binder IPC • Bluetooth 4.0+.
mechanism [67] to interact with the android system services from
the application framework. Commercially, the Intel Edison kit [72] with the Arduino expan-
Moving upwards, the OTA Updates component [68] is a wire- sion board is the first Brillo starter board.
less service aims to install batches and update versions of software
over the air. The underlying devices perform regular checks with 4.4.4. Security features
OTA servers for updates. Also, OTA servers notify all connected de- A high priority has been given for verifying security through out
vices once there are some new updates available. Metrics compo- the design of both Brillo and Weave. Secure boot, signed over-the-
nent collects usage data from devices in order to analyze and view air updates, timely patches at the OS level, and the use of SSL/TLS
it to understand the behavioral patters of users. Also, crash reports are all building blocks of the security architecture of Brillo/Weave
can be submitted to debug remote devices. framework.
While Brillo represents the low level segment (OS) of this archi-
• Authentication: Weave main functions is the Discovery, provi-
tecture, Weave11 is the high level one. It is a communication suite
sioning, and authenticating devices and users. OAuth 2.0 pro-
of protocols and APIs that lets smart phones, IoT devices, and the
tocol along with digital certificates are used for authentication.
cloud to communicate with each others. In addition, it provides
Regardless the Weave-enabled cloud server chosen by the user,
services for authentication, discovery, provisioning, and interaction.
Google provides the authentication server.
Practically, Weave is following a JSON format. As mentioned before,
• Authorization and access control: The right of access con-
Weave module is baked into the Brillo OS as a significant part of
trol is ensured by the Linux kernel. SELinux (Security Enhanced
the top layer in Brillo’ s architecture. Weave adds a key feature to
Linux) module is responsible for ensuring access control secu-
the user experience through the capability to connect to devices
rity policies, in which the owner of an IoT device can apply
directly or via the cloud. This is achieved by exposing a common
multiple levels of access control as needed. Enforcing access
language between all Brillo-powered devices, which is Weave. Fur-
12
For the difference between MPU and MCU devices, please refer to refer-
11
Google Weave is totally different from NEST WEAVE protocol. ence [70].
the platform specific features like sensors and actuators in a uni-

form manner to the platform independent runtime layer where it
resides above the platform dependent runtime layer. The platform
independent runtime layer acts as an interface to the actors. The
runtime can be configured to grant access to different resources
depending if an actor is a part of the application or not. Actors ex-
ecute asynchronously and autonomously per definition. They can
also encapsulate protocols, such as REST or SQL queries, as well
as device specific I/O functionality. Connections between actors are
not specified in the architecture since they are logical and dynam-
ically handled by the different runtimes.
Proxy Actors [77] is one of the important features that Calvin
brings to the users. Using this attribute, Calvin-based applications
can scale and function with non-Calvin ones. Proxy Actors help in
integrating different systems as one system by handling communi-
cation and doing the task of converting data to messages or tokens
that both systems can understand.

Fig. 10. Calvin architecture. Calvin framework divides the development process of an ap-
plication into four pipelined isolated steps, each step has its own
control is done by assigning the actual rights (read, execute, functionality as explained in the following [78]:
write) for each user or group of users. Describe: the functional part of any application which consists
Again, as this IoT framework is Linux-based, sandboxing tech- of reusable components or blocks called Actors. An actor is a com-
nique is applied with regards to UID (User Id) and GID (Group ponent representing any object doing a computation e.g. smart
Id). It provides an enhanced mechanism to enforce the sepa- phone, cloud, client, server, and etc. The way of communication
ration of information based on confidentiality and integrity re- between actors is by passing tokens over predefined ports. This is
quirements for each profile. the only way to affect the behavior of an actor and change its state.
• Secure communication: Secure communication are guaranteed Data is processed on the input ports of actors and then passed to
via Weave by providing link-level security through the SSL/TLS the output ports in order to fire some actions depending on the
protocol. Furthermore, the Linux kernel supports full disk en- contents of messages/tokens. Thus, writing an actor means identi-
cryption of saved data. Also, Brillo depends on a Trusted Execu- fying a new component that can be used in several locations by
tion Environment (TEE) and secure boot to protect code and data multiple applications. An actor can be created by (i) describing its
loaded inside the IoT and preserve confidentiality. The availabil- actions, (ii) defining its input/output ports, (iii) identifying condi-
ity of TEE provides the connected devices Hardware-backed key- tions for each particular action to be triggered, and (iv) adjusting
store/ketmaster [73]. the priority orders between actions.
Connect: in this interaction step, information about how ac-
4.5. Calvin tors are connected is supplied in a simple way using CalvinScript, a
declarative language used to describe applications and how actors
Calvin is an open source IoT platform released by Ericsson [74]. connected inside them. At the end of this phase, the application is
It is designed for building and managing distributed applications completely identified and ready for deployment.
that enable devices talk to each others. Calvin is a framework that Deploy: after completing the two former steps, the deployment
applies Flow based Computing (FBP)13 paradigm [75] methodologies phase takes a place in order to run the application in reality. The
over the well-defined actor model14 [76]. core of this step is the lightweight distributed runtime that pro-
vides a number of accessible nodes for deployment and actors exe-
4.5.1. Architecture cutions. Once the runtime environment is ready for execution after
Fig. 10 shows the high level architecture of Calvin. The two bot- passing the application script to it, the distributed execution envi-
tom layers compose a foundation for the runtime environment15 . ronment can move actors to any accessible runtime based on sev-
The base layer represents the hardware or the physical device, eral factors such as resource, locality, connectivity, or performance
whereas the second one encapsulates the operating system that requirement.
the hardware exposes. At the top, the platform dependent runtime Manage: it monitors the life cycle of the application. Fur-
layer of Calvin takes a place. In this layer, all kinds of communica- thermore, it is involved in keeping track of the resource usage,
tions between different runtime environments (e.g. IoT devices) are firmware updates, error recovery, and scalability.
handled. Also, this layer provides an abstraction of the hardware In order to support multiple programming languages and plat-
functionality (e.g. I/O operations). In other words, this layer sup- forms, the design of Calvin does not require a specific way of pro-
ports several transport layer protocols (WiFi, BT, i2c) and presents cessing data inside different actors. Only the format of data passed
between ports is standardized. An API, written in python, is pro-
13
vided to device manufacturers and third party developers to port
The FBP development approach views an application as a network of asyn-
chronous processes communicating by passing messages as streams of structured
to Calvin runtime from various platforms and languages.
data chunks, called information packets. This component-oriented model does not
support single sequential processes which start at a particular point of time, do 4.5.3. Hardware specifications
operations, and then finish to let others start their actions. Calvin framework supports different platforms, ranging from
14
The actor model is a mathematical theory that treats Actors as the universal
small sensor devices to data centers. Also, it is designed to run
primitives of concurrent digital computation. The model has been used as a frame-
work for a theoretical understanding of concurrency. in distributed heterogeneous cloud environment. The only require-
15
Runtime environment means the IoT device with the executable software ment needed in the hardware is the support of one of the compat-
loaded into it. ible communication protocols.
Fig. 11. Calvin communication system.

Calvin platform applies security measures at different levels us-
ing various techniques [79].
• Authentication: Authenticating users can be done in three dif-

ferent ways. The first is via local authentication, in which the
hash value of usernames and passwords are stored in a JSON
file in a well-known directory in the same machine. Authenti-
cation can be verified by comparing the hash value of the en-
tered and stored records. Second, using an external machine, Fig. 12. HomeKit architecture.
which acts as an authentication server and performs the au-
thentication on behalf of the corresponding runtime. Third, by
using a RADIUS server. The radius server verifies the username and providing digital signatures, as it incurs limited overhead,
and password and replies with subject attributes. compared with other protocols (e.g. RSA). Calvin framework can
• Authorization and access control: Authorization is only sup- be integrated with any public cloud system since it does not
ported via local or external procedure. In the local authoriza- involve Ericsson cloud as a main component of the ecosystem.
tion, policies are stored in JSON files in a directory on the same Therefore, Calvin does not provide details of the object level-
machine, whereas the external authorization involves using an- security in the cloud.
other runtime to act as an authorization server. When external
authorization is used, digital certificates in the form of X.509
4.6. HomeKit
standards are needed to verify signed JSON web tokens that
contain the authorization request/response. The authorization
HomeKit is an IoT framework released by Apple [80]. It is a
process must be done after a successful authentication since
platform dedicated only to home-connected IoT devices. It facil-
it uses as an input the returned subject attributes. The access
itates the process of managing and controlling connected acces-
control is activated for a certain actor or entity via an attribute-
sories and appliances in a user’ s home by enabling interaction via
based configuration file. Adding a feature with its value as an
smart apps. Through their own iOS devices, using the HomeKit app,
attribute means activating this feature in Calvin framework.
called Home, users can discover, configure, control, and manage all
To the best of our knowledge, neither sandboxing nor virtual-
HomeKit connected devices in a secure way. Furthermore, users can
ization technique are provided in Calvin framework because Er-
create actions and trigger their IoT devices using Siri service [81].
icsson does not maintain their own cloud infrastructure.
Until the moment of writing, iOS, watchOS, and tvOS are the only
• Secure communication: Fig. 11 shows an overview of the em-
operating systems supporting the HomeKit capabilities.
ployed communication mechanism inside Calvin system. IoT de-
vices can interact with each other or with smart applications.
They are connected over short-range radio protocols to M2M 4.6.1. Architecture
gateways. Devices and gateways are integrated with the mo- The core components of HomeKit architecture are: the HomeKit
bile network in order to access the cloud. End-users commu- configuration database, HomeKit Accessory Protocol (HAP), HomeKit
nicate with the cloud and explore the various information of API, and the HomeKit-enabled devices.
the different IoT devices, that they authorized to access. IoT de- Fig. 12 simplifies the HomeKit architecture. The IoT devices (ac-
vices can not connect to the cloud via M2M gateways with- cessories) are located in the base layer. However, not all home-
out conducting the authentication and authorization processes. connected IoT devices can integrate with the HomeKit platform
Since M2M gateways have no user interface for entering user- directly. They should meet some conditions as explained later in
names and passwords, Calvin depends on the mobile networks the hardware specifications section. Accessories that do not satisfy
and utilizes their capabilities. All M2M gateways are injected HomeKit requirements are still able to connect to the HomeKit plat-
with SIM cards, and use their SIM-based identity to authen- form using intermediate devices called Bridges. HomeKit Bridges are
ticate themselves to the cloud services using 3GPP standard- gateways that act as a proxy between iOS applications and home
ized Generic Bootstrapping Architecture (GBA). The transmit- automations that do not support the HomeKit protocol. At the de-
ted/received data may be secured using TLS/DTLS protocol. El- vice side, the bridge supports only ZigBee and Z-Wave protocols.
liptic Curve Cryptographic (ECC) algorithm is implemented as a Therefore, the connected accessories are limited to support one of
part of the TLS suite and used for encrypting communications these protocols. For accessories that implements HAP, the bridge is
not required and either IP (LAN, WiFi) or BLE is used as a transport to be uniquely identified and each one should points to its own
protocol. data. Everything in a home must have a unique name as well. Nar-
Since HomeKit speaks HAP, the backbone of the architecture is rowing the scope, the instance of the Room class lets users to add
the HAP layer. HAP is proprietary protocol mapped over HTTPs the number of rooms they have inside their homes. From a pro-
with discovery leveraging the Bonjour architecture16 [82]. JSON for- gramming point of view, each room is an array of accessories. Each
mat is used in HAP for exchanging messages between iOS apps and input of this array belongs to an instance of the Accessory class.
HomeKit compliant devices. An accessory corresponds to the physical IoT device. Accessories
The HomeKit API layer is responsible for providing interfaces to are assigned and distributed between rooms. The instance of the
third party developers to simplify the development of smart appli- accessory object allows users to access the device state. Also, ac-
cations and hide the complexity of the underlying layers. cessories have to be uniquely named within a home. Names of ac-
The application layer resides at the top of the architecture. It cessories can be recognized by Siri service too. An accessory is the
is responsible for providing a consistent user interface to all Apple whole object that the a user is referring to. So, an accessory has a
devices sharing the same account, by synchronizing the stored data pointer back to the room where it is located, and it has a pointer to
in the shared database using iCloud [83]. the array of services that represents its functionality. An accessory
With tvOS 10 [84], Apple extended the capabilities on the Ap- at any point of time may be reachable or not depending on the
ple TV and HomeKit by bringing the HomeKit framework to the state of connectivity. This should be reflected in the smart applica-
tvOS. Interestingly, Apple TV is able to run all home automations tion by maintaining the callback handler available to developers in
that users have set up inside their homes. Therefore, wherever the API [85].
users are, if they have an Internet connection, they can access their Services represent the functionality of accessories. A service is
home accessories remotely. In other words, Apple TV acts as a hub described as a collection of characteristics. Characteristics are spe-
or a gateway for home automations. cific parameters that the user could interact with. Not all of ser-
Apple TV also supports features for providing additional con- vices have names. The anonymous services are operational ones
trols to shared users. This enables the possibility of any user to and not designed for user interaction (e.g. a firmware update ser-
share the control of accessories with others, by inviting them us- vice). Named services should be unique and exposed within the
ing their Apple Id. It is also possible to grant administrative access user interface. An example of such services are the light bulb
to shared users. Shared users with an administrative access can and door bell. HomeKit does not only recognize names of services,
change the configurations in the home. They can add or remove but also takes into account Apple-defined service types. Therefore,
accessories as necessary. Also, they, in turn, can invite additional users can refer to the service by its name or type when using Siri
users to the home and let them control home accessories. Another to detect it. The Service class contains the name of the service,
possibility is controlling remote access per user. Using this func- an array of characteristics, service type, and a pointer back to the
tionality, the admin user can grant or deny remote access capabil- accessory. Characteristics provide some information and metadata
ities to the other shared users. about the state of the physical device. The characteristics can be of
a few varieties: Read-only, Read-write, or Write-only. A good ex-
4.6.2. Smart application specifications ample is the thermostat device, where users want to read its tem-
An important part of the HomeKit ecosystem is the Home appli- perature degree without writing privileges. This implies that the
cation. It is an Apple-designed app for HomeKit platform. It sets up characteristics of this service should be Read-only [85].
home accessories as well as controls their common functions. HomeKit objects are stored in a database residing in the user’ s
The Home app provides a very simple interface for users to set iOS device, which is synchronized over the iCloud to other involved
up, control, and configure accessories inside the home. The Home iOS devices. This common database contains all information about
app is supported in all iOS devices and in the Apple watch. Using homes and accessories that have been configured by users. It is
its user interface, the user can add a number of homes and de- available to all user’ s applications in a consistent way [85].
fine number of rooms in each home. Then, he start setting up and
detecting accessories in each room.
Due to the integration with Apple system, HomeKit allows users 4.6.3. Hardware specifications
to access their accessories when they are not at home. This re- HomeKit framework is compatible only with HomeKit-enabled
mote access enabled through iOS device connectivity, in which the devices. Thus, HomeKit supports all third-party hardware acces-
Apple TV acts as a gateway and intermediate layer between home- sories that use Apple’ s MFi licensed technology [86] to connect
connected accessories and Internet-connected Home app or even electronically to the iPhone, iPad, iPod or Apple Watch. By us-
third party apps. ing Apple’ s MFi license, Apple ensures that the produced hard-
Additionally, developers can implement iOS-based mobile ap- ware meets all key requirements and technical specifications of the
plications and bring their apps to the foreground by utilizing the HomeKit framework in terms of the supported communication pro-
HomeKit API provided by Apple [85]. Using this API, developers tocols, physical security, etc.
can implement their applications by creating instances of a lim- As stated earlier, in order to connect an accessory, that is not
ited number of classes, delegating them to their apps and then MFi-certified, to the HomeKit framework, A HomeKit bridge must
customizing them according to the requirements. The architecture be used to find a common language between the heterogeneous
of HomeKit API is hierarchical. The entry point is the Home Man- transport protocols. The bridge supports only ZigBee and Z-Wave
ager class which provides pointers to a common database shared protocols from the input side of the accessory.
among all user’ s homes and maintains their data. Being shared, From a low level point of view, HomeKit supports a wide range
such database ensures consistency between all authorized applica- of embedded microcontrollers including low-power, low-cost 32
tions in various devices. The Home Manager acts as a container of bit MCUs. Both ARM and MIPS architectures are supported. Gener-
multiple homes and lets the user to label the primary one. Also, it ally, the memory is the most critical resource in microcontrollers.
lets the user to add or remove homes as necessary. Each home has However, for HomeKit, there is no minimum requirements for the
size of memory since it mainly depends on the specific goal of the
16
Bonjour is Apple framework for networking purposes. It implements a number
MCU and the size of the code loaded.
of functionalities including: service discovery, address assignment, and hostname For users, HomeKit-enabled accessories can be controlled and
resolution. managed only by Apple smart devices such as iPhones and iPads.
There is no support for devices powered by other operating sys-

tems such as Android.

HomeKit leverages many features from the security architecture
of iOS [87] as it composes of software, hardware, and services de-
signed to work together in a secure way, in which, end-to-end se-
curity must be guaranteed. This means that the entire ecosystem
is covered by the security polices and mechanisms enforced by the
tight integration of hardware and software in iOS devices.
• Authentication: Authentication is required between HomeKit-
connected accessories and iOS devices based on Ed2551917
public-private key signature [88]. For each user and accessory
in the HomeKit framework, an ed25519 key pair is generated
for authentication purposes. Keys are stored in shielded key-
chain and synchronized between devices using iCloud Keychain.
In the authentication process, keys are exchanged using Secure
Remote Password protocol, in which a 8-digit code, provided by
the accessory’s manufacturer, must be entered by the user via
the UI of the iOS device.
Keys are encrypted using ChaCha20-Poly1305 AEAD with HKDF-
SHA-512-derived keys [87]. The accessory’ s MFi certification is
also verified during setup. The aforementioned keys are long-
term keys. In order to protect each communication session, a
temporary session key is generated using the Station-to-Station Fig. 13. Kura architecture.
protocol and encrypted with HKDF-SHA-512 derived keys based
on per-session Curve25519 keys [89]. The process of configuring
Moreover, HomeKit provides Perfect Forward Secrecy, a property
Apple TV in order to perform remote access and the process of
that ensures in every communication session between an Apple
adding new shared users are also subjects to the same authen-
users’s devices and their HomeKit enabled accessories, a new
tication and encryption mechanisms.
session key is generated for secrecy and confidentiality pur-
• Authorization and access control: Applications have to ex-
poses. After the completion of the underlying session, this key
plicitly ask user’s permissions to get access to their home
is discarded. This feature strengthens the communication pro-
data. Moreover, all applications are subject to security measures
cess in case, in the future, the device is compromised and the
designed to prevent collisions and compromising each other.
long-term key is publicly known, the adversary can not decrypt
Sandboxing is enforced among apps. An application can access
the communication process using only this long-term key.
its own data only, which stored in a unique home directory.
This directory is assigned randomly during the installation pro-
4.7. Kura
cess of the application. On the other hand, iOS system data is
isolated from third-party apps and users have no privilege to
Kura is an Eclipse IoT project which aims to provide a
modify it in any case. Also, Address Space Layout Randomiza-
Java/OSGi-based18 framework for IoT gateways that run M2M ap-
tion (ASLR) technique [90] is applied to prevent buffer overflow
plications [93]. Kura offers a platform for managing the interac-
memory-based attacks.
tion between the local network of physical IoT devices and the
• Secure communication: The integration of the core compo-
public Internet or the cellular networks. Similarly to other frame-
nents of the iOS security architecture (e.g. secure boot, etc.)
works, Kura abstracts and isolates the developer from the com-
ensures that only trusted code can run in Apple devices. AES
plexity of the hardware, networking sub-systems, and re-defining
256 encryption protocol is applied through an engine built into
the development of existing software components, by offering an
the DMA path between the flash storage and the main system
APIs that allow accessing and managing the underlying hardware
memory in each device, making data encryption is highly effi-
smoothly [94].
cient. Each Apple device has a unique device Id which is AES
256-bit key injected into the processor during manufacturing
4.7.1. Architecture
and this allows data to be cryptographically tied to one par-
Fig. 13 shows an overview about Kura’ s architecture. Kura can
ticular device only. This feature provides a robust secure hard-
only be installed on Linux-based devices and provides a remotely
ware in case the memory chip is moved from a device to an-
manageable system, complete with all the core services and a
other one, the data is inaccessible and can not be read or de-
device abstraction layer for accessing the gateway’s own hard-
crypted. Apart from this, all cryptographic keys are created by
ware [95].
the system’ s random number generator (RNG) using an algo-
To interact with network-connected devices, smart applications
rithm based on CTR_DRBG [91].
can use Java’ s own networking capabilities to plug into the ex-
Communication using HTTP protocol are secured using
isting device infrastructure. The device abstraction layer allows de-
TLS/DTLS with AES-128-GCM and SHA-256.
velopers to access many devices by abstracting the hardware us-
In HomeKit, the long-term keys, used to secure communica-
ing OSGi services for Serial, USB and Bluetooth communications.
tions, reside only in the user’ s devices. So even if the com-
munication flows through an intermediate devices or services,
the keys can not be decrypted even by Apple. 18
The OSGi specification Open Services Gateway initiative describes a modular
system and a service platform that implements a dynamic component system for
Java to simplify the process of developing reusable software building blocks. For
17
https://ed25519.cr.yp.to/. more information, refer to [92].
A communication API for devices attached via GPIO, I2C, or PWM

will allow a system integrator to incorporate a custom hardware as
a part of their gateway [96].
The Gateway Basic Services layer provides a configurable OSGi
services available to applications to interact with the basic gateway
functionality. Such services include watchdog, clock, GPS position,
embedded database, process, and device profile service.
Also, the network management layer offers a configurable OSGi
services to access the current network configuration and adminis-
ter it (e.g. DHCP, NAT, DNS, etc.). It interacts with the Linux system
to configure network interfaces including WiFi access points and
PPP connections.
Furthermore, the connectivity & delivery layer simplifies the de-
velopment of telemetry M2M applications interacting with a re-
mote cloud server [97].
The functionality of Remote Management layer include remote Fig. 14. SmartThings architecture.
configuration, remote software update, remote system command,
remote log retrieval, device diagnostic service, and remote VPN ac-
cess. Finally, The administration GUI provides interfaces for access- • Authorization and access control: The security service com-
ing such services. ponent in Kura offers API to manage security policies and start
script consistency, whereas the certificate service API is used
4.7.2. Smart applications specifications to retrieve, store and verify certificates for SSL, device manage-
Java is the main programming language of Kura framework. An ment and bundle signing.
application is delivered as an OSGi module and run according to Ensuring the non-corruption or non-tampering with a file by a
the standard specifications inside the container along with other malicious user is done by doing a regular check of environmen-
components. The deployment of an application can be done re- tal integrity by the security manager component. ESF also en-
motely in the form of OSGi bundles. Kura package provides also forces runtime policies to deny execution of particular services
a web front interface that allows developers to remotely login and or the import/export of specific packages. This makes it harder
manage their applications. for hackers to access the service for retrieving the master pass-
word from the device.
4.7.3. Hardware specifications • Secure communication: The SSL manager manages SSL certifi-
Kura has two hard requirements in order to run on the IoT de- cates, trust stores and private and public keys. All communi-
vice. First, it must run at the top of Linux operating system. This cations are secured using SSL/TLS protocol. The cryptography
means that the IoT device should be Linux-based. Second, Ora- APIs are used to encrypt and decrypt secrets and to retrieve the
cle Java VM 7 or later is required for Kura [98]. Memory size re- master password.
quirement depends on how large is the installed application and
number of exchanged messages with other connected devices. An 4.8. SmartThings
example of compatible devices, that meet the mentioned require-
ments, includes Raspberry Pi [99] and BeagleBone [100]. SmartThings is a platform released by Samsung for developing
IoT applications. It is mainly dedicated to smart homes, where de-
4.7.4. Security features velopers can implement applications that let users manage and
The naive Kura framework provides a robust and simple secu- control their home appliances via smart phones [104].
rity architecture for protecting and securing communications with
IoT devices and gateways. However, there is a limited support for 4.8.1. Architecture
securely updating and configuring devices from cloud applications. According to Fig. 14, the SmartThings ecosystem comprises of
To handle this issue, Eurotech [101] released an open-sourced ESF, the following components: the SmartThings cloud backend, the
a tool can be used along with Kura [102]. ESF adds support for ad- SmartThings hub/home controller, the SmartThings mobile client app
vanced security, remote access via virtual private network (VPN), (the buddy app), and the IoT device (SmartDevice).
diagnostics and bundles for specific vertical applications. ESF max- The hub (home controller) acts as a gateway between the IoT
imizes the productivity by utilizing the basic Kura security API to devices (SmartDevices) and the cloud services. It connects directly
make it easier to write Java applications that can ensure the in- to the Internet and supports multiple communication protocols in-
tegrity and security of new software bundles. cluding ZigBee, Z-Wave, WiFi, and BLE. The SmartThings hub has
Eclipse foundation has injected also a number of security com- the ability to execute some functionality locally without the need
ponents into the Kura framework such as a security service, a cer- to connect to the cloud backend. Events are still required to be
tificate service, a secure sockets layer (SSL) manager, and a cryp- sent to the cloud once the hub gets online in order to reflect the
tography service. current state of the home and execute other cloud-based services.
Communication between all connected parties are encrypted using
• Authentication: SSL/TLS protocol.
Kura uses secure sockets provided by the Java Runtime envi- The buddy app, released by SmartThings, lets users access the
ronment. The Eclipse Paho client19 [103] handles the majority home controller, manage their IoT devices smoothly, and, if re-
of data communication via MQTT protocol [97]. This includes quired, install third party applications (SmartApps). The buddy app
using public key cryptography to authenticate communication is supported by multiple mobile operating systems including An-
with remote devices and gateways. droid and iOS. While the buddy app provides a basic and unified
interface to all connected devices, SmartApps are customized ap-
19
The Paho Java Client is an MQTT client library written in Java for developing applications, developed by third party developers, add more options
plications that run on the JVM or other Java compatible platforms such as Android. and functionality to the end-user. Three classes of SmartApps are
vices and APIs in order to support the integration with third party
applications.
The SmartThings cloud backend has two important functionality.
First, it hosts and run SmartApps in a closed source environment.
Second, it runs the virtual software image of the physical Smart-
Device. In other words, it provides the abstraction and intelligence
layers as well as web services that support the application layer.

SmartApps should be implemented using a web-based IDE, of-
fered by SmartThings, and in Groovy programming language [107].
Following a particular structure, a SmartApp is composed of five
sections: definition, preferences, predefined callbacks, event handlers,
and mappings. The latter is optional and only required for cloud-
connected SmartApps. The definition section holds the metadata
of the application (e.g. application name, author, etc.). The prefer-
ences section is responsible for defining the target group of devices,
specifying their capabilities and then reflecting the information to
Fig. 15. The structure of the SmartThings cloud system.
the user interface for interaction purposes. The pre-defined call-
backs are methods already defined and automatically called upon
meeting some conditions during the life cycle of the SmartApp. Fi-
specified: (i) Event-handlers, (ii) Solution Modules, and (iii) Service nally, the event handlers section contains the handler methods of
Managers. Event-handler SmartApps allow end-users to subscribe to the various events.
events and call handler methods upon their firings. Solution Module
SmartApps act as a container for the two other categories of Smar- 4.8.3. Hardware specification
tApps and simplify the management of a certain physical area in- SmartThings platform supports a wide variety of IoT devices that
side the home (e.g. bedroom). They are predefined by SmartThings may either integrate with the SmartThings hub or connect directly
developers and thus they can be installed via the SmartThings ap- to the cloud backend. These devices are manufactured by several
plication interface (the buddy app). Lastly, Service Manager Smar- vendors like Samsung, Google, Amazon, Philips Hue and many oth-
tApps are applications that integrate with SmartDevices and should ers. The only required specification is the ability to communicate
be installed by end users in case of the presence of the device using one of the compatible protocols.
on the network. SmartApps may run on the hub as well as in the
cloud depending on the physical characteristics of the SmartDevice.
SmartThings has a security architecture that specifies what
SmartDevices may have the ability to connect via WiFi/IP proto-
SmartDevices a SmartApp may access and what services can a
col. This feature lets these devices to bypass the gateway and con-
SmartApp utilize in the authorized SmartDevice. In the following,
nect directly to the SmartThings cloud. Each SmartDevice belongs
we are discussing the security attributes verified by this architec-
to one or more of the following categories: (i) Hub-connected, (ii)
ture.
LAN-connected, and (iii) Cloud-connected [105]. Hub-connected de-
vices include all devices that have the capability to interact with • Authentication: Integrating new SmartDevice in SmartThings
the SmartThings hub using ZigBee or Z-Wave home automation environment involves the use of OAuth/OAuth2 protocol for au-
protocols, whereas LAN-connected devices have an extra feature thenticating this SmartDevice and authorizing SmartThings plat-
which lets them to communicate with the hub over the LAN, e.g. form to access its capabilities. Cloud- and LAN-connected de-
Sonos system. Cloud-connected devices, e.g. Ecobee thermostaat, con- vices follow a bit different procedure for authentication due to
nect to the cloud directly using HTTP and authenticate themselves the use of other communication protocols to bypass the gate-
using OAuth protocol. Both LAN and Cloud-connected devices are way and connect directly to the cloud. Both of them require
able to communicate and integrate via web services like REST or identifying a custom service manager SmartApp along with a
SOAP [104]. device handler for establishing connections, handling authenti-
There are two ways of communication between SmartApps cation, granting authorization, and maintaining communication.
and SmartDevices; (i) Method calls, in which, SmartApps can ex- The main functions of the service manager are handling authen-
ecute and perform operations over SmartDevices, and (ii) Event- tication with 3rd party cloud service, device discovery, initiat-
Subscription, where SmartApps can subscribe to events generated ing connection using OAuth protocol, and controlling SmartDe-
by other SmartApps or SmartDevices. vice actions. The device handler is responsible for parsing mes-
Fig. 15 gives an overview of the key building blocks of the sages being sent or received by the corresponding SmartDe-
SmartThings cloud [106]. The Connectivity Management layer is re- vice. On the other hand, identifying the SmartDevice through
sponsible for maintaining persistent and secure connection be- out the authentication process is based on many factors due
tween the connected device (e.g. the hub) and cloud services. The to the wide range of the supported SmartDevices from various
Device Type Handlers layer simplifies the scalability by maintain- vendors. Examples of such factors include unique identifier e.g.
ing an instance or a virtual image for each type of SmartDevices. serial number, media access control (MAC) address, unique IP
End-users interact with the physical SmartDevices indirectly via address, and so on.
instances, hosted in the cloud. The Subscription Processing layer • Authorization and access control: Accessing SmartDevices us-
acts as an event manager for routing events from hubs/devices to ing SmartApps follows the policies governed by the SmartThings
SmartApps that are subscribed to a specific SmartDevice/event. The Capability model. Capabilities is an important concept in the un-
SmartApp Management & Execution layer provides access rights to derlying architecture which belongs to a logical layer that pro-
the stored data, and is responsible for the execution of the Smar- vides an abstraction of the capabilities of SmartDevices. The
tApp when triggered via either subscriptions or external calls. The SmartApp should ask for a permission to use a capability of-
top layer of the stack is the Web UI layer which provides web ser- fered by a SmartDevice. The capability, as identified by its
Table 1
Examples of capabilities in SmartThings.
Resource Name Capability Command Attributes
Switch capability.switch on(), off() switch(status: string)

Energy Meter capability.energyMeter – energy(status: Integer)
Thermostat capability.thermostat off(), heat(), cool(), fanOn(), ... temperature, thermostaatMode(status: string)
Smoke Detector capability.smokeDetector – smoke(status: string) //possible values:detected, clear, or tested
Notification capability.notification deviceNotification(status: string) –
name, is composed of a set of commands and their associ- protocol. For access control, they behave a little bit differently;
ated attributes. Commands are methods or functions to perform some of them implements sandboxing techniques and some oth-
some actions on the SmartDevice, whereas attributes are input ers propose their own models (e.g. capability model in SmartThings,
parameters representing the state of the device. Table 1 pro- configuration files in Calvin, etc.). Various cryptography primitives
vides some examples of some capabilities in the SmartThings and cipher suites are supported by each framework depending on
platform. As a consequence of applying this model, installing the availability of either supported software libraries or hardware
a battery-monitoring SmartApp will be authorized to use the modules. Techniques used to perform the mutual authentication
capability of battery and prevented from accessing other re- between the involved parties in each framework are limited to the
sources or capabilities supported by the SmartDevice. coverage domain and the capabilities of communication protocols.
All SmartApps are executed by the SmartThings ecosystem. This Theoretically, the presented security architectures seem to be ro-
means that these apps run either in the closed-source cloud or bust and immune against potential threats. However, design flaws
on the SmartThings hub. The SmartThings infrastructure environ- still exposes users to significant security risks if good practices
ment applies Kohsuke sandboxing technique [108] and isolates in both design and implementation are not followed. Fernandes
both SmartApps and SmartDevices (Device Handler instances) et al. [109] constructed four proof-of-concept attacks by exploit-
from each other [109]. In the sense of providing a highly con- ing two design flaws in SmartThings framework. On the other hand,
trolled environment by Groovy, Kohsuke sandbox is an efficient some security challenges are still not handled by the majority of
implementation that isolates untrusted running pieces of code IoT frameworks. The vast majority of IoT devices depend on the
and allows only method calls that are predefined in a white list, commercial of the shelf (COTS) microcontrollers, and these devices
stored in the restricted operating system. Developers can not are deployed without hardware security support. However, the de-
create their own classes or load external libraries in such envi- sign of the security models of the current frameworks does not
ronment and once they publish a SmartApp or a SmartDevice, consider these devices. Encryption techniques need higher com-
a private isolated data store is assigned. puting power than what the simplest type of IoT devices can pro-
• Secure communication: The SmartThings Hub is a security- vide. Some frameworks (e.g. HomeKit) create and inject the se-
enabled Z-Wave product. When a security-enabled Z-Wave de- cret key of the IoT device prior deployment to be used for the
vice is added to the Hub’s network, communication will be whole lifetime of the device. This key can’t be changed after de-
encrypted using 128-bit AES. As the hub also supports the ployment. This increases the overall on-boarding time and threat-
ZigBee protocol, it provides the same security guarantees for ens the privacy as, generally, IoT entities may not be owned by a
ZigBee-enabled products. In general, communications between single user (e.g. selling or exchanging this device between multiple
all building blocks of the SmartThings ecosystem is performed users). Moreover, the embedded device may outlive the encryption
over a SSL/TLS protocol. algorithm lifetime, causing a cavity in the security architecture. For
example, smart meters could last beyond 40 years, whereas crypto
algorithms have a limited lifetime before they are broken. There-
5. Discussion
fore, they need to be updated frequently. Physical protection is still
another security challenge couldn’t be handled easily in IoT frame-
The IoT is where the Internet meets the physical world, in
works. Deployed IoT devices can be stolen or moved from their lo-
which, a completely new dimensions to security should be inves-
cations. This requires a physical protection of the IoT device to se-
tigated as the attack threat moves from manipulating information
cure sensitive information in its memory. Addressing the privacy of
to controlling actuations. The frameworks, included in this survey,
the outlined frameworks was challenging due to the lack of infor-
approach IoT from the perspectives and priorities of their vendors.
mation in some of them. Privacy should be ensured in all levels of
At the hardware level, there is a gap between these frameworks
the architectures. SDKs offered to third party developers to imple-
in terms of compatibility. This issue is due to the requirements
ment their IoT apps should preserve privacy in terms of preventing
and dependencies of the other components of the ecosystem of
generating traceable signatures of the location and behavior of the
each framework (e.g. OS, security requirements). For example, IETF
individuals by applications. Finally, the flexibility of the security
Class-1 IoT devices can be integrated with AWS IoT framework, and
framework is a requirement. For example, If a cloud server is un-
they are not supported in Brillo/Weave because they do not have
dergoing a Denial of Service (DoS) attack, the secure availability of
sufficient memory to allocate the operating system. HomeKit con-
data for end-users should be verified by outsourcing it from a sec-
nects only to IoT devices that meet the minimum level of secu-
ondary server. For a critical industrial processes that rely on time,
rity by supporting Apple’ s MFi licensed technology. At the soft-
the availability of data is of paramount importance. This feature is
ware level, some frameworks support any programming language
not ensured by frameworks such as Kura as it is M2M framework
for apps development (e.g. AWS IoT), whereas some others are
and does not offer its own cloud system. The user of Kura has to
limited to specific programming languages (e.g. SmartThings sup-
handle it himself by choosing a cloud server that meet this prop-
ports only Groovy). At the security level, each framework encapsu-
erty.
lates its own security logic and applies the model that implements
Table 2 presents a comparison of the characteristics of each IoT
this logic. However, they follow the same trend and enforce the
framework.
same security standards in some aspects. For example, for secur-
ing communications between IoT elements, they all use SSL/TLS
24
Table 2
A brief summary of the characteristics of IoT frameworks.
IoT Framework SmartThings AWS IoT Calvin Brillo/Weave Kura ARM Mbed HomeKit Azure IoT
Company Samsung Amazon Ericsson Google Eclipse ARM Apple Microsoft
Architecture + Cloud Backend + Cloud services + Actors: smart + physical devices Java/OSGi based. + Mbed OS + + Home Conf. + Cloud backend
Components + Smart + Smart devices embedded with Mbed device D.B. + HAP + + Cloud
Devices + + Device devices, smart Brillo/Android Connector + HomeKit API + Services +
SmartThings Gateway + phones, cloud, as OS + OTA mbed Cloud + HomeKit- Cloud Gateway
Hub + Rules Engine + servers. + Flow servers + Cloud mbed Client + enabled + Smart
SmartThings Registry Unit + based Services ARM Cortex-M devices Devices
Home App. Device Shadow computing MCU
Programming Groovy Any language can + CalvinScript + Any Java + C++ for device + Swift + + C + Node.js +
Language use Restful API Python + others programming side + multiple Objective-C Java + Python +
language can for user side .Net
M. Ammar et al. / Journal of Information Security and Applications 38 (2018) 8–27

talk through
Weave SDK
Hardware + SmartThings + (optionally) NONE NONE NONE + ARM MCU + (optionally) + Azure IoT Hub
Dependencies Hub AWS hub Apple TV +
(optionally)
HomeKit bridge
Software The Home app. NONE NONE + Brillo OS + + JVM 7.0 or later + mbed OS + + iOS + watchOS NONE
Dependencies Weave SDK mbed Client + tvOS +
HomeKit app.
Compatible All MCUs that Any MCU can be Any MCU with Any MCU with Linux based + 32 bits ARM + All devices that All devices that
Hardware support configured communication memory = devices that Cortex-M MCUs support Apple’s have 64KB
compatible using C, capabilities 35 MB support JVM MFi licensed RAM and RTC
communication arduino 7.0+ technology + and support
protocols. platforms, or All devices can SHA-256
Node.js connect to
HomeKit bridge
Supported + HTTP + HTTP + + HTTP + HTTP + XMPP + MQTT + CoAP + CoAP + HTTP + + HTTP + HTTP + MQTT +
Application WebSockets + MQTT + others AMQP
Protocols MQTT
Supported Com- + ZigBee + All + WiFi + i2c + BT + WiFi + BLE + + WiFi + BLE All + WiFi + BLE + + WiFi + ZigBee +
munication Z-wave + WiFi + others Ethernet ZigBee + Z-wave +
Protocols + BLE Z-wave others
Security
Authentication + OAuth/ OAuth2 + X.509 + X.509 + OAuth 2.0 + + secure sockets + X.509 + Ed25519 + X.509
protocol. Certificates + Certificates + TEE Certificates + public/private certificates +
AWS IAM + Sim-based other standards key signature + HMAC-SHA256
AWS Cognito Identity (mbed TLS) Curve25519 signature
keys
Access Control + Capability + IAM Roles + + Configuration + SELinux + ACL + Security + uVisor + MPU + Sandboxing + + Azure Active
mode/ Rules Rules Engine + files + Sandboxing: Manager + iOS security Directory
for granting Sandboxing UID&GID Runtime architecture + Policies +
permissions + Policies ASLR Technique Access control
Sandboxing rules of Azure
Technique IoT hub
Communication + SSL/TLS + SSL/ TLS + SSL/ TLS + SSL/TLS + SSL/TLS +mbed TLS + TL S/DTL S + + TL S/DTL S
Perfect Forward
Secrecy
Cryptography + 128-bits AES + 128-bits AES + + ECC protocol Full disk Multiple + mbed TLS + + 256-bits AES + Multiple
protocol. other encryption cryptography Hardware many others cryptography
primitives supported by primitives Crypto. primitives
Linux kernel
6. Conclusion [21] Fremantle P, Scott P. A survey of secure middleware for the internet of things.
Peer J Comput Sci 2017;3:e114.
[22] Amazon. Aws iot framework. https://aws.amazon.com/iot. Online; accessed:
The IoT market is growing rapidly and as a consequence the at- April 2017.
tention has shifted from proposing single IoT elements and pro- [23] Amazon. Amazon dynamodb. https://aws.amazon.com/dynamodb. Online; ac-
tocols towards application platforms in order to identify frame- cessed: April 2017.
[24] Amazon. Amazon s3. https://aws.amazon.com/s3. Online; accessed: April
works supporting the standard IoT suites of regulations and pro- 2017.
tocols. This study has covered a subset of commercially available [25] Amazon. Amazon machine learning. https://aws.amazon.com/
frameworks and platforms for developing industrial and consumer machine-learning. Online; accessed: April 2017.
[26] Amazon. Components of aws iot framework. https://aws.amazon.com/iot/
based IoT applications. The selected frameworks have the same de-
how- it- works/. Online; accessed: April 2017.
sign philosophy in terms of identifying cloud-based applications by [27] Hunkeler U, Truong HL, Stanford-Clark A. Mqtt-sa publish/subscribe protocol
centralizing distributed data sources. However, they followed var- for wireless sensor networks. In: Communication systems software and mid-
dleware and workshops, 2008. comsware 2008. 3rd international conference
ious approaches in order to apply this philosophy. A comparative
on. IEEE; 2008. p. 791–8.
analysis of the frameworks was conducted based on the architec- [28] Dierks T., Rescorla E. The transport layer security (tls) protocol version 1.2.
ture, hardware compatibility, software requirements, and security. https://www.ietf.org/rfc/rfc5246.txt. Online; accessed: April 2017.
We highlighted on the security measures of each framework as [29] Amazon. Amazon iot protocols. http://docs.aws.amazon.com/iot/latest/
developerguide/protocols.html. Online; accessed: April 2017.
verifying the various security features and immunity against at- [30] Amazon. Amazon lambda. https://aws.amazon.com/lambda. Online; accessed:
tacks is one of the most important contemporary issues facing the April 2017.
Internet of Things. [31] Amazon. Amazon management console. https://aws.amazon.com/console. On-
line; accessed: April 2017.
[32] Amazon. Amazon kinesis. https://aws.amazon.com/kinesis. Online; accessed:
Acknowledgment April 2017.
[33] Amazon. Amazon command line interface. https://aws.amazon.com/cli. On-
This research is supported by the research fund of KU Leuven line; accessed: April 2017.
[34] Cooper D. Internet x.509 public key infrastructure certificate and certifi-
and iMec, a research institute founded by the Flemish government. cate revocation list (crl) profile. https://tools.ietf.org/html/rfc5280. Online; ac-
cessed: April 2017.
Supplementary material [35] Amazon. Iam users, groups, and roles. http://docs.aws.amazon.com/iot/latest/
developerguide/iam- users- groups- roles.html. Online; accessed: April 2017.
[36] Amazon. Amazon cognito identities. http://docs.aws.amazon.com/iot/latest/
Supplementary material associated with this article can be developerguide/cognito-identities.html. Online; accessed: April 2017.
found, in the online version, at 10.1016/j.jisa.2017.11.002 [37] Amazon. X.509 certificates. http://docs.aws.amazon.com/iot/latest/
developerguide/x509-certs.html. Online; accessed: April 2017.
References [38] Amazon. Aws identity and access management (iam). https://aws.amazon.
com/iam/. Online; accessed: April 2017.
[1] Singh D, Tripathi G, Jara AJ. A survey of internet-of-things: Future vision, ar- [39] Amazon. Amazon cognito. https://aws.amazon.com/cognito/. Online; ac-
chitecture, challenges and services. In: Internet of things (WF-IoT), 2014 IEEE cessed: April 2017.
world forum on. IEEE; 2014. p. 287–92. [40] Amazon. Signature version 4 signing process. http://docs.aws.amazon.com/
[2] Derhamy H, Eliasson J, Delsing J, Priller P. A survey of commercial frame- general/latest/gr/signature-version-4.html. Online; accessed: April 2017.
works for the internet of things. In: 2015 IEEE 20th conference on emerging [41] Amazon. Aws authorization. http://docs.aws.amazon.com/iot/latest/
technologies & factory automation (ETFA). IEEE; 2015. p. 1–8. developerguide/authorization.html. Online; accessed: April 2017.
[3] Khan R, Khan SU, Zaheer R, Khan S. Future internet: the internet of things [42] ARM. Arm mbed iot device platform. http://www.arm.com/products/
architecture, possible applications and key challenges. In: Frontiers of infor- iot-solutions/mbed-iot-device-platform. Online; accessed: April 2017.
mation technology (FIT), 2012 10th international conference on. IEEE; 2012. [43] ARM. mbed device connector. https://www.mbed.com/en/platform/cloud/
p. 257–60. mbed- device- connector- service/. Online; accessed: April 2017.
[4] Specification Z. Zigbee alliance. URL: http://www.zigbee.org 2006; 558. [44] ARM. mbed os. https://www.mbed.com/en/platform/mbed-os/. Online; ac-
[5] Z-Wave. Z-wave public specification. http://z-wave.sigmadesigns.com/ cessed: April 2017.
design- z- wave/z-wave- public- specification/, Online; accessed: April 2017. [45] mbed A. mbed client. https://www.mbed.com/en/platform/mbed-client/. On-
[6] Gomez C, Oller J, Paradells J. Overview and evaluation of bluetooth line; accessed: April 2017.
low energy: an emerging low-power wireless technology. Sensors [46] mbed A. mbed device connector. https://docs.mbed.com/docs/
2012;12(9):11734–53. getting- started- with- mbed- device- connector/en/latest/Connector-intro/.
[7] Ghosh A, Ratasuk R, Mondal B, Mangalvedhe N, Thomas T. Lte-advanced: Online; accessed: April 2017.
next-generation wireless broadband technology [invited paper]. IEEE Wireless [47] mbed A. mbed cloud. https://cloud.mbed.com/. Online; accessed: April 2017.
Commun 2010;17(3):10–22. [48] mbed A. mbed documentation. https://docs.mbed.com/. Online; accessed:
[8] Rescorla E. Http over tls 20 0 0. April 2017.
[9] Shelby Z, Hartke K, Bormann C. The constrained application protocol (coap). [49] mbed A. mbed security. https://www.mbed.com/en/technologies/security/.
Tech. Rep.; 2014. Online; accessed: April 2017.
[10] Locke D. Mq telemetry transport (mqtt) v3.1 protocol specification. http:// [50] mbed A. mbed uvisor. https://www.mbed.com/en/technologies/security/
www.ibm.com/developerworks/webservices/library/ws-mqtt/index.html On- uvisor/. Online; accessed: April 2017.
line; accessed: April 2017. [51] mbed A. mbed tls. https://tls.mbed.org/core-features. Online; accessed: April
[11] Saint-Andre P. Extensible messaging and presence protocol (xmpp): 2017.
Core2011;. [52] Microsoft. Tap into the internet of your things with azure iot suite. https://
[12] Vinoski S. Advanced message queuing protocol. IEEE Internet Comput www.microsoft.com/en- us/cloud- platform/internet- of- things- azure- iot- suite.
2006;10(6):87. Online; accessed: April 2017.
[13] Group O.M. Data distribution service v1.2. http://www.omg.org/spec/DDS/1.2/. [53] Azure M. Microsoft azure iot reference architecture. https://azure.microsoft.
Online; accessed: April 2017. com/en- us/updates/microsoft- azure- iot- reference- architecture- available/.
[14] Al-Fuqaha A, Guizani M, Mohammadi M, Aledhari M, Ayyash M. Internet of Online; accessed: April 2017.
things: a survey on enabling technologies, protocols, and applications. IEEE [54] Azure M. Azure iot hub. https://azure.microsoft.com/en- us/services/iot- hub/.
Commun Surveys Tutorials 2015;17(4):2347–76. Online; accessed: April 2017.
[15] Sheng Z, Yang S, Yu Y, Vasilakos AV, McCann JA, Leung KK. A survey on the [55] Azure M. Communication protocols. https://azure.microsoft.
ietf protocol suite for the internet of things: standards, challenges, and op- com/en- us/documentation/articles/iot- hub- devguide- messaging/
portunities. IEEE Wireless Commun 2013;20(6):91–8. #communication-protocols. Online; accessed: April 2017.
[16] Yang Y, Wu L, Yin G, Li L, Zhao H. A survey on security and privacy issues in [56] Azure M. Azure iot protocol gateway. https://azure.microsoft.com/en-us/
internet-of-things. IEEE Internet Things J 2017. documentation/articles/iot- hub- protocol-gateway/. Online; accessed: April
[17] Kumar JS, Patel DR. A survey on internet of things: security and privacy is- 2017.
sues. Int J Comput Appl 2014;90(11). [57] Azure M. Azure products. https://azure.microsoft.com/services/. Online; ac-
[18] Vikas B. Internet of things (iot): A survey on privacy issues and security 2015. cessed: April 2017.
[19] Borgohain T., Kumar U., Sanyal S. Survey of security and privacy issues of in- [58] Microsoft. Power bi. https://powerbi.microsoft.com. Online; accessed: April
ternet of things. arXiv:150102211 2015. 2017.
[20] Bouij-Pasquier I, El Kalam AA, Ouahman AA, De Montfort M. A security frame- [59] Azure M. Azore iot sdks. https://github.com/Azure/azure- iot- sdks. Online; ac-
work for internet of things. In: International conference on cryptology and cessed: April 2017.
network security. Springer; 2015. p. 19–31.
[60] Microsoft. Security development lifecycle. https://www.microsoft.com/en-us/ [86] Apple. Mfi program. https://developer.apple.com/programs/mfi/. Online; ac-
sdl/default.aspx. Online; accessed: April 2017. cessed: April 2017.
[61] Microsoft. Operational security assurance. https://www.microsoft.com/en-us/ [87] Apple. ios security. http://www.apple.com/business/docs/iOS_Security_Guide.
SDL/OperationalSecurityAssurance. Online; accessed: April 2017. pdf. Online; accessed: April 2017.
[62] Azure M. Internet of things security from the ground up. https://azure. [88] Bernstein DJ, Duif N, Lange T, Schwabe P, Yang B-Y. High-speed high-security
microsoft.com/en- us/documentation/articles/iot- hub- security- ground- up/. signatures. J Cryptograph Eng 2012;2(2):77–89.
Online; accessed: April 2017. [89] Bernstein D. A state-of-the-art diffie-hellman function. https://cr.yp.to/ecdh.
[63] Azure M. What is azure active directory. https://azure.microsoft.com/en-us/ html. Online; accessed: April 2017.
documentation/articles/active-directory-whatis/. Online; accessed: April 2017. [90] Snow KZ, Monrose F, Davi L, Dmitrienko A, Liebchen C, Sadeghi A-R. Just-in–
[64] Azure M. Documentdb. https://azure.microsoft.com/en-us/services/ time code reuse: On the effectiveness of fine-grained address space layout
documentdb/. Online; accessed: April 2017. randomization. In: Security and privacy (SP), 2013 IEEE symposium on. IEEE;
[65] Google. Brillo. https://developers.google.com/brillo/. Online; accessed: April 2013. p. 574–88.
2017. [91] Barker E., Kelsey J. Recommendation for random number generation using de-
[66] Google. Weave. https://developers.google.com/weave/. Online; accessed: April terministic random bit generators. https://doi.org/10.6028/NIST.SP.800-90Ar1.
2017. Online; accessed: April 2017.
[67] Gargenta A. Deep dive into android ipc/binder framework. AnDevCon: The [92] Alliance O. Osgi architecture. https://www.osgi.org/developer/architecture/.
Android developer conference; 2012. Online; accessed: April 2017.
[68] Google. Ota updates. https://source.android.com/devices/tech/ota/. Online; ac- [93] Organization E. Kura framework. http://www.eclipse.org/kura/. Online; ac-
cessed: April 2017. cessed: April 2017.
[69] MSV J. Google brillo vs. apple homekit: The battleground [94] Organization E. Kura framework. http://wiki.eclipse.org/Kura. Online; ac-
shifts to iot. http://www.forbes.com/sites/janakirammsv/2015/10/ cessed: April 2017.
29/google- brillo- vs- apple- homekit- the- battleground- shifts- to- iot/ [95] Organization E. Kura - osgi-based application framework for m2m ser-
#484c33674cac. Online; accessed: April 2017. vice gateways. http://www.eclipse.org/proposals/technology.kura/. Online; ac-
[70] Gaillard F. Microprocessor (MPU) or Microcontroller (MCU)? What factors cessed: April 2017.
should you consider when selecting the right processing device for your next [96] Organization E. Kura - a gateway for the internet of things. http://www.
design. Technical report, Atmel Corporation, 2013. URL http://www.atmel. eclipse.org/community/eclipse_newsletter/2014/february/article3.php. Online;
com/images/mcu_vs_mpu_article.pdf. accessed: April 2017.
[71] CNXSoft. Brillo android based os for iot projects supports arm, in- [97] Organization E. Mqtt and coap, iot protocols. http://www.eclipse.org/
tel and mips platforms. http://www.cnx-software.com/2015/10/28/ community/eclipse_newsletter/2014/february/article2.php. Online; accessed:
brillo- android- based- os- for- iot- projects- support- arm- intel- and- mips- platforms/. April 2017.
Online; accessed: April 2017. [98] Organization E. Kura - hardware targets. http://eclipse.github.io/kura/ref/
[72] Intel. Getting started with brillo on the intel edi- hardware-targets.html. Online; accessed: April 2017.
son board. https://software.intel.com/en-us/articles/ [99] Organization E. Kura - raspberry pi quick start. http://eclipse.github.io/kura/
getting- started- with- brillo- on- the- intel- edison- board. Online; accessed: doc/raspberry- pi- quick- start.html. Online; accessed: April 2017.
April 2017. [100] Organization E. Kura - beaglebone quick start. http://eclipse.github.io/kura/
[73] Android. Hardware-backed keystore. https://source.android.com/security/ doc/beaglebone- quick- start.html. Online; accessed: April 2017.
keystore. Online; accessed: April 2017. [101] Eurotech. Eurotech. https://www.eurotech.com/en/about+eurotech/. Online;
[74] Ericsson. Open source release of iot app environment calvin. https: accessed: April 2017.
//www.ericsson.com/research- blog/cloud/open- source- calvin/. Online; ac- [102] Lawton G. How to put configurable security in ef-
cessed: April 2017. fect for an iot gateway. http://www.theserverside.com/tip/
[75] Morrison JP. Flow-based programming, 2Nd edition: a new approach to ap- How- to- put- configurable- security- in- effect- for- an- IoT- gateway. Online;
plication development. Paramount, CA: CreateSpace; 2010. ISBN 1451542321, accessed: April 2017.
9781451542325. [103] Organization E. Eclipse paho. http://www.eclipse.org/paho/. Online; accessed:
[76] Hewitt C. Actor model of computation: scalable robust information systems. April 2017.
arXiv:100814592010;. [104] SmartThings. Smartthings documentation. http://docs.smartthings.com/en/
[77] Ericsson. A closer look at calvin. https://www.ericsson.com/research-blog/ latest/. Online; accessed: April 2017.
cloud/closer- look- calvin/. Online; accessed: April 2017. [105] SmartThings. Cloud and lan-connected devices. http://docs.smartthings.
[78] Persson P, Angelsmark O. Calvin merging cloud and iot. Procedia Comput Sci com/en/latest/cloud- and- lan- connected- device- types- developers- guide/. On-
2015;52:210–17. https://doi.org/10.1016/j.procs.2015.05.059. line; accessed: April 2017.
[79] Ericsson. Security in calvin. https://github.com/EricssonResearch/calvin-base/ [106] SmartThings. Smartthings architecture. http://docs.smartthings.com/en/latest/
wiki/Security/. Online; accessed: April 2017. architecture/index.html. Online; accessed: April 2017.
[80] Apple. The smart home just got smarter. http://www.apple.com/ios/home/. [107] Groovy. Groovy programming language. http://www.groovy-lang.org. Online;
Online; accessed: April 2017. accessed: April 2017.
[81] Apple. Siri. http://www.apple.com/ios/siri/. Online; accessed: April 2017. [108] Kawaguchi K. Groovy sandbox. http://groovy-sandbox.kohsuke.org/. Online;
[82] Apple. About bonjour. https://developer.apple.com/library/content/ accessed: April 2017.
documentation/Cocoa/Conceptual/NetServices/Introduction.html. Online; [109] Fernandes E, Jung J, Prakash A. Security Analysis of Emerging Smart Home
accessed: April 2017. Applications. In: Proceedings of the 37th IEEE symposium on security and
[83] Apple. icloud. http://www.apple.com/lae/icloud/. Online; accessed: April 2017. privacy; 2016.
[84] Apple. tvos. http://www.apple.com/tvos/. Online; accessed: April 2017.
[85] Apple. Homekit developer guide. https://developer.apple.com/library/content/
documentation/NetworkingInternet/Conceptual/HomeKitDeveloperGuide/
Introduction/Introduction.html#//apple_ref/doc/uid/TP40015050. Online;
accessed: April 2017.
Mahmoud Ammar is a PhD researcher in the KU Leuven Computer Science Department, where he is a member of the imec-DistriNet research group. His research interests
lie in the field of the IoT security. He is particularly interested in issues concerning the physical layer security in IoT devices based on simple microcontrollers. Mahmoud
obtained a Master of computer science from La Sapienza University of Rome in late 2015.
Giovanni Russello is a senior lecturer and leader of the digital security programme at the university of Auckland, New Zealand. He received his Ph.D. from the Eindhoven
University of Technology, The Netherlands. After obtaining his Ph.D., he was a research associate in the department of computing at Imperial College London, UK. His research
interests include policy-based security systems, privacy and confidentiality in cloud computing, smartphone security and applied cryptography.
Bruno Crispo is a professor of computer science at KU Leuven, Belgium and at the University of Trento, Italy. His research interests focus on system and network security,
mobile platform security and privacy, and access control. Crispo has a PhD in security from the University of Cambridge, UK. He’s an associate editor of the ACM Transactions
on Privacy and Security and a senior member of IEEE.
View publication stats

Internet of Things: A Survey On The Security of Iot Frameworks

Uploaded by

Copyright:

Available Formats

Internet of Things: A Survey On The Security of Iot Frameworks

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Internet of Things: A Survey On The Security of Iot Frameworks

Uploaded by

Copyright:

Available Formats

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Internet of Things: A survey on the security of IoT frameworks

Article in Journal of Information Security and Applications · February 2018

Mahmoud Ammar Giovanni Russello

SEE PROFILE SEE PROFILE

Security and Privacy in Distributed Systems View project

Privacy Protection and DRM View project

The user has requested enhancement of the downloaded file.

Contents lists available at ScienceDirect

Journal of Information Security and Applications

Internet of Things: A survey on the security of IoT frameworks

1. Introduction Very recently, several IoT frameworks have been launched by

• Illustrating the pros and cons of each framework in terms of

The remainder of this paper is structured as follows:

The very rapid growth of Internet-connected devices, ranging

Several survey papers have been published covering various

Fig. 3. AWS IoT security mechanism.

of libraries to help connecting hardware devices, authenticating

The most commonly technique used for authentication, in AWS

thenticate and authorize all actions in the user’s account. In

Fig. 5. ARM mbed IoT architecture.

standard communication protocols, and multiple APIs for integra-

• Authentication: There is no specific way of authentication.

Cortex-M4, and Cortex-M7 processors by segmenting mem-

4.3.2. Smart application specifications

thermore, Weave exists as a mobile SDK for smart phones and a

4.4.2. Smart applications specifications

the platform specific features like sensors and actuators in a uni-

4.5.2. Smart applications specifications

Fig. 11. Calvin communication system.

4.5.4. Security features

• Authentication: Authenticating users can be done in three dif-

There is no support for devices powered by other operating sys-

4.6.4. Security features

A communication API for devices attached via GPIO, I2C, or PWM

4.8.2. Smart applications specifications

Resource Name Capability Command Attributes

Switch capability.switch on(), off() switch(status: string)

M. Ammar et al. / Journal of Information Security and Applications 38 (2018) 8–27

View publication stats

You might also like