UNIT V

Trust Management

5.1 The need for evaluating trust in IoT

• With the growing demands of the people, IoT systems also have
designed and developed to cater the societal needs.
• “Trust” is very important for the IoT systems and in it’s design
and development.
• if the humans do not trust an IoT system and its components, they
will not be willing to use it. The same stands for the service
providers, the municipalities, the companies, and all kinds of IoT
stakeholders. If they are not convinced that the IoT systems are
reliable, they will not be willing to invest in them.
Significance of Trust in IoT:
• Trust is closely interconnected with reliability and reputation. In
Information and Communication Technologies (ICT) the concept
of trust has been considered crucial for any digital interaction
between multiple entities.
• The concept of Trust can be defined as the level of confidence
that an entity has on another entity to behave certainly in a given
situation.
• Not only with humans, it is also associated with machines,
devices and software
Trust vs Trust worthiness:
• Trust can be considered as subjective, because it is a belief of an
entity (user, device, etc.) that another entity is functioning
according to some predefined criteria, and these criteria are
subjective to the former entity. On the contrary, Trustworthiness,
which is an abstract concept, is considered as objective, because
 it is described as a metric of how much an entity deserves the trust
of other entities.
• IoT systems have to be trustworthy so that they are adopted by all
stakeholders.
• This metric is built upon several criteria, i.e. evidence of current
and past behaviour, availability, data reliability, security, etc.
Trustworthiness can also be calculated as “absolute” or as
“relative” to other entities
Reputation
• Reputation is considered as an estimator of the trustworthiness of
an entity according to the criteria of another entity. Since the
trustworthiness of an entity is very difficult to be evaluated, the
metric that is widely used instead is the reputation. In order to
calculate the reputation of an entity, the metrics of multiple other
entities are fused and compared according to certain criteria
Trust can be considered in which contexts?
• (i) from users to devices that send them information,
• (ii) from devices to users that send actuating commands, and
• (iii) between devices that exchange information and actuating
commands
Example for trust and trustworthiness
• A temperature sensor sends commands to the air-conditioning
system to turn on the heating because the temperature in the room
is very low, the air-conditioning should be sure that the
temperature sensor is trustworthy in order to execute the
command.
• only trusted users have to be allowed to manage critical data or
actuators
• The concept of trust is quite important in controlling the objects
like doors, windows or even fire-extinguishers, malicious
 (untrusted) users may create incidents against the safety of other
users.
• Since in the IoT devices are also able to control other devices,
these incidents can also occur not only by user actions (i.e.
hacking devices), but also by faulty or malfunctioning devices.
• Another example is traffic management. The trust in traffic
systems should be in providing a best route to the client when
traffic is high.
• If this sytem fails in trust, then no one will use it and the Iot
system design and development is mere a failure.
5.2 Trust management in IoT
• The main objective of a Trust management system in IoT is
• to be able to evaluate the trustworthiness of various components
of the system and
• to use these values in order to provide reputation information to
users of the IoT services or to internal configuration services.
Design metrics of an IoT Trusted Model:
• Any IoT trust model should be designed according to the
following:
• Observation: This step is the most important step since it is responsible
for monitoring the parameters of the system entities and
their behaviour, allowing the extraction of results with
regards to the trustworthiness of the entities. The
monitoring of these parameters can be performed by the
system devices or by specific entities that are called
observers. The collected information can originate from
standalone observers or from groups of observers, which
then fuse the information for extracting more objective
results
• Scoring: When the observers gather the information for an entity they
can give it a proper weight which will result in a reputation
score. This will be done for all entities in the system
(considering that adequate information has been gathered).
This reputation score can be given by an interested agent or
a centralized entity or by many entities collectively. Finally,
the reputation scores can be used in order to rank the entities
in terms of trustworthiness according to some criteria.
• Selection: Once the reputation scores and ranks are in place, the
next step is to select the entity which is more appropriate for a
specific transaction, i.e. that provides a specific IoT service. Of
course this service might be provided by more than one entity,
thus the user has to select the most appropriate according to some
criteria.
• Transaction: When a service has been selected, the transaction
takes place and more information regarding the entity (that
provides the service) is being gathered by the system components,
as a feedback
• Rewarding and punishing entities: Trust management systems
should also include functionalities for rewarding the entities that
are performing according to the criteria and have high reputation.
At the same time, the system must punish malicious or
untrustworthy entities that may negatively affect system decisions
or the systems’ overall reliability and trustworthiness
Sub Models of an IoT Trust Model
• A trust model for the IoT can be split in two main sub-models: (i)
a trust evaluation model and (ii) a reaction model.
• The Trust evaluation model is responsible for gathering trust
metrics and trust ratings for the system entities and evaluating
them for extracting their reputation, while the reaction model is
responsible for reacting to these reputation evaluations, either by
rewarding or by punishing the entities.
 • The trust evaluation model has to be lightweight, keeping a small
state that is updated regularly, so that it can also run on
constrained devices.
• The main idea is that there is a set of observers that are providing
trust ratings for a specific entity in mind
• These trust ratings are trust values that relate to the confidence
that this observer has on this entity according to some criteria.
• Trust ratings can also be provided by the administrator of the
system or by other users that have had past interactions with this
entity.
• These trust ratings are then fused into a centralized component
(i.e. reputation manager) that extracts the reputation of this entity.
• Then, when a user, a service or another entity wants to interact
with the entity under evaluation, it queries this centralised
component to get the reputation and decide according to its own
rules if it can trust this entity or not
Reacting Model
• logging alerts, warning administrators, disabling or re-enabling
services, stopping/starting gathering data from devices, initiating
networking or system configuration mechanisms, warning users,
etc
5.3 Trust for Devices
• The trust model for IoT devices aims to improve the reliability
and trustworthiness in IoT scenarios where disparate and
unknown devices interact each other and provide data to IoT
applications.
• The device-based trust model follows a multidimensional or
multi-layered approach to calculate the overall trustworthiness of
an IoT device. The model describes the procedure employed to
quantify several trust dimensions (or trust metrics).
 • Contrary to past approaches that considered only reputation
between different devices and data reliability, lately other
parameters such as communication reliability, security aspects
and social relationships between the devices are being
considered.
• In the end, this approach leads to a more accurate and reliable
value of trustworthiness about a given IoT device, which can be
exploited either for improving the reliability of the provided
services or for increasing the overall security of the IoT system.
• The trust model follows a hierarchical and a layered approach in
which the different dimensions are split in categories and
subcategories, which in turn are composed by measurable
properties. This hierarchical approach enables the trust model to
be extensible, allowing users to consider and include new
properties to the model.
• The trust dimensions can be measured in different layers within
an IoT network.
• Some of them can be measured on the devices themselves and
• The values will be exchanged between the devices and fused in
order to extract the reputation of each of their neighbour devices
• In IoT the evaluation of the trustworthiness of a device can be
generally based on multiple criteria that can be grouped into 5
categories: (i) communication criteria, (ii) security criteria, (iii)
data-based criteria, (iv) social relationship criteria, and (v)
reputation criteria.
5.3.1 Communication based trust:
• The communication based criteria correspond to the quality of the
communication links between the devices.
• Communication link quality is not directly related with the
trustworthiness of the devices but also on performance of the
device’s transmissions.
• This will in turn affect the Quality of Service provided by this
device (in terms of throughput, delay, jitter, etc.) and its
availability
• The communication based trust criteria are mainly used for
evaluating the networking related trustworthiness of the devices
which is then used to consider the trusted devices within network-
related cooperative mechanisms such as cooperative routing,
spectrum or channel allocation, network monitoring, etc.
• The chosen metric is the Expected Transmission Count (ETX)
metric which has been proved in the literature that is quite
accurate in evaluating the reliability of the link between any two
nodes.
• The ETX expresses the average number of transmissions that are
required for a successful delivery of a packet to its destination
when there are transmission failures due to degradation of link
quality (e.g. interference, collisions, etc.).
• The ETX is very widely used for routing mechanisms because
• good reliability
• quite simple
• computationally efficient,
• easily calculated even in the very constrained IoT devices

• where fi,j is the metric for the forward delivery ratio, namely the
probability that a packet sent from node i is received by node j,
and ri,j is the reverse delivery ratio, namely the probability that
 the acknowledgement packet from node j will be received by
node i.
5.3.2: Security-based Trust:
• The security trust criteria are mainly related with the behaviour
of a device as this is anticipated by its neighbours.
• By evaluating and fusing these metrics, the security-based trust
of the devices can be calculated, which will show how susceptible
this device is in these types of attacks, affecting it overall
trustworthiness and the way the rest of the neighbours behave
towards this device
• These metrics can be calculated mainly at the device level or at
the cluster head/gateway level, when the devices are incapable (in
terms of resources) to do these calculations. In order to calculate
these metrics at the device level, the devices have to be able to go
into promiscuous mode
Below are the few trust metrics:
• Data/control packets forwarded
• Packet address modified
• Routing protocol execution
• Battery/lifetime
• Sensing communication
• Availability
• All devices within an IoT network are assumed to be monitoring
the behaviour of their neighbours when they are interacting with
them.
• For these two metrics, the following statistics can be used: (i)
Packet Drop Rate (PDR), as the ratio of the number of dropped
packets divided by the total number of received packets and (ii)
Packet Modification Rate (PMR), as the ratio of the number of
 modified packets divided by the total number of forwarded
packets.
5.3.3 Data-Reliability based Trust or “service-based metric” :
• One of the most important trust metrics for IoT devices is related
to the reliability of the data they produce.
• By using the term “data” one refer to the measurements the IoT
devices are producing from their onboard sensors, i.e.
environmental, location, energy, etc. These measurements are
being used by the services of the system and if they are unreliable
they may severely degrade the trustworthiness of the overall
system
• Consider for example a weather station producing wrong values
for the temperature and the rain level in the centre of the city and
the citizens are falsely informed and are not properly dressed.
Another example may be regarding the alerts for fire or hazardous
gases. It is evident thus that the data reliability is very important
because it can even affect the safety of the users/citizens.
• Its evaluation is done by comparing the measurements with
known measurement patterns, past measurements or
measurements of other devices at the same area, monitoring the
same physical object and the same property of the object
• This means that one should only compare temperature
measurements from different sensors monitoring the same room
and not different rooms or measurements of temperature with
humidity.
• IoT devices may have various sensors of different types onboard
and may be providing multiple services
• A low trust rating for one service does not mean that other
services provided by different sensors will also be unreliable.
 • However, combining the trust ratings for services provided by a
specific sensor can provide results about the malfunctioning of
that sensor or its driver being hacked
5.3.4: Social Relationship based Trust:
• In IoT, social parameters can also be used for evaluating the trust
rating of IoT devices. These social parameters are based on the
emerging Social IoT (SioT) paradigm, which assumes that
devices can establish social relationships with each other In such
a case, devices are assumed to be grouped into trust bubbles or
communities based on their social relationships, i.e. if they belong
to the same owner, if their owners are friends, are working
together, if they are located at the same area, if they have the same
manufacturer, etc.
• An IoT trust model has to consider the social relationship between
a device ‘i’ when assessing the trust of a device ‘j’. Different
weights can be given to the relationship between the devices
considering the links among them
• Where Bp is the Personal Bubble, Bf is the Family Bubble, Bo is
the Owner Bubble and C is the Community Bubble

5.3.5: Reputation based Trust

• An IoT trust model should consider recommendations from
multiple devices about a particular device j. Let be the
Opinion score about device j .
• It is also reasonable to assume that the opinions of different
devices may have different impact on the opinion score of other
devices, that’s why there can be weights for each one of the
“recommender” devices.
 • Thus, the opinions are subject to a credibility process where each
reputation evidence coming from a device i is subject to
credibility factor Cri in the interval [0..1], where 1 represents the
highest credibility. Therefore, the Reputation property in our trust
model is given by Ri j = Oi j ∗ Cri.

5.4 Trust for IoT Services

• The IoT Services provide streams of information towards the end
users.
• IoT services can be either simple services provided by a single
device or composed services that combine data from many
devices.
By using services the client should answer the following questions
• Q1: if he can rely on a specific service
• Q2: if the service provides reliable measurements.
• The reputation of a service is directly related with the reliability
of the data of this service.
• As a result, for evaluatingthe reputation of a service, the trust
rating of its data stream has to be evaluated. Thus, an observer
has to be allocated to monitor this data stream.
• The observer should basically extract statistics for the data
stream, in order to be able to identify changes in the pattern of the
data stream, i.e. to identify when there are jumps or values that
are outside the “normal” limits of the data stream
• For the statistics of the data stream, the first calculation that has
to be done is the average value, that can be calculated as an overall
average or as a moving average on a sliding window.
• Here the challenge is to be able to calculate the average without
using too much storage, so that even constrained devices will be
able to calculate it.
 • Then, the observer has to calculate also the limits and the
thresholds of the data stream (in terms of minimum and maximum
value) so that an alert will be fired if a value outside these
thresholds is measured
Temperature measurement example
• While measuring the temperature in a room, the minimum and
maximum observed readings are 5 degrees and 35 degrees
respectively.
• If the temperature monitoring service provides values of around
50 degrees, an alert has to be fired for a possible fire in the
apartment or for a possible tampering with the service’s data (i.e.
a hacked device or a n intermediate entity altering the
measurements). In the latter case, the reputation of the service has
to be lowered
• Apart from the values outside the thresholds, sudden jumps in the
data stream might cause change in the reputation of the service.
• For example, in the previous scenario of a temperature
monitoring service, if the current temperature of the room is
around 10 degrees and suddenly the service starts providing
values around 25 degrees this might fire an alarm despite the fact
that the values are within the thresholds.
• Such a sudden jump has to be evaluated because it might mean
that the service might be providing false values and its reputation
has to be decreased.
• For this reason, the alarm might to be a warning to the
administrator of the system to check what is happening in that
room. Another type of an alert, may cause the cross-evaluation of
the values of the temperature service with the values of other
services, i.e. of a smoke detector service to see if there is indeed
a fire in that room, etc
Cross evaluation of the statistics is important
 • It can be easily understood from the latter scenario that in order
to evaluate the reputation of a service, the calculation of the
statistics of its data stream might not be enough. Thus, there needs
to be a mechanism to allow the crossevaluation of the statistics of
different data streams.
• For the usage of the statistics of the data streams, the definition
of the thresholds and the identification of the jumps, specific rules
have to be defined either by the administrator of the system or by
the users that want to receive a service.
5.5 Consent and trust in personal data sharing
• The volume of data is doubling every two years, of which two
thirds is generated by individuals, in particular with adoption of
new wearable devices.
• This growth has been driven by the increasing of both the number
of connected devices in our lives as well as their capabilities. This
trend looks set to continue with data traffic from IoT devices
rising from 2% share of the total in 2013 to 17% in 2020.
• This derives from the creation of new services such as those
providing holistic approach to healthcare, where prevention and
caring of long-term conditions can be made more effective by
combining information beyond those included only in medical
records, but including also any related life style information (such
as shopping and dietary habits, fitness/exercise information etc)
Freemium Model
• In the current IoT service model, personal data are mostly
collected by a multiplicity of Service Providers, each one offering
a dedicated service, most of the time provided through a
freemium model
• This currently undermines individuals’ trust in sharing IoT
personal data, thus hindering its associated value. A recent Digital
Catapult report on Personal Data and Trust [32] highlighted that
60% of consumers are uncomfortable about sharing their data,
 with a further 14% feeling so uncomfortable that they do not want
to share their data at all.
People’s reluctance in data sharing in:
• For commercial purposes
• Research purposes
• Third party involving purposes
• There is a need to regain individuals’ trust by increasing
transparency on how data are collected, managed and shared.
• Control is the key and to support this change in the current trend,
the new General Data Protection Regulation (aka GDPR),
recently approved and in force by early 2018, is putting the end-
user (aka the individual) at the center of this process, while
promising expensive sanctions for those businesses big and small
failing to comply to its principles (e.g., up to 100 Mio or 4% of
their annual turnover fines for big corporates and up to 100K or
2% of annual turnover for SMEs).

Components of a Personal data Sharing Ecosystem

• Attribute Providers collect personal data through the provisioning
of a service as part of their day-to-day operations (e.g., banks,
utility suppliers, IoT service providers, etc.).
• To avoid to lock such data in silo’ed systems, and to allow further
access, reuse and combination of them for creation of new
services by a growing ecosystem of SMEs, data need to be
brokered according to well-defined rules (aka the Scheme),
enforced by certified Scheme Operators
• For ensuring compliance to GDRP, while increasing
individuals’trust, the envisioned Scheme should set, among
others, the following principles:
• Transparency
• Consent
• Erasure
Principles
• Transparency: Privacy Notices for data sharing should be easy
to access and to understand, explaining how data are processed,
what are the individuals’ rights and how they can be enforced;
• Consent: Valid consent must be explicit for data collected and
the purpose for the data collection should be stated. Data
controllers must be able to collect “consent” form end-users (opt-
in) and consent might be withdrawn;
• Erasure:Attribute Providers (e.g., the data controllers) are the
entry point for the erasure requests and need to inform third
parties (e.g., the Relying Parties).
• If control means trust for individuals to exercise this control,
hence the consent to sharing cross-domain personal data, there is
the need for tools and open standards.
• Consent Receipt represents one of such tools. The Consent
Receipt inherently, by being a record of consent given at the point
 of consent (e.g., when first accessing a service), provides proof of
consent and delivers contact information to communicate about
consent directly to the end userceipt represents one of such tools.
Consent Receipt Structure

• Header: The purpose of which is to set out administrative fields

for the consent transaction, including a unique Consent ID;
• PI (Personal Information) Controller Information: This section
identifies the individual and company that is accountable for data
protection and the privacy policy (included in the receipt or linked
to otherwise) to which the consent is bound;
• Purpose Specification: It specifies the purpose(s) for which
Controller is collecting additional Personally Identifiable
Information
• Personally Identifiable Information: This section specifies the
personal information categories and related attribute collect by
the PI Controller;
• Information Sharing: When applicable and stated in the Privacy
Policy, the purpose of this section is to provide the individual with
 information about how their information is shared with third
parties;
• Scope: This section specifies the technical and policy scope
within which the collected data are used.
Open Consent Framework

• First of all, certified authorities perform a Service Assessment of

Relying Parties that develop services using personal data, in order
to provide a data protection impact assessment and to collect the
information required to pre-fill the Consent Receipt fields,
specifying what data and how they are collected, used and shared
according to stated privacy policies. The result of such
assessment is used to pre-configure a Consent Receipt Generator,
the access to which is provided to the given Relying Party as
Service (Consent Receipt As A Service, CRaaS). Unique Consent
Receipt IDs, useful for auditing purposes, are created by the
Scheme Operator and assigned to each generated receipt. Along
with the Consent Receipt ID, the remaining Consent Receipt
fields are filled at run time.
• First of all, certified authorities perform a Service Assessment of
Relying Parties that develop services using personal data, in order
to provide a data protection impact assessment and to collect the
 information required to pre-fill the Consent Receipt fields,
specifying what data and how they are collected, used and shared
according to stated privacy policies. The result of such
assessment is used to pre-configure a Consent Receipt Generator,
the access to which is provided to the given Relying Party as
Service (Consent Receipt As A Service, CRaaS). Unique Consent
Receipt IDs, useful for auditing purposes, are created by the
Scheme Operator and assigned to each generated receipt. Along
with the Consent Receipt ID, the remaining Consent Receipt
fields are filled at run time.
• On the other end, a set of end-users facing tools allow, among
others, individuals to manage consent, collect and group receipts,
as well as visualize and track shared personal data, through a User
Consent Dashboard.

5.6 Using trust in authorization

• The IoTAccess control system can implement a Trust Model in

order to enable secure and reliable interactions between granted
and trustworthy entities. This mechanism can be deployed on IoT
scenarios where smart objects can maintain social relationships,
composing different kinds of groups of entities called “bubbles”
(e.g. Personal, Family, Office or Community).
 • Each bubble is made up of a set of smart objects, along with an
Authorization Manager, which is responsible for generating
authorization credentials for smart objects.
• Furthermore, each smart object have a Trust Manager, which is in
charge of assessing the trustworthiness of the other involved
entities
The main entities involved in the trust-based access control process are
the following:
• Smart object. It is a device (e.g. a smartphone, printer, camera, sensor,
etc.) that can act both as a CoAP client and a CoAP server offering
services (e.g. temperature, location, etc.) in an IoT environment.
• Trust Manager. It is the component implementing the proposed trust
model. In the case of a smart object with tight resource constraints (i.e.,
class 0 or class 1 device), the Trust Manager is deployed as separate
network element, such as a gateway. In the case of more powerful smart
objects (at least class 2 devices), the Trust Manager is a part of the
devices.
• Authorization Manager. It is responsible for generating and sending
authorization tokens to smart objects. Additionally, it is composed of
two subcomponents; the Policy Decision Point (PDP), which is in
charge of making authorization decisions based on a XACML engine,
and the Token Manager, which generates authorization credentials
according to the authorization decisions.
Intra bubble-Inter bubble communications
• In a trust-aware access control system, an intra-bubble
communication happens when a smart object attempts to access
another smart object that is part of the same bubble.
• inter-bubble communication between smart objects from
different bubbles. Under this scenario, the purpose of the Trust
Manager (TM) is twofold. On the one hand, it is used by the
requester smart object to know the most trustworthy target among
a set of devices providing the same service. On the other hand, it
is employed by the target smart object in order to get the trust
value associated with the requester under a specific transaction.
This value is used, along with the authorization credential that is
previously obtained from the Authorization Manager, in order to
make the access control decision.
• Firstly, the smart object A accesses its TM in order to know the
most trustworthy smart object providing a specific resource in
bubble B. The TM calculates the trust of the set of available
devices in bubble B (a prior discovery of devices is assumed).
Then, in step 2 device A obtains an authorization token for
accessing to devices in B. The decision is made based on XACML
policies evaluated by the policy engine. This stage is optional and
it is supposed to be done not so often, as tokens are reusable.
• Afterwards, in step 3, the subject smart objectAuses the
authorization credential (authz token) for access to a
service/resource being hosted on the target smart object B. The
target acts as PEP (Policy Enforcement Point) that enforces the
authorization rights defined in the token, taking into account as
 well actual context conditions. During this interaction the target
device also considers the trust value associated to the requester
device (i.e. smart object A). To this aim, it contacts its TM in
bubble B, which quantifies in real time the trust based on previous
evidences within A as well as actual conditions.
• Then, in step 6, device B verifies that the obtained trust value is
greater than a threshold value, which was specified as a condition
in the token. If that condition is fulfilled, the request is accepted
and the service is provided to the smart object A. Finally, in steps
7 and 8 (reward stage), the smart object A sends to its TM
evidences feedback about the reliability of the interaction, in
order to update the trust value associated to the smart object B,
which is useful for future interactions.
5.7 Using Trust in an Indoor Positioning Solution
Smart buildings are comprised of devices integrated into the Internet infras-
tructure with network and processing abilities, which make them vulnerable to
attacks and abuse. The associated services and resources can be accessed
through mobile devices anytime and anywhere by common users, which may
interact each other according to their levels of trust and reputation. In the smart
buildings context, location-aware mechanisms for trust evaluation, can allowa
user located at a certain room to share his data only with users located in his
same location. In this way, a specific level of trust can be automatically
established among people located in the same room, because all of them canbe
seen as belonging to the same ecosystem [44].
The effectiveness of location-aware security mechanisms is closely related to
the accuracy of the location information and the definition of security zones, that
is, the area where security aspects like access control, trust, reputation, etc. may
be established. However, in the context of smart buildings, how this location
information is obtained is a challenging task since traditional mechanisms such
as GPS are not useful. The indoor localization mechanismfor smart buildings is
able to provide accurate location data to be included insecurity aspects of smart
services. The proposed system is based on the use of sensors which are
integrated in common smartphones built-in magnetic sensors to make security
mechanisms totally independent on the type of devices and available signals in
buildings. The sensed magnetic field is a combination of the effects of the Earth’s
magnetic field and that of surrounding objects. A methodological approach is
used to generate the buildings maps containing the magnetic field distribution
used as map of fingerprints. Then,based on such maps, location estimations are
calculated using a combination of Radial Basis Functions Networks and
Particles Filters [45].
The Access Control system can rely on the Indoor location enabler to make authorization
decisions accordingly. In this way, devices can ask this servicein order to get
the distance where a requester user is placed when trying to access to their
services; consequently, certain services can be only provided when users are
placed inside the authorization zone of some smart objects. Figure 6.6 below
depicts the proposed scenario to perform location-aware access control in
indoor environments. The smartphone, acting as a subject,requests to get access
a resource being provided by the target smart device. Before allowing it to
access to his resource, the target device evaluates both the capability token as
well as the subject’s position, which must be located inside target’s security
zone. The context that determines the smart object Bposition comes from the
indoor localization enabler.
Firstly, the use case requires an offline stage where the smartphone of user A
contacts with the Authorization Manager in order to get an authorization
credential to get access to smart objects. Notice that this phase requires the
authentication process. Once the subject is successfully authenticated, the
Authorization Manager evaluates the policies and generates (if allowed) a token
with the set of privileges associated to the smart object. Then, the subject device
wants to make use of a resource hosted by target device, and it uses the obtained
token to present it against the target, which validates the token, see it the
quantified trust value is over a threshold, and checks subject’s positionagainst a
localization service, since only those devices located nearby are allowed to get
access.
5.8 Using Trust in Routing
A different scenario for the application of trust management in IoT systems is
related to improving the security, the privacy and the performance of a network
of IoT devices. Assume that there is an IoT deployment with a large number
of IoT devices that are forming a multi-hop sensor network.In such a network,
the information from the leaf devices or any device has topass through a number
of intermediate devices before it reaches the gateway that will forward the
measurements to the backbone middleware and the applications. If there are
intermediate devices that are either tampered with,malicious or faulty, this may
result to loss of information or to the provisionof faulty/tampered information.
Moreover, malicious devices may be able to get access to sensitive user
information that is passed through them.
To avoid such scenarios, the evaluation of the trustworthiness of the devices can
be used in the routing mechanism of the network, so that malicious or
malfunctioning devices will be quickly identified and sensitive informationto be
passed only through trustworthy devices. As described in [27], the reputation
evaluation of a network of IoT devices can be done very easily. Assuming that
the devices are able to monitor the transmissions of their neighbours, the trust
evaluation system can identify very quickly which devices are providing
erroneous information. The main idea is that before the start of the trust
evaluation all devices have a trust-rating of “unknown”,which is then changed
as the devices start to exchange data and observing the behaviour of their
neighbour devices. Generally, the rules that can be applied are that the trust-
belief for a device (i.e. how much we trust a device) shouldincrease slowly, in
order to be sure after many interactions that the device istrusted, but it should
decrease faster, so that malicious or suspicious devicesshould be avoided.
 When the reputations of the devices have been calculated, then these haveto
be included in the definition of the routing metric, to ensure that the nodeswill
be able to identify the routes to the gateway by avoiding suspiciousor
malicious devices. As shown in [46], including the device reputation in the
routing mechanism can significantly improve the performance of the IoT
network in terms of improved packet delivery ratio and throughput. This is
justified because by avoiding malicious nodes, the percentage of packet losses or
packet integrity fails will be minimized.