Ubicomp Research Lab (mscs.mu/~ubicomp)

1. Ubicomp Research Lab (www.mscs.mu.edu/~ubicomp) Department of Mathematics, Statistics and Computer Science Marquette University, Milwaukee, Wisconsin Service Sharing with Trust in Pervasive Environment: Now it’s Time to Break the Jinx Sheikh I. Ahamed, Munirul M. Haque and Nilothpal Talukder

2. Outline • Introduction and background • Motivation • Trust model • Evaluation • Conclusion • Future work

3. Introduction and background • The number of handheld users will reach 2.6 billion this year and 4 billion by 2010 • portable low-cost lightweight devices and emergent short range, and low power wireless communication networks • In USA, seniors over age 65 whose numbers are expected to hit 70 million by 2030, almost doubling from 35 million in 2000

4. Pervasive Computing • What it means • Pervasive computing is the computation that’s freely available everywhere • Goals of it • Integrate computing and communications with the surrounding physical environment • Make computing and communication transparent to the users

5. Pervasive Computing Environment • Ad hoc network in pervasive • environment with powerful device support (b)Ad hoc network in pervasive environment without powerful device support

6. Motivation for trust model • Depend on each other for resources • Poor battery power • Small memory storage • Poor computational capability • Susceptible and vulnerable to malicious snoopers • Inter-device dependency • Common shared medium • Transitory connectivity • Absence of a fixed trust infrastructure

7. Motivation for trust model : cont. • With which node(s) should I interact and with which I do not? • Trust models • Responsible for establishing and managing trust relationships • Decision-making role in resource sharing • Request from unknown device • Decision based on recommendation • Identify malicious recommendation

8. Features of a Trust Model • F1. Only valid nodes should be able to take part in any interaction • F2. Only authorized nodes should get a requested service • F3. A valid node may not be remained valid forever

9. Why Trust in Access Control Framework • Consider a scenario in which node A wants to share or to get access to node B’s resources. • The first thing B will do is to reason about the trustworthiness of A. • B will accomplish this by analyzing accumulated data from the previous interactions or requesting some recommendations from his trusted parties in the case that A has not had any interactions with B before. • There may also be a situation where there might not be enough information to trust, then B has to make his decision based on other variables [1].

10. Why Trust in Access Control Framework (cont.) • Because B cannot also allow access to his resources for an indefinite amount of time, his access policies will be dynamically updated on the information based on trust over time. • The service delivery agent running on B will consult the access control to decide on access. • If trust values are satisfactory A is immediately provided access. The interaction will also be used to modify the existing trust status of A.

11. Trust Framework • Two units • Direct Trust Unit • Formed through direct interaction experience • Behavior model • Evaluate the satisfaction level • Recommended Trust Unit • Recommended trust Protocol • Evaluate the recommendations

12. Recommended Trust • Active Recommendation • Active recommendation is possible only from neighboring nodes, • Passive • the node might consider all path that has hop length >=2. • Discrete • When a node can’t reach any path to consider it for recommendation, it needs some way to resolve the issue. That’s what we term discrete recommendation.

13. Hop Based Recommendation Protocol (HBRP) • a hop based recommendation protocol to determine trust values to consider a node eligible for access. • this protocol actually includes mechanisms for active and passive recommendations. • the maximum path length enables a node to avoid a long chain of recommendations. • This value is reduced in each hop by 1 and the path is ignored when the field becomes 0.

14. Risk in trust: handling malicious recommendation • Sometimes a node is in a scenario where the recommendation value contrasts the current recommendation value. It is a malicious recommendation. • There can be two such situations. • a) When a malicious node gives a high recommendation value for a node when the overall value is poor. • b) When a malicious node recommends a very low value contrasting high recommendations from others. • We have adopted a statistical method (t-Estimate) to address this issue of malicious recommendation. • Our assumption is that the number of benevolent nodes is much larger compared to the number of malicious nodes.

15. Evaluation • Implementation of the prototype • Operating system: WINCE • PDA: Axim X50vProcessor • Programming language: VC# .Net Compact Framework • Mobile ad-hoc mode: IEEE 802.11b • FTM

16. Screenshots of the Service sharing application based on trust based access control

17. Usability Survey

18. Conclusion • We presented a trust model to fit the dynamic access control framework intended for pervasive environment. • We used this information to optimize the accuracy of the recommendation process and the discarding of malicious devices from the network. • The prototype of the secured service sharing application presented in the evaluation section uses this hop-based recommendation protocol. • We have incorporated the risks involved in the different sharing scenarios

19. Future work • As a continuous addendum to the features, this access control module will be placed in the MARKS (Middleware Adaptability for resource Discovery, Knowledge Usability, and Self Healing) middleware. • Apart from security issues in service sharing, our future research lies with privacy issues that may arise due to context-awareness of applications in the pervasive environment

20. Questions • Send questions to • iq@mscs.mu.edu