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

1. Yosra Ben Saied, Alexis Olivereau, DjamalZeghlache, MarylineLaurent Presented by Ali Asgar Sohanghpurwala Trust management system design for the Internet of Things: A context-aware and multi-service approach

2. Introduction • 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

3. Why does IoT need a TMS? • 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

4. How is TMS different for IoT? • 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

5. Assessment of prior TMS wrt IoT

6. Overview • 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

7. Initialization and Information Gathering • 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

8. Report information • Each report contains the following information: • Each report Rijrefers to jth report regarding QoS for assisting node Pi

9. Entity Selection • When a node asks for assistance, the trust manager returns a list of trustworthy assisting nodes • Five steps: • Restrict set of proxies pi • Restrict the set of reports Rij for each proxy Pi • Compute weights (wRij) for each report Rij • Compute trust value Ti for each proxy pi • Provide requestor with list of best suited proxies

10. Entity 1: Restrict set of proxies pi • 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

11. Entity 2: Restrict set of Reports • 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

12. Entity 2:Quantify Parameters • 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

13. Entity 2: Context Similarity • Report Rijsent 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

14. 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)

15. Entity 2: dij Illustration • 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:

16. Entity 2: Example

17. Entity 2: Example cont.

18. Entity 3: Compute weight for each report • 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

19. Entity 4: Compute Trust Value for each proxy • 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

20. Entity 5: Provision best rated proxies of pi • Securely send list of best rated nodes to requestor • Finally done with Entity selection

21. Transaction and Evaluation • 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

22. Learning • 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.

23. Learning Steps • Update witness nodes' qualities of recommendation • Update of assisting nodes' reputation levels

24. Learning 1: Update Quality of Recommendation • 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)

25. 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

26. 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!

27. Learning 2: Update assisting nodes' reputation levels • 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

28. Test Simulation

29. Simulation Parameters

30. QR Evolution

31. QR Evolution Cont.

32. Attack Resilience

33. Attack Resilience Cont.

34. Conclusion • 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