UNIT 3

Internet of Things
Privacy, Security and Governance
Introduction
One specific challenge in IoT is to
Ensure that the information collected and stored by
micro/nano-RFID and micro/nano sensors should be
visible only to authorized users (e.g., the owner or user of
the object) otherwise there could be a breach of security
or privacy.
Information collected by the body sensors applied to an
elderly person should not be accessible by other persons
apart from the doctor.
Access control mechanisms for these wireless devices
should be implemented and deployed in the market,
security and privacy solutions are not easy to
implement in micro-nano devices because of the
limitations in computing power and storage.
It should not hamper business development of micro-
nano technologies.
Keys management and deployment can also be
complex to implement.
Trade-offs should be identified and described. These
are goals for research activity.
Augmented Reality 2030 - YouTube
 New devices like Google Glass or future Intelligent Transportation Systems (ITS)
applications in cars will propose “augmented reality” where the integration of
digital and real-word information is used to compose sophisticated applications.
 This trend highlights even more the need for security and privacy, because data
breaches in the virtual-world can have consequences in the real-world.
 In some contexts and applications, security and privacy threats can even become
safety threats with more dramatic consequences for the lives of the citizen. As a
conceptual example, actuators in the real-world may be set remotely within a “smart
house” to provoke fires or flooding.
Topics-Internet of Things Privacy, Security and
Governance
-Introduction,
Overview of Activity Chain — Governance, Privacy
and Security Issues,
Contribution From FP7 Project,
Security and Privacy Challenge in Data Aggregation
for the IoT in Smart Cities-Security,
Privacy and Trust in Iot-Data-Platforms for Smart
Cities,
First Steps Towards a Secure Platform, Smartie
Approach
Privacy
Internet of Things privacy is
the special considerations
required

to protect the information of

individuals from exposure in
the IoT environment
Definition
Privacy itself is multi-dimensional. Popular
definitions focus upon individual freedoms, or the
“right to be left alone”.
In reality privacy encompasses the interests of
individuals, informal groups and including all forms of
organizations and is therefore a complex
multidimensional subject.
Security
IoT security is the
technology segment
focused on safeguarding
connected devices and
networks in the internet of
things .
Allowing devices to
connect to the internet
opens them up to a
number of serious
vulnerabilities if they are
not properly protected.
Governance

The governance of IoT

systems is strongly related to
the data those systems
produce.
Enterprises and organisations
are increasingly using IoT
devices to drive operational
success by tapping into more
data — but IoT governance
is falling behind.
 • The European Research Cluster on the Internet
of Things has created a number of activity
chains to favor close cooperation between the
projects addressing IoT topics and to form an
arena for exchange of ideas and open dialog on
important research challenges.
• IERC Activity Chain 05 is a cross-project
IERC activity focused on making a valued
contribution to IoT privacy, security and

Activity governance among the EC funded research

projects.
• Privacy, security and competition have been

Chain identified as the main issues related to IOT

Governance,

05
• The main objective of the Activity Chain 05 is
to identify research challenges and topics, which
could make IoT more secure for users (i.e.
citizen, business and government), to guarantee
the privacy of users and support the confident,
successful and trusted development of the IoT
market.
 •FP7 iCore Access Framework

Contribu
tion
•The iCore cognitive framework is based on the principle
that any real world object and any digital object that is
available, accessible, observable or controllable can have
From a virtual representation in the “Internet of Things”, which
is called Virtual Object (VO).

FP7
Composite virtual objects (CVOs) use the services of
virtual objects.
A CVO is a cognitive mash-up of semantically
Projects interoperable VOs that renders services in accordance with
the user/stakeholder perspectives and the application
requirements.
iCore framework
The first cognitive management layer (VO level cognitive framework)
is responsible for managing theVOs throughout their lifecycle,
ensuring reliability of the link to the real world object/entity (e.g.,
sensors, actuators, devices, etc.).
The second cognitive management layer (CVOlevel cognitive
framework) is responsible for composing the VOs in Composite
VO.
The third level (User level cognitive framework) is responsible for
interaction with User/stakeholders. The cognitive management
frameworks will record the users needs and requirements (e.g.,
human intentions) by collecting and analyzing the user profiles,
stakeholders contracts (e.g., Service Level Agreements) and will
create/activate relevantVO/CVOs on behalf of the users.
IoT@Work Capability Based Access
Control System
The CapBAC is devised according to the capability based
authorization model in which a capability is a communicable,
unforgeable token of authority.
This token uniquely identifies the granted right(s), the object on
which the right(s) can be exercised and the subject that can
exercise it/them.
https://www.sciencedirect.com/science/arti
cle/pii/S089571771300054X
 ACL
vs
Capab
ility-
based
author
izatio
n
model
s
ACLs become very complex to manage when the
number of subjects and resources increases.
The Attribute Based Access Control (ABAC) approach, well
exemplified by the tries to solve the problem of roles
explosion giving the possibility to directly use subject’s
properties (e.g.: age, location, position in an organization,
etc.), as well as resources and environmental properties, to
specify access policies, therefore potentially reducing the
number of rules, or rules changes, at the expense of more
powerful (and complex) rules and more processing and data
availability requirements. 
An example of ABAC would be allowing only users
who are type=employees and have department=HR to
access the HR/Payroll system and only during business
hours within the same timezone as the company.
ABAC is not only the most flexible and powerful of the
four access control models, but is also the most
complex.
Additional features
Essential innovation over previous capability based techniques:
Delegation support: a subject can grant access rights to another
subject, as well as grant the right to further delegate all or part of the
granted rights. The delegation depth can be controlled at each stage;
Capability revocation: capabilities can be revoked by properly
authorized subjects, therefore solving one of the issues of capability
based approaches in distributed environments;
Information granularity: a capability can even specify dynamic
adaptation of the granted rights (e.g. specify a “level of details” for a
read access right on a specific piece of information). In this way the
service provider can refine its behavior and the data it has to provide
according to what is stated in the capability token.
Housekeeping example.
Bob has to go on holidays and his house
needs some housekeeping while he is away.
Dave, Bob’s neighbor, offered to takes care of
Bob’s house housekeeping for his holiday’s
period.
Typically each of us, and Bob in this
example, will hand over a copy of our house’s
keys to our neighbor Dave (as exemplified by
action in the figure).
Our neighbor Dave will then use our keys for
doing the agreed housekeeping activities
(action in the figure).
But how can we, or Bob in our example,
be sure Dave does not use the keys for non-
envisaged or non-authorized activities?
How can we avoid that Dave makes a
duplicate of the keys?
To this end, Fig. 4 revise the use case depicted in Fig. 3 using a capability based access
control mechanism. In this example Bob provides to Dave an access token (a capability
token) that:
• identifies Dave has the only subject entitled to use the token,
• states what Dave can actually perform (e.g. monitoring and configuring Bob’s garden
watering system),
• states for how many days Dave can do these actions (i.e. token validity period).
• Bob and Dave do not need to establish trust relationships among their authentication
and authorizations systems (that actually remain independent). Bob’s house appliance
recognizes the access token created by Bob and Dave has only to prove that he is the
subject (grantee) identified by the capability token as (temporary) entitled to do a
specific housekeeping activity. Therefore:
• Dave cannot use Bob’s token for non-envisaged or non-authorized activities,
• Dave cannot pass the token to someone else, nor can use it outside the validity period,
• subjects other than Dave cannot use the capability token unless that are able to prove
they are Dave (e.g. if an attacker has stolen Dave’s identity).
Capability-based authorization architectural
components and their interactions.
The CapBAC architectural elements
Can be shortly characterized as follows
• The resource object of the capability (Service A in Figure 4.4); it
can be a specific data or device, a service or any accessible element
that can be univocally identified and/or actable on (like resource);
• The authorization capability that details the granted rights (and
which ones can be delegated and, in case, their delegation depths),
the resource on which those rights can be exercised, the grantee’s
identity, as well as additional information (e.g. capability validity
period, XACML conditions, etc.). An authorization capability is
valid as specified within the capability itself or until it is explicitly
revoked;
The capability revocation is used to revoke one or more
capabilities. Like a capability, a capability revocation is a
communicable object a subject, having specific rights (e.g. the
revoker must be an ancestor in the delegation path of the
revoked capability), creates to inform the service in charge of
managing the resource that specific capabilities have to be
considered no more valid;
• The service/operation request is the service request as
visualized by the provided service with the only additional
characteristics to refer or include, For example, for a RESTful
service, an HTTP GET request on one of the exposed REST
resource has to simply include the capability and its proof of
ownership to use our access control mechanism;
The PDP (Policy Decision Point) is a resource-agnostic service in
charge of managing resource access request validation and
decision.
In the CapBAC environment it deals with the validation of the
access rights granted in the capability against local policies and
checking the revocation status of the capabilities in the
delegation chain;
• The resource manager is the service that manages
service/access requests for/to the identified resource. The
resource manager checks the acceptability of the capability token
shipped with the service request as well as the validity and
congruence of the requested service/operation against the
presented capability. It acts as an XACML Policy Enforcement
Point (PEP) which consider the validation result of the PDP;
• The revocation service is in charge of managing capability
revocations.
GAMBAS Adaptive Middleware
(GAMBAS Contribution)
GAMBAS Adaptive Middleware (GAMBAS Contribution)

The GAMBAS project develops an innovative and adaptive

middleware to enable the privacy-preserving and automated
utilization of behaviour-driven services that adapt autonomously
to the context of users.
In contrast to today’s mobile information access, which is primarily
realized by on-demand searches via mobile browsers or via mobile
apps, the middleware envisioned by GAMBAS will enable proactive
access to the right information at the right point in time.
As a result, the context-aware automation enabled by the GAMBAS
middleware will create a seamless and less distractive experience
for its users while reducing the complexity of application
development.
GAMBAS- elements
GAMBAS are centred on a secure distributed architecture in which data acquisition,
data storage and data processing are tightly controlled by the user. Thereby, security
and privacy is based on the following elements.
• Personal acquisition and local storage:
 The primary means of data acquisition in GAMBAS are personal Internet-connected
objects that are owned by a particular user such as a user’s mobile phone, tablet,
laptop, etc.
 The data acquired through the built-in sensors of these devices is stored locally
such that the user remains in full control.
 Thereby, it is noteworthy that the middleware provides mechanisms to disable
particular subsets of sensors in order to prevent the accumulation of data that a user
may not want to collect and store at all.
 • Anonymised data discovery:
 In order to enable the sharing of data among the devices of a single user or
a group of users, the data storages on the local device can be connected to
form a distributed data processing system.
 To enable this, the GAMBAS middleware introduces a data discovery
system that makes use of pseudonyms to avoid revealing the user’s identity.
 The pseudonyms can be synchronized in automated fashion with a user
defined group of legitimate persons such that it is possible to dynamically
change them.
 • Policy-based access control:
 To limit the access to the user’s data, the networked data storages perform
access control based on a policy that can be defined by a user.
 In order to reduce the configuration effort, the GAMBAS middleware
encompasses a policy generator tool that can be used to derive the initial
settings based on the user’s sharing behaviour that he exhibits when using
social services.
 Secure distributed query processing:
 On top of the resulting set of connected and access-controlled local data storages,
the GAMBAS middleware enables distributed query processing in a secure manner.
 Towards this end, the query processing engine makes use of authentication
mechanisms and encryption protocols that are bootstrapped by means of novel key
exchange mechanisms that leverage the existing web-infrastructure that is already
used by the users.
 • In the IoT-A project, security and privacy
issues in various aspects has been
addressed.
• A set of requirements based on the input of
external and internal stakeholders was
used as a basis for the identification of the
IoT-A mechanisms and functionalities that
guarantee user data privacy and integrity,
Architecture user authentication, and trustworthiness of
the system.
(IoT-A • These functionalities were analysed and
Contribution orchestrated in Functional Groups (FG)
and Functional Components (FC) in the
) frame of WP1.
• High-level PS&T specifications were
integrated in the frame of the IoT-A
Architectural Reference Model (ARM) and
then passed to vertical WPs dealing with
communication protocols (WP3),
infrastructure services (WP4) as well as
hardware aspects (WP5).
Hexa-X – Objectives
Governance, Security and Privacy in the Butler Project
BUTLER project overview (slideshare.net)

The main requirements relate to:

• Standard issues of data security, both at data storage level as
at data communication level exists in IoT application.
 • The application enabled by the Internet of Things may pose
additional privacy issues in the use that is made of the data. From the
collection of data by the applications (which should be conditioned
by an “informed consent” agreement from the user), to the profiling,
exchange and sharing of these data necessary to enable true “context
awareness”.
Data technical protection3 mechanisms include two major aspects. One is the
protection of the data at data storage, the other one the protection of the data at
communication level. The protection of data at communication level is one the major
area of research. Many communication protocols implement high level of end-to-end
security including authentication, integrity and confidentiality.
At communication level, the major issue is the deployment process of the security keys
and the cost of the required hardware and software environment to run the security
algorithms in efficient and secure way. However, Privacy and Security do not only
refer to security of the exchange of data over the network, but shall also include:
(a) Protection of the accuracy of the data exchanged,
(b) (b) Protection of the server information,
(c) (c) Protection of the usage of the data by explicit, dynamic authorization
mechanisms,
(d) (d) Selected disclosure of Data and
(e) (e) The implementation of “Transparency of data usage” policies.
 The BUTLER project also addresses the Security and Privacy challenges from the
point of view of their implication on business models. To specify the horizontal IoT
platform envisioned in BUTLER, the project started from the gathering and analysis
of the requirements from up to 70 use cases. The
 analysis of these use case not only produced requirements for the specification of
the platform but also valuable information on the potential socio-economic impact
of the deployment of an horizontal IoT and on the impact on the associated business
models.
 If treated accordingly, the ethics and privacy issues transforms from a threat to an
opportunity. Better understanding of the service by the user increase acceptance and
create trust in the service. This trust becomes a competitive advantage for the
service provider that can become a corner stone of his business model. In turn the
economic interest of the service providers for ethics and privacy issues, derived
from this competitive advantage, becomes a guarantee for the user that his privacy
will be respected. The BUTLER project research on the implication of the Ethics,
Privacy and Data security on the business models and socio economic impact will
be published in Deliverable 1.4 (May 2013) and Deliverable 1.3 (September 2014).
The involvement of end users in proof of concepts and field trials is another specificity of
the BUTLER project.
The end user involvement is key to validate not only the technical qualities of the
BUTLER platform (technology feasibility, integration and scaling) but also to assess the
perception of end user and their acceptance of the scenario envisioned for the future
“horizontal” IoT.
The following issues must be considered in the organization of end user involvement:
(a) Technical security mechanisms must be set up to ensure the security and privacy of
the participants. This involves secured data communication and storage, and in the
scope of the BUTLER project is addressed by the enabling security technologies
developed and integrated in the BUTLER platform;
(b) The participants must be well informed of the scope and goal of the experiment. In
the case of BUTLER, this involves specific efforts to explain the scope and goal of the
project to a larger public;
(c) The consent of the participants must be gathered based on the information
communicated to them. The consent acknowledgment form must remind the
participants of their possibility to refuse or withdraw without any negative impact for
them;
(d) finally both a feedback collection and a specific complaint process have been designed
to offer the possibility to the participants to raise any issue identified.
  The vision of SMARTIE is to create a
Security and distributed framework for IoT based
Privacy applications sharing large volumes of
heterogeneous information.
Challenge in  New challenges identified for privacy, trust
Data and reliability are:
Aggregation • Providing trust and quality-of-information in
shared information models to enable re-use
for the IoT in across many applications.
Smart Cities • Providing secure exchange of data between
IoT devices and consumers of their
information.
• Providing protection mechanisms for
vulnerable devices.
 One of the main aims of Smart City technologies
is to provide different optimization mechanisms
for different aspects of data management.
Data is gathered from various sources owned by
Security, different administrative domains.
Privacy and Data from public and private transportation
providers, data from mobile users, captured for
Trust in Iot- instance with their smart phones, surveillance
data and videos from private and public
Data- organizations and a vast amount of sensors and
meters, attached to machines and infrastructures,
Platforms distributed throughout the city.
All this information is stored in a variety of
for Smart different places, for instance it can remain
locally in the sensors or company internal
Cities databases, in social networks, in data storage
located in private data centres or even in a public
cloud storage service.
Architectural components of
Smart City
Information needs to cross multiple administrative boundaries
Actuation decisions can be taken in a coordinated way between
multiple control centres or data providers.
data flows from various sources and from different
administrative boundaries - need to be treated in a secure
and privacy preserving way.
To ensure this, security and privacy need to be part of the
platform by design and may not be added later on.
The design goal and challenge is allowing user/service
control of the data accessible and at the same time providing
solution for easily configured management of the process.
 All parties involved in the overall systems such as sensors and actuators, end users,
data owners also service providers need strong mechanisms for reliability and trust.
 Users and residents of the system will require fine grained access and data privacy
policies they want to enforce.
 For instance, a user might be willing to share location information with family and friends
and make the information available in aggregated form for improvement of the public
transport. But the same user might not want the information to be used by other 3rd-party
service providers.
 New applications and synergies are possible if the data is shared between multiple
domains.
However, several challenges need to be overcome to make this
possible. Creating a platform for sharing IoT-type of data is per
se a huge challenge.
Risks to a Smart City IoT Platform
Attacks on the control infrastructure, poisoning of data and
leakage of confidential data.
SMARTIE will focus on challenges that concern privacy, security
and trust of the information available in the smart city.
An attacker can simultaneously attack on multiple layers:
• Manipulate the sensor measurements to infiltrate the system with
wrong data, e.g. to cause certain actuations
• Attack the sensors and actuators physically to obtain credentials
• Attack or impersonate network components to act as a man-in-the
middle
• Obtain sensitive data or cause actuation by attacking the sharing
platform with forged or malicious requests
 Standard network security tools such as firewalls, monitoring or typically
access control will not suffice to prevent such sophisticated attacks due to
the distributed nature of the IoT and the problem of defining/finding trusted
parties.
 It is essential that security is built into the infrastructure rather than being
added as an extra plug-ins.
 An effective protection approach is to have security in depth, where data
and services are protected by several independent systems.
 The challenge will be to design solutions where no single server has
significant power to control the infrastructure or to access significant
amounts of data.
First Steps Towards a Secure Platform
1. Trust and Quality-of-Information in an Open
Heterogeneous Network
In SMARTIE and in other IoT systems, systems belonging to
different owners need to cooperate.
System Of Systems (SoS).
It is an entity composed of independent systems that are
combined together in order to interact and provide a given
service, which cannot be provided by the individual systems
when not cooperating.
The major properties of SoS especially for application fields
as those intended in the SMARTIE project are
 Dependability, security and privacy.
Dependability comprises the following attributes
Availability— readiness for correct service
 Reliability— continuity of correct service
Safety—absence of catastrophic consequences on the system
user and its environment
 Integrity — lack of inappropriate system alternations
 Maintainability—ability to undergo updates and repairs
Building blocks for realizing and managing
SoS
The five characteristics that give possible representation of
fundamental are:
Autonomy — the ability to make independent choices — the
SoS has a higher purpose than any of its constituent systems,
independently or additively.
Belonging—happiness found in a secure relationship—
systems may need to undergo some changes to be part of SoS.
Connectivity—the ability of system to link with other systems
—systems are heterogeneous and unlikely to conform to a
priori connectivity protocols and the SoS relies on effective
connectivity in dynamic operations.
Diversity — distinct elements in a group — SoS can achieve
its purposes by leveraging the diversity of its constituent
systems.
Emergence—new properties appear in the course of
development or evolution — SoS has dynamic boundaries,
which are always clearly defined, SoS should be capable of
developing an emergence culture with enhanced agility and
adaptability.
Since we are mainly concerned with heterogeneous
groups of devices/services we will call such a SoS a
Federation of Systems (FoS).
The need of cooperation in a Federation of Systems
requires that the individual systems within FoS have to
be trustworthy, and that there is a minimal level of
trust between the involved systems.
The transitive trust can be used to extend trusted
relationship within the group.
 Establish a trust value with other interacting entities

FAIR (fuzzy-based aggregation providing in-network

resilience) is an example how trust can be established and
maintained at least between a base station and sensor node
in the field.
FAIR well suitable for medium size or large sensor networks.
In a smart city scenario, smaller sets of sensors are more
likely and we present a variant for trusted Quality of
Information (QoI) computation that is particularly well-
suited for small unattended networks.
Two-step aggregate-and-confirm approach.
There are three roles pseudo-randomly distributed among the
nodes at the beginning of each epoch:
the Aggregator Node, the Normal Nodes and the
StorageNodes.
The protocol consists of two message rounds, where each
message is authenticated and broadcasted:
 1. Periodically, the aggregator node triggers the network to start
an aggregation process; each node senses the environment and
sends back its measurement.
 (2) The aggregator node collects all the values, removes the
outliers and computes the aggregate, which consists of the
result and a measure of precision.
This precision expresses the dispersion of the “genuine” data
set.
Based on this tuple, each node checks that the result is correct
by comparing it with its own measurement and outputs a
confirmation digest, encrypted with a pairwise key shared with
the base station.
Those confirmations are collected and stored by the storage
nodes, which keep them for the base station.
2. Privacy-preserving Sharing of IoT Data
Privacy is one of the most sensitive subjects in any discussion of
IoT protection. As the amount of data generated by IoT will be
huge.
Single pieces of information, i.e., single measurements, in most
cases do not represent a significant threat for the owners of IoT
devices (temperature at a location, even heart rate of a person at a
given moment).
However, given that the devices are generating data continuously,
it is obvious that unauthorized access to such wealth of data can
cause significant problems and can be used to harm the owners of
the data (and possibly others, depending on the context of the
data).
Therefore, it is of paramount importance to protect access to IoT
data.
On the other hand, the power of IoT lies in the ability to share
data, combine different inputs, process it and create additional
value.
 Hence, it is equally important to enable access to data generated
by other IoT devices, while preventing the use of data in un-
authorized or undesired ways.
The existing initiatives such as FI-WARE address the privacy issue
within the Optional Security Service Enabler. The issue of privacy
is concerned with authorization and authentication mechanisms.
 This includes a policy language to define which attributes (roles,
identity, etc.) and credentials are requested to grant access to
resources.
It includes a (data handling) policy language that defines how the
requested data (attributes and credentials) is handled and to
whom it is passed on.
Finally, it includes the means to release and verify such attributes
and credentials. It is also important to consider the mechanisms
enabling the protection of information based on encryption
algorithms within the secure storage.
The fundamental privacy mechanisms lie in the intelligent data
management so that only the required data is collected.
 Detecting the redundancy, data is anonymised at the earliest
possible stage and then deleted at the earliest convenience.
Furthermore, the processing of collected data will have to be
minimised according to a strict set of rules so that it cannot be re-
used.
The proposed approach will define such methodology together
with the mechanisms for the secure storage based on efficient
cryptographic algorithms suited for the resource constrained
environments.
3. Minimal Disclosure

Three features of privacy-friendly credentials are informally

described in NSTIC documents:
(1) Issuance of a credential cannot be linked to a use, or “show,”
of the credential even if the issuer and the relying party
share information, except as permitted by the attributes
certified by the issuer and shown to the relying party.
(2) Two shows of the same credential to the same or different
relying parties cannot be linked together, even if the relying
parties share information.
(3) The user agent can disclose partial information about the
attributes asserted by a credential. For example, it can prove
that the user if over 21 years of age based on a birthdate
attribute, without disclosing the birthdate itself.
4. Secure Authentication and Access Control in
Constrained Devices
Embedded systems and especially wireless sensor nodes can be
easily attacked. This is due to the fact that they are normally
unprotected by cryptographic means.
This is due to the fact that both types of devices suffer from severe
resource constraints e.g. energy resources and processing power so
that standard cryptographic approaches cannot be applied.
Thus there is a necessity of development of the lightweight
cryptographic solutions, which take the above mentioned
constraints into consideration and are able to ensure the needed
level of the security.
There are several lightweight security approaches designed for
wireless sensor networks.
For eg: The SPINS protocols encompass authenticated and
confidential communication, and authenticated broadcast.
Asymmetric cryptographic schemes to exchange secret session keys
between nodes and symmetric crypto approaches for data
encryption.
LiSP: a lightweight security protocol, which supports all security
attributes, but at a high level of power consumption.
The lightweight security approach presented in is based on the RC4
stream cipher. It provides data confidentiality, data authentication,
data integrity, and data freshness with low overhead and simple
operation.
A lightweight security approach based on modification of elliptic
curves cryptography. The reduction of the length of the security
parameters influences the security level but also helps to save the
energy needed for computation and communication.
The RSA with limited lifetime is still too expensive for WSNs due to
the large size of the messages (>512bit). Such a size of the message
requires in most of the WSN platforms packet fragmentation what
makes the communication expensive and complicated.
When dealing with access control for IoT, the first considered
approach consists in the potential applicability of existing key
management mechanisms widely used in Internet that allows
performing mutual authentication between two entities and the
establishment of keying material used to create a secure
communication channel.
Due to the computational and power restrictions that must be
satisfied in IoT networks, existing mechanisms are not applicable
for controlling the access to services offered by IoT networks.
For example, while public key cryptography solutions demand
high computational capabilities, schemes based on pre-shared
keys are not applicable since they would require the pre-
establishment of symmetric keys between an IoT device with
every Internet host.
For this reason, in the literature we can find different works
proposing alternative solutions to cope with the access control
problem in IoT networks.
For example, one of the earliest works in this area is developed by
Benenson et al. [33] where a cooperative access control solution is
defined.
In this work, user authentication is performed by collaboration of
a certain group of IoT nodes. Despite this scheme is carefully
oriented to minimize the computation overhead in IoT devices, it
increases communication overhead.
Different access control solutions have been proposed for IoT
networks. Depending on the employed scheme, we can
distinguish between public key cryptography (PKC) and shared
key cryptography (SKC) based solutions.
PKC schemes are based on Elliptic Curve Cryptography (ECC) in
order to reduce the computational requirements on IoT nodes.
The different schemes vary on the approach used to implement
the ECC based authentication.
For example, while some solutions require a Key Distribution
Centre to be available all the time, others develop a certificate
based local authentication.
However, these proposals suffer from requiring high times to
conduct user authentication (in some cases times are greater than
10 seconds).
SKC schemes propose the user authentication based on symmetric
key cryptography algorithms, which are more efficient than public
key schemes.
The use of these solutions requires both users and IoT nodes to
share a secret key that will be used to carry out mutual
authentication before granting the user access to the service
offered by the IoT nodes.
Compared to PKC, SKC schemes require lower computation and
capabilities. Nevertheless, these schemes present serious
scalability problems since they require the pre-establishment and
pre-distribution of keying material.
 Smartie Approach
SMARTIE will design and build a data-centring
information sharing platform in which information will
be accessed through an information service layer
operating above heterogeneous network devices and
data sources and provide services to diverse applications
in a transparent manner.
It is crucial for the approach that all the layers involve
appropriate mechanisms to protect the data already at
the perception layer as well as at the layers on top of it.
 These mechanisms shall cooperate in order to provide a
cross-layer holistic approach.
 Adaptation and Deployment
1. Smart Transportation
Smart City Objectives
Improving the management of the public transportation networks to
foster greater use of sustainable transport modes and to provide time and
cost benefits to travellers.
Involving user smartphones in order to include additional information
related to their travels.
Improving the management of individual motor car traffic, to reduce
travelling time in the town, improve traffic flow and reduce fine dust
pollution.
Extending traffic control systems with mobile traffic control systems to
react fast on abnormal situations, planned ones (e.g. Road reconstruction)
and also unplanned ones (e.g. accidents).
Exploiting heterogeneous wireless sensor networks placed on public
transport vehicles and in the environment (streets etc.) e.g. Stationary
traffic sensors/actuators placed at cruces of the transportation network.
Usage:
Public transportation companies monitor the current demand of
travellers for public transportation for certain routes and optimise
the number of vehicles to match the demand. They also monitor
location of all public vehicles.
Travel plan component located on the cloud infrastructure
calculates the best routing option for the traveller taking into
account the traveller location, expected arrival times and current
traffic conditions.
This information is then forwarded to the associated smartphone
application and presented to the traveller.
City traffic authorities monitor the current traffic conditions:
◦ To optimise the traffic lights in order to achieve better traffic flow.
◦ To adapt speed limitation signs.
◦ To indicate detours in case of road re-construction, accidents or
other emergency situations.
The required adaptation of the individual car traffic is then
indicated via adapted traffic light switching, updated electronic
traffic sign, etc.
Security and Privacy Challenges:

Information related to location of public vehicles should be

accessible to system users according to the access policy and
privacy rules.
All data exchange between the sensor, actuators and backend
server should be implemented in a secure manner.
All the data related to the travellers’ location and activity should
be considered private, and it should be treated according to the
privacy rules.
Integration systems owned by different parties such as public
authorities and private companies providing telematics services.
2. Smart campus
Smart City Objectives:
Monitoring energy efficient in the campus considering energy
consumption and energy generation.
Evaluating real-time behaviour of systems jointly acting as a
sustainable ecosystem.
Providing the user capability to interact with the system to
facilitate the improvement of the energy efficiency.
Usage:
Energy Supervisor entity will be able to collect from the different
sources: information in real time about building consumption and
energy generation from the different entities involved
(photovoltaic generators).
Energy Monitoring entity will collect data from the sensors being
deployed and also data aggregated and summarized about the
different energy producers to take decisions over different actuators
involved in the system.
Energy Producer will provide data aggregated to the Entity Monitoring
based on the agreement established and will provide more detail data
to the Energy Supervisor as main regulator.
User will provide in certain situations their positions and presence
information to the Energy Monitoring entity by means of the sensor
within the building or light-street pathways.
Security and Privacy Challenges:
Access to the data of the sensor should be controlled based on access
control and privacy rules. Hence only certain services of the entity
monitoring could read or act over them especially in the case the
monitoring entity is a third party.
The exchange will require mechanisms including data protection and
integrity in the transfer between the different parties.
Scalable and secure management protocol which lets the
verification and authentication of new sensors deployed and
ensure the extension of the trust domain to new devices in the
deployment environment.
Entities are actually restricted to use the data based on the
national protection data law. They will like to explore how to reuse
the data and possible being able to share to third parties but also
controlling what can be shared based on legislation.
Data exchange between entities needs to follow data minimization
principles and allow traceability.
User data information exchange could be in some case anonymous
and in other case could be needed some control over the
distribution of data.