TRUST MANAGEMENT SYSTEM DESIGN FOR THE INTERNET OF THINGS: A CONTEXT-AWARE AND MULTI-SERVICE APPROACH

Yosra Ben Saied, Alexis Olivereau, Djamal Zeghlache, Maryline Laurent

Presented by Ali Asgar Sohanghpurwala

Machine to Machine (M2M) and Internet of Things (IoT) architectures becoming prevalent

Wireless Sensor Networks (WSNs) introduced unattended wireless topologies with resource constrained nodes

IoT expands on WSN requirements Wider architectures More heterogeneous Inconstant resource capabilities Increased autonomy

INTRODUCTION

Nodes expected to securely communicate with external Internet nodes, but likely don't have resources to do it alone Constraints such as computing power, battery life, limited bandwidth Need to collaborate to meet this goal Cooperative techniques for routing and security have been proposed

in literature Collaboration needs to be controlled, to protect against attacks Cryptographic methods don't account for insider attacks

Cryptographically trusted nodes can lie, alter data, or selfishly refuse to collaborate

Existing WSN and MANET insufficient for IoT

WHY DOES IOT NEED A TMS?

IoT nodes providing different services assessed by same TMS

Non-malicious nodes may temporarily have low capabilities

IoT nodes are highly heterogeneous Node owned by multiple self-interest

communities Complex malicious patterns arise with

coexistence of heterogeneous and self-concerned nodes

HOW IS TMS DIFFERENT FOR IOT?

ASSESSMENT OF PRIOR TMS WRT IOT

Use past behavior to determine task-specific trust levels for each node

Eventually only the best partners for a specific service are proposed to requesting node

Fine-tune trust levels, even in presence of malicious and erroneous nodes

Geographically centralized TM servers

Multi-phase approach

OVERVIEW

Initially all nodes are assumed trustworthy Bootstrapping period is required to gather information

before results are trustworthy Trust manager speeds up process by targeting nodes and

inducing artificial interactions Requesting node classifies behavior of assisting node

as positive or negative Evaluations are stored in trust manager Context under which evaluations are received is

important Aging, resource capacity, etc. of evaluated node Execution time

INITIALIZATION AND INFORMATION GATHERING

Each report Rij

refers to jth report regarding QoS for assisting node Pi

Each report contains the following information:

REPORT INFORMATION

When a node asks for assistance, the trust manager returns a list of trustworthy assisting nodes

Five steps:1) Restrict set of proxies pi

2)Restrict the set of reports Rij for each proxy Pi

3)Compute weights (wRij) for each report Rij

4)Compute trust value Ti for each proxy pi

5)Provide requestor with list of best suited proxies

ENTITY SELECTION

Select candidates based on service requirements

Examples: Lightweight communication may require

nodes in same multi-cast group Signature delegation schemes may require

nodes dispersed in specific locations May require neighbors in radio range

ENTITY 1: RESTRICT SET OF PROXIES PI

Find most meaningful reports for prospective nodes

Ideal reports: Assisting node provided the same service Assisting node status was the same as it is now

It is likely that there won't be enough ideal reports to judge the node pi in specific context

We can calculate context similarity by quantifying node capabilities and service similarity

ENTITY 2: RESTRICT SET OF REPORTS

Quantifying node capability is easy: Percentage of Battery, CPU power,

Memory available Service similarity isn't as straightforward

Estimate service similarity based on resource requirements

Of measurable resources, energy consumption is recommended by authors

ENTITY 2:QUANTIFY PARAMETERS

Report Rij sent by all nodes j, regarding interactions with node Pi contains: Sj – service provided

by Cj – capability

Nj – Note

Try to match with target values: Starget – Current

service in request Ctarget – Current Pi

capability

ENTITY 2: CONTEXT SIMILARITY

ENTITY 2: CONTEXTUAL DISTANCE

dSmax, dCmax - tolerance of selection mechanism for capability and service measurements

First term represents distance from center of ((Starget,Ctarget), dSmax, dCmax) ellipse

Node that behaves well for expensive service, is likely to behave well for less demanding service Second term represents distance between Rij and (Smax, 0)

Node performing well for low-demand service, doesn't mean it performs well in demanding service Second term represents distance between Rij and (0, Cmax)

Positive report close to (Smax, 0) means node performed well for expensive service while near min capacity

Negative Report close to (0, Cmax) means that node performed poorly for simple service, while at max capacity

Any report close to center of target ellipse is very similar

Retained report Rij should have dij such that:

dij (Rij, RTarget) < t, where:

ENTITY 2: DIJ ILLUSTRATION

ENTITY 2: EXAMPLE

ENTITY 2: EXAMPLE CONT.

Weight of each report (wij) determined by contextual distance (dij) and age (tnow - tj)

λ,θ are parameters in range [0,1] expressing 'memory' of the system θ (resp. λ) is adjusted according to expected rapidity of change Lower θ (resp. λ) indicates lower importance for past reports

(resp. more contextually distant reports)

s = ½ * (N2j-Nj), where Nj is the score given by witness

s = 1 when score is -1, and 0 when score is 0,1 weight of negative score is doubled compared to positive or

neutral scores

ENTITY 3: COMPUTE WEIGHT FOR EACH REPORT

Ti is trust value for proxy pi

QRj is the quality of recommendation of witness node j trustworthiness score based on accuracy of past

reports Ranges between -1 and 1

wRij is weight from previous slide

ENTITY 4: COMPUTE TRUST VALUE FOR EACH PROXY

Securely send list of best rated nodes to requestor

Finally done with Entity selection

ENTITY 5: PROVISION BEST RATED PROXIES OF PI

Client node relies on list of trusted proxies provided by Trust Manager to select partners

Sends positive or negative score for each partner to TM

Evaluation technique depends on service provided Could be direct observation, or could solicit

feedback from peers Received reports should take into account node

credibility

TRANSACTION AND EVALUATION

Learning phase qualifies system as a cognitive process

In security scenarios: Adaptive security systems

dynamically react by applying new security policies in reaction to environment change

Cognitive security introduces learning step. Assessment of enforced action eventually modifies system behavior so a different action may be taken next time.

LEARNING

1)Update witness nodes' qualities of recommendation

2)Update of assisting nodes' reputation levels

LEARNING STEPS

Simple Concept Decrease QR score if witness gave a 'bad' score

to a 'good' node Increase QR score if witness gave a 'good' score

to a 'good' node Use weighted average

avoids excessive variations of QR allows precise choice of extent to which QR must

be oriented towards 1 (good recommender), 0 (non-usable data), and -1 (bad recommender)

LEARNING 1: UPDATE QUALITY OF RECOMMENDATION

LEARNING 1: QR DIRECTION

Let X be a witness node who evaluated node P, which later provided a service to node F

Node F sends report RF with score N {-1,0,1} TM uses F's report to update QR score of each recommender System retrieves n stored QR scores for all witness nodes

X has for example QRx (QR1,...,QRn-1, Qrn)

System extracts note N from RF and retrieves wRx corresponding to RX

QRXF represents direction that QR for X should evolve

r = 1 if X and F agree on rating, r=-1 when they are opposite, and r=0 when they are off by 1

CF is weight of r, increases when weight of X's previous report is high, increases if F is a good recommender

LEARNING 1: WEIGHTED AVERAGE

QRi represents X's rec. history Ci is respective weight for X's rec. history θ represents 'memory' factor of system Negative N_QR means X is reporting opposite of

actual service quality Instead of discarding X's ratings, consider the opposite!

Reputation distinct from trust Trust measures ability of node

to perform specific task Reputation refers to overall

trustworthiness of node in the system

Combine QR (QRFj)and service ratings (NFj) with age-based weighting factor

TM recalculates reputation after each interaction

Nodes with low-reputation are added to blacklist

LEARNING 2: UPDATE ASSISTING NODES' REPUTATION LEVELS

TEST SIMULATION

SIMULATION PARAMETERS

QR EVOLUTION

QR EVOLUTION CONT.

ATTACK RESILIENCE

ATTACK RESILIENCE CONT.

Presented generic, context-aware TMS for IoT Dynamic trust scores assigned to nodes based

on node status, and required function Independent score given for Quality of

Recommendation QR score is adjusted through learning phase System withstands several classes of attacks

CONCLUSION