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