On the Security and Privacy of
Internet of Things Architectures and Systems
Emmanouil Vasilomanolakis
∗†
, J
¨
org Daubert
∗†
, Manisha Luthra
∗
,
Vangelis Gazis
†
, Alex Wiesmaier
†‡
and Panayotis Kikiras
†
∗
CASED / Telecooperation Lab,
Technische Universit
¨
at Darmstadt
{manolis, joerg.daubert}@cased.de, manisha.luthra@stud.tu-darmstadt.de
†
AGT International
{vgazis, awiesmaier, pkikiras}@agtinternational.com
‡
Department of Computer Science,
Hochschule Darmstadt
Abstract—The Internet of Things (IoT) brings together a mul-
titude of technologies, with a vision of creating an interconnected
world. This will benefit both corporations as well as the end-
users. However, a plethora of security and privacy challenges
need to be addressed for the IoT to be fully realized. In this
paper, we identify and discuss the properties that constitute
the uniqueness of the IoT in terms of the upcoming security
and privacy challenges. Furthermore, we construct requirements
induced by the aforementioned properties. We survey the four
most dominant IoT architectures and analyze their security
and privacy components with respect to the requirements. Our
analysis shows a mediocre coverage of security and privacy
requirements. Finally, through our survey we identify a number of
research gaps that constitute the steps ahead for future research.
I. INTRODUCTION
The Internet of Things (IoT) forms a dynamic global
network infrastructure with self configuring capabilities, based
on standard and interoperable communication protocols [56].
It represents the interconnection of numerous things—smart
devices and services. Currently, more than a billion devices
are connected to Internet, including PCs, embedded sensors,
and mobile phones [32]. This present Internet of smart devices
is moving towards the Internet of Things, and is expected to
comprise 16 billion interconnected devices by the year 2020
[49].
IoT applications include domestic scenarios such as smart
homes, mobility and transportation, but also industry scenarios
such as smart manufacturing processes and smart energy
grids. To reach such a level of diffuse and influence, holistic
architectures for the IoT are required. Such architectures must
cope not only with operational challenges, but also provide
security and privacy, e.g., to comply with social acceptance
[22]; society must trust that the IoT is handling such scenarios
in a secure and privacy-preserving manner.
In this paper, we first identify properties for the IoT,
by doing a comprehensive analysis of the related work,
that combined make the IoT ecosystem unique compared to
previous Information Technology (IT) infrastructures. With
respect to these properties, we construct a number of security
requirements. Furthermore, we identify the most dominant (in
terms of their openness, the amount of research and industrial
contributors, their coverage and impact, etc.) IoT architectures
and conduct a comprehensive analysis by mapping them with
the requirements. Finally, we compare the IoT architectures
and highlight the research gaps as well as the necessary steps
for a security and privacy complete IoT architecture.
The remainder of this paper is organized as follows: in
Section II, we first identify properties that make the IoT unique
in terms of the security and privacy challenges. Second, we
propose a number of security and privacy requirements that
take into account these IoT properties. Section III provides
an overview of the IoT architectures as well as a security
and privacy analysis of them with respect to our requirements.
Section IV compares all IoT architectures with a focus on the
fulfillment of the requirements. Finally, Section V concludes
the paper and gives insights regarding current research gaps
and possible future directions.
II. IOT PROPERTIES & SECURITY REQUIREMENTS
In this section, we identify the properties that constitute
the uniqueness of the IoT in terms of the security and privacy
challenges. Furthermore, we construct a number of security
and privacy requirements, based on the aforementioned prop-
erties, and discuss them in detail.
A. IoT Properties
In contrast to traditional IT systems such as enterprise
applications, cloud computing, and big data, a combination
of a number of properties makes the IoT unique in terms
of the challenges that need to be coped with. We identify
these properties by analyzing related IoT research [2]–[4],
[21], [23], [24], [35], [37], [38], [42], [54]. The identified
distinguishing properties are four, namely: the uncontrolled
environment, the heterogeneity, the need for scalability, as well
as the constrained resources utilized in the IoT:
a) Uncontrolled environment: Many things will be part
of a highly uncontrolled environment; things travel to un-
trustworthy surroundings, possibly without supervision. Sub-
properties of the uncontrolled environment are: mobility, phys-
ical accessibility, and the lack of trust.
Network
Security
Confidentiality
Integrity
Authenticity
Availability
Identity
Management
Authentication
Authorization
Accountability
Revocation
Privacy
Data Privacy
Anonymity
Pseudonimity
Unlinkability
Trust
Device Trust
Entity Trust
Data Trust
Resilience
Robustness
against
attacks
Resilience
against
failures
Fig. 1: Main security requirements and their subcomponents
• Mobility: Stable network connectivity and constant
presence cannot be expected in such an environment.
• Physical accessibility: In the IoT, sensors can be
publicly accessible, e.g., traffic control cameras, and
environmental sensors.
• Trust: A priori trusted relationships are unlikely for
the large amount of devices interacting with each
other and users [42]. Thus, automated mechanisms
to measure and manage trust of things, services, and
users are crucial for the IoT.
b) Heterogeneity: IoT is expected to be a highly het-
erogeneous ecosystem as it will have to integrate a multitude
of things from various manufacturers. Therefore, version com-
patibility, and interoperability have to be considered.
c) Scalability: The vast amount of interconnected
things in the IoT demands highly scalable protocols. This also
has an influence on security mechanisms. For instance, central-
ized approaches, e.g., hierarchical Public Key Infrastructures
(PKIs), as well as some distributed approaches, e.g., pairwise
symmetric key exchange schemes, cannot scale with the IoT.
d) Constrained resources: Things in the IoT will have
constraints that need to be considered for security mechanisms.
This includes energy limitations, e.g., battery powered devices,
as well as low computation power, e.g., micro sensors. Thus,
heavy computational cryptographic algorithms cannot be ap-
plied to all things.
B. Security Requirements for the IoT
Security and privacy are crucial enabling technologies and
thus among the biggest challenges [1], [35], [43], [44], [47],
[57] for the IoT. Therefore, it is compelling for the IoT
architectures to consider and resolve these challenges upfront.
Otherwise, applications as well as whole ecosystems building
on top of such architectures may repeat the security fallacies of
the past decades. For that, a precise understanding of security
requirements in the context of the IoT is indispensable.
Prior technology trends, e.g., cloud computing and big
data, are likely to share security requirements with the IoT.
However, the uniqueness of the IoT introduces new challenges
to security requirements, different from previous technology
trends. Big data solutions for instance are designed to scale
and deal with heterogeneity of data sources. Nevertheless, big
data solutions are not required to deal with an uncontrolled
environment and constrained resources; big data analytics run
in isolated silos with time or resources to spare. Likewise,
cloud computing by design is supposed to scale and over-
come challenges of constrained resources. However, cloud
computing hardly deals with mobility of devices and physical
accessibility of sensors.
Related IoT security surveys are incomplete with respect
to requirements. For instance, [11] provides a sound review
of network security and identity management, but does not
consider privacy, trust, and resilience; [53] emphasizes privacy
and trust, but hardly tackles network security, identity manage-
ment, and resilience. The requirement listing in [4] is the most
extensive to the best of our knowledge. The analysis however
only considers identity management.
To provide a comprehensive overview, we summarize se-
curity requirements from the domain of the IoT, but also
related areas of IT and elaborate these requirements in the
context of the properties of the IoT. For that, we split the
requirements into five groups: Network Security, Identity Man-
agement, Privacy, Trust, and Resilience. The five main security
requirements along with their subcomponents are shown in
Fig. 1. Furthermore, Table I depicts the relationship between
the various IoT properties and the security requirements. In a
glance, it is shown that with regard to network security the
constrained resources have the strongest connection, mainly
due to the restrictions that they apply to traditional security
mechanisms, e.g., cryptography. Moreover, identity manage-
ment is influenced by the heterogeneity of the IoT. Privacy
is mostly connected with scalability and the constrained re-
sources as restrictions are posed to the technology candidates
that can be utilized. Furthermore, the uncontrolled environment
and the heterogeneity of the IoT have a serious impact on trust.
Lastly, resilience is directly connected to the need of the IoT
for scalability.
1) Network Security: Network security requirements [46]
can be split into confidentiality, authenticity, integrity, and
availability. These apply to IoT architectures, e.g., by means
of things connecting to things or services. However, properties
of the IoT, e.g., constrained resources, must be considered.
The IoT requires architectures to deal with the hetero-
geneity of things. Interconnecting things may require confi-
dentiality, e.g., to prevent eavesdropping sensitive information
via Internet transmission. Technologies such as IPSec[31] and
Transport Layer Security (TLS)[16] exist to fulfill this require-
ment. However, overhead may exceed the resource constraints
of things and thus dedicated secure network stacks for the
IoT exist [8]. Authenticity provides proof that a connection
is established with an authenticated entity (cf. the following
section). Integrity ensures no data is lost or modified unde-
tected. While authenticity includes integrity, integrity alone
can be required in the absence of authenticity to detect and
recover failures. Existing mechanisms, e.g., TCP and TLS
may suffice. However, IoT scenarios may require transactional
integrity, e.g., critical infrastructures, and thus this should be
considered by the architectures as well. Availability ensures
that the connectivity of a thing or service persists even under
link failures. Therefore, IoT architectures should ensure that
link handover is possible.
2) Identity Management: Identity management poses a
specific challenge in the IoT due to the number of devices, but
also due to the complex relationship between devices, services,
owners and users [36], [50]. Hence, specific attention has to
be payed to authentication, authorization including revocation,
and accountability or non-repudiation.
The mere quantity of devices in the IoT scenarios exceed
the capabilities of direct authentication, e.g., a user provision-
ing many devices with her service credentials. Hence, methods
to claim ownership and take control over devices are required.
Within the IoT scenarios, interactions may stretch across
multiple domains. Scenarios for existing authorization so-
lutions, e.g., Kerberos [48], assume a single domain that
encloses devices, owners, users, and services. Thus, solutions
for federated authorization that work with untrusted devices,
allow delegation of access across domains, and provide quick
revocation, e.g., for broken or rogue devices, are required.
Accountability ensures that every action is clearly bound to
an authenticated entity. Accountability is a particular challenge
in the IoT due to the magnitude of reuse of devices, services,
and also data for many purposes. Thus, accountability must
deal with huge amounts of entities, delegation of access,
actions that span organizational domains, as well as continuous
derivation of data.
3) Privacy: Privacy is considered to be one of the most
dominant challenges in the IoT [36] due to the involvement
of citizens and increasingly ubiquitous data collection, e.g., in
smart home scenarios. A plethora of privacy definitions exist
depending on the view of an IT solution. We briefly elaborate
on data privacy, anonymity, pseudonymity, and unlinkability.
Data privacy complements confidential data transmission in
the sense that a stored data record must not expose undesired
properties, such as the identity of a person. This requirement
is an enormous challenge in the IoT, as so many sensing
devices collect personal information. Large amount of such
data becomes Personally Identifiable Information (PII) when
combined together; the data identifies a person [15]. Models
to “anonymize” such data records exist [34], [51], [55], but
have constantly proven to be insufficient. Moreover, models to
protect this data privacy under data exchange between domains
[18] are rather uncharted and complicated to apply.
Anonymity describes the property of a single person not
being identifiable as the source of data or an action [41].
Anonymity is desirable in the IoT whenever a persons’ identity
is not required to comply to data minimization laws (Directive
95/46/EG [19]), as well as to dispel preconceptions that arise
with data collection in the IoT. Achieving anonymity is a tough
challenge as wearable and mobile devices may leak PII such
as IP addresses and location unknowingly. Technologies such
as anonymous credentials [9] and onion routing [17] exist, but
may not scale well with the IoT.
Pseudonymity trades off anonymity with accountability.
With pseudonymity, actions of a person are linked with
a pseudonym, a random identifier, rather than an identity.
Pseudonyms can serve many purposes [41], e.g., linking mul-
tiple actions of the same persons or providing graceful degra-
dation of anonymity in the case of abuse. While pseudonyms
may resolve privacy and accountability concerns in the IoT,
standardized solutions that accompany multiple domains are
required.
Unlinkability qualifies pseudonymity in the sense that
specific actions of the same person must not be linked
together. Unlinkability protects from profiling in the IoT.
While pseudonyms may solve unlinkability, i.e., a differ-
ent pseudonyms is used for every action, cross-implications
with anonymity, in particular unknown meta-data, remain a
challenge. Furthermore, some entity can always link every
pseudonym to a person, and can thus also link all actions of
that person.
4) Trust: Trust is another crucial requirement in the IoT
due to the fact that it is highly distributed as well as dependable
on qualitative data. Trust can be decomposed into device trust,
entity trust, and data trust [15].
Device trust in the IoT is a challenge, as a priori trust
in devices cannot always be established, e.g., due to high
dynamics and cross domain relations. Hence, approaches such
as trusted computing [26] (for standardized devices) as well as
computational trust [29] are required to establish device trust.
Moreover, every entity may assess trust in a device differently,
hence IoT architectures have to deal with non-singular views
of trust.
Entity trust in the IoT refers to expected behavior of
participants such as persons or services. While device trust
can be established via trusted computing, mapping such ap-
proaches to device trust, e.g., via behavioral attestation, is more
challenging and experimental.
Data trust occurs in the IoT in a twofold manner: first, data
originates from many and potentially untrusted devices. Hence,
trusted data must be derived from untrusted sources, e.g., by
applying data aggregation and machine learning techniques.
Network Security Identity Management Privacy Trust Resilience
Uncontrolled Environment • • • • • • •
Heterogeneity • •• • •• •
Scalability • • •• • • • •
Constrained Resources •• • •• • •
TABLE I: IoT properties and security requirements: the “•” symbols represent the level of influence in a scale from one (low)
to three (high).
Second, IoT services derivate new data, e.g., by integrating
different types of data. For that newly generated data, a new
trust assessment is required, e.g., via computational trust.
5) Resilience: The merge of scale of the IoT in terms of
devices creates a large surface for attacks and failures. For this
reason, resilience and robustness against attacks and failures
apply, as important requirements, to the IoT.
Architectures must provide means to proficiently select
things, transmission paths, and services according to their
robustness (failure/attack avoidance). Furthermore, to ensure
resilience, fail-over and recovery mechanisms must be pro-
vided to maintain operations under failure or attacks, and to
return to normal operations (failure/attack mitigation).
III. IOT ARCHITECTURES
The primary concept of the IoT is the pervasive presence of
a variety of things, e.g., RFID tags, sensors, actuators, mobile
phones, that are able to exchange and process information
through Internet [33]. This triggers a need of controlling
and monitoring of the data. An IoT architecture fulfills this
responsibility by creating a bridge between the things, and the
virtual entities (the Internet and associated services) [6], so
that the data flow is consistent.
The following sections provide an overview of the existing
research projects: Internet of Things Architecture (IoT-A) [27],
Building the environment for the Things as a Service (BeTaaS)
[6], Open source cloud solution for the Internet of Things
(OpenIoT) [40] and Internet of Things at Work (IoT@Work)
[28].
We selected these architectures as they were constructed
during EU FP7 research projects and they are supported by
a large number of academic research institutes as well as
industrial partners. Thus, we expect these architectures to play
a dominant role in future research as well as upcoming IoT
solutions. Furthermore, the open nature of the aforementioned
architectures suggests that they will be highly reused (either as
a whole or partially). In fact, this has already been observed
with the case of IoT-A. Therefore, a security analysis of them
is essential. In addition, the selected IoT architectures provide
a holistic surface coverage that includes generic environments
(e.g., IoT-A), and corporate/industrial areas (e.g., IoT@Work).
All the architectures have been surveyed qualitatively, by
comprehensively analyzing all the specification documents as
well as any related research papers, and by mapping them to
our requirements. Unfortunately, due to the fact that most of
these proposals lack of available implementations, an extensive
quantitative evaluation is not possible. OpenIoT is the only one
of the surveyed architectures that provides an implementation.
Thus, in this case we also investigated the level of consistency
between the specification documents and the provided code.
A. IoT-A
IoT-A[27] is an architecture reference model developed
with an EU FP7 project until 2013, with ongoing community
development. This architecture uses the concepts of views and
perspectives to guide the generation of architecture instances,
from business goals via requirements. Such views and per-
spectives include the information view for static structures
as well as dynamic information flows, the performance and
scalability perspective, and the trust and security perspective
[5]. The requirements are derived from a multitude of coarse-
grained requirements (so called unified requirements) [14]
based upon business goals, and then converted into fine-
grained requirements for an architecture instance. The unified
requirements are currently 38, addressing the security and pri-
vacy perspectives. In addition, IoT-A contains several models
that are independent of particular architectures. These models
include for instance the communication model and the trust,
security and privacy model.
To address security requirements, IoT-A contains five log-
ical security components [45]. Network security is addressed
via the Key Exchange and Management (KEM) component.
KEM manages cryptographic keys that are used for confiden-
tiality as well as integrity in combination with authenticity. To
handle resource constrained devices, KEM uses IP Security
(IPSec) tunnels between (unconstrained) gateways as a well
integrated concept to maximize the coverage of network se-
curity. However, the connections between constrained devices
and the gateway remain unprotected. Furthermore, KEM does
not address availability in the context of network connections.
KEM also addresses functional requirements, such as lawful
interception.
IoT-A contains three modules that address the requirements
of identity management. The module Identity Management
(IM) places focus on mere management, but does not cover
a particular security requirement. The module Authentication
(AuthN) covers the authentication requirements for users and
services, as well as accountability with non-repudiation. The
module Authorization (AuthZ) covers the authorization re-
quirements for services via role-based access control (RBAC)
as well as attribute-based access control (ABAC) [45]. Revo-
cation depends on the particular access control model used.
The authors are not aware of particular revocation schemes in
IoT-A to the best of their knowledge.
A dedicated module called Pseudonymisation (PN) ad-
dresses privacy by means of providing pseudonymization
for devices, users, and services. Pseudonyms replace real
identities, which are obtained from KEM, but still maintain
coupling of identities and pseudonyms to ensure accountability.
Pseudonyms can furthermore provide unlinkability, given a
new pseudonym for every action is used. Complete anonymity
as well as data privacy however are not addressed by PN.
Still, AuthZ provides some means of access granularity that
may solve data privacy to a certain extend.
The module Trust & Reputation (TRA) tackles the trust
requirement for entity and device trust. In particular, the
module describes the collection of the user reputation to
calculate service trust. However, data trust does not appear
to be addressed.
IoT-A describes the fault handling model, or functional
group respectively. Requirements and measures of this model
include predicting potential failures, detecting existing failures,
reduction of effects of failures and repairing the system. Thus,
the first measure addresses avoidance whereas the latter three
address a life-cycle for mitigation.
B. BeTaaS
BeTaaS proposes an architecture for the IoT and Machine-
to-machine (M2M) communication, to enable running appli-
cations over a local cloud of gateways. Each BeTaaS in-
stance builds its own cloud of gateways that integrates various
heterogeneous M2M systems in a seamless way. BeTaaS is
founded on the Things as a Service (TaaS) reference model
[7]. Modifying and augmenting the reference models of IoT-A
(Sec. III-A), it provides architectural models for domains,
information, communication, security, and functions.
The architecture comprises of four layers. First, the Phys-
ical Layer contains the M2M systems connected to the plat-
form. Second, the Adaptation Layer handles the connection
to the physical layer, abstracting from peculiarities of the
individual M2M systems. The third layer, namely the TaaS
Layer, relies on the abstraction layer and provides network-
wide access to the devices in the M2M layer. Finally, the
Service layer manages the functionalities and services of
BeTaaS applications. At a glance, the BeTaaS architecture is
addressing the security requirements by providing individual
mechanisms for all of its layers except the physical one (which
is implicit to the M2M/IoT systems).
With regard to Network Security the Key Management
component associates entities, performs authentication, man-
ages user sessions, and provides encrypted communication.
Since BeTaaS instances consist of multiple gateways, BeTaaS
uses a PKI with a Certificate Authority (CA) to manage
keys and ensure confidentiality, authenticity and integrity via
secure communication channels. BeTaaS also covers cases
with multiple involved organizations, e.g., external entities that
are not governed by the internal CA. Such cross-organization
key management is handled by the BeTaaS directory service.
Furthermore, BeTaaS addresses resourced constrained devices
by applying computationally efficient cryptographic schemes
such as Elliptic Curve Cryptography (ECC) [30].
For Identity Management, BeTaaS provides authentication
via a dedicated architectural component. For that, it distin-
guishes two cases: gateway level authentication, e.g., when a
gateway joins a BeTaaS instance, and application or service
level authentication, e.g., when a user utilizes an application.
For the first case, the authentication module uses key man-
agement, whereas for the latter case OAuth can be adapted
for authentication and authorization. Authorization is covered
by a dedicated component as well [13]. The accountability
requirement remains unclear.
While Privacy is stated as a key aspect of the security
mechanisms in BeTaaS [6], there is no evidence of how this
requirement is fulfilled. The identity management component
is responsible for managing the identities of sensors and gate-
ways, but data anonymity or pseudonymity are not discussed.
Trust is handled by the trust and reputation component.
The model retrieves input from individual trust aspects: se-
curity mechanisms (which for instance include information
regarding the encryption algorithms, the certificates, etc.), QoS
fulfillment, dependability performance, battery load and stabil-
ity in provided data. These trust aspects are then aggregated
to compute the final trust value.
Lastly, the aspect of resilience is handled via four different
pillars: fault prevention, removal, tolerance and forecasting.
The Failure Analysis Approach [13] component is responsible
for the identification of potential causes of failures and for
providing solutions to properly manage them. A process named
Failure Modes Effects and Critically Analysis is performed on
the functional items of the system. First, the fault modes for
each IoT device are identified and corresponding effort on the
analysis and operations is computed. Moreover, after assessing
the probability of failure occurrence, it assigns the criticality of
the failure. At this point, the Reliability Architectural Approach
component proposes solutions for overcoming the possible
system failure, with respect to the aforementioned analysis.
C. OpenIoT
The EU FP7 OpenIoT research project (2012-2014), has
introduced an IoT architecture [39], [40]. OpenIoT is based
on IoT-A’s (cf. Section III-A) defined Architectural Refer-
ence Model (ARM). It adopts the main ARM concepts and
functional building blocks. However, OpenIoT concentrates on
providing a cloud-based middleware infrastructure, to deliver
an on-request access to the IoT or the IoT services, which
could be formulated over multiple infrastructure providers like
cloud-based ones [40]. OpenIoT also offers an open source
implementation
1
that focuses on structuring principles for the
IoT applications with cloud-based characteristics such as on-
demand or pay-as-you-go service delivery. At a glance, the
architecture deals with IoT/cloud convergence.
The OpenIoT architecture specification [25] describes two
security modules: the security & privacy module as well as
the trustworthiness (trust) module. Within the the security
module, one submodule addresses secure messaging, another
one authentication and authorization. Opposed to the specifi-
cation, privacy features are not present in the public code. The
trustworthiness module evaluates the trustworthiness of input
sensor data (data trust).
OpenIoT relies on the HTTP with TLS protocol to en-
sure secure and encrypted messaging. Resource constrained
devices, e.g., IEEE 802.15.4 (ZigBee), are partially addressed
1
https://github.com/OpenIotOrg/openiot
