Adaptive Trust Assessment in Distributed E-Records Replication Service

1. A DistributedService, Adaptive to Trust Assessment, based on Peer-to-Peer E-RecordsReplication and Storage Lorenzo Tomasi Marco Casassa Mont

2. Table of Contents • Trusted Services and PAST Service • Objectives • Research Problem • Scenario and Use Cases • Service Architecture • Related work • Future steps • Conclusions

3. Trusted E-Services

4. A Service for long-term preservation of e-records • Long-term preservation of electronic documents involves • renewal of information • migration of data through technology • survivability • long-term access control • integrity • privacy • confidentiality • authenticity • ………………

5. Persistent Active STorage Service

6. PAST Architecture : Layers

7. Objectives • Develop a service for long-term storage of e-records that can be used by PAST Service as a physical storage layer element • The service should be able to : • store,delete and retrieve a document • preserve a document for a long period • guarantee documents’ survivability, integrity and confidentiality

8. Objectives Long-term storage of e-records in a medium-large enterprise

9. Traditional solutions SAN for example … Focus on rapid and frequent access to data Dedicated, expensive solutions

10. Cheap resources • Cheap and abundant resources within the enterprise : • are geographically distributed (survivability) • their storage capacity and CPU time are not fully in use

11. Environment description • Environment is dynamic (in the long term period) • PCs change • users change • users’ profiles change • Environment is : • collaborative • unreliable / not trusted • not malicious

12. Research area Using cheap and abundant resources within a medium-large enterprise is an opportunity and a challenge Opportunity : take advantage of cheap resources Challenge : cope with a dynamic and unreliable environment Objectives : long-term storage, survivability, integrity and confidentiality of e-records

13. Research Variables none Trust full centralized Control centralized distributed Resources distributed

14. Related Work Trust Control traditional FarSite Resources OceanStore Frangipani

15. Related work • OceanStore • global scale • Farsite • long-term storage is not an issue • Frangipani • trusted environment • central administrator

16. Our research area Resources ---------- distributed Trust : unreliable but not malicious environment

17. Our research area • Control : • not centralized ( take advantage of distributed resources ) • not fully distributed ( likely anarchic, need for one trusted access point for PAST )

18. Trusted Not trusted Our model enterprise

19. Trusted Not trusted Scenario PAST Service PAST requests for storage, deletion and retrieval of e-records are accepted from the trusted, centralized controller

20. Use cases • join and leave • PAST ( client ) initiative • peers’ initiative • Focus on mechanisms

21. Use case : join

22. Use case : store

23. Use case : retrieve

24. Use case : delete

25. Use case : p2p

26. Basic mechanisms • Communication ( identity ) • Delegation • Integrity management ( signature ) • Confidentiality ( encryption ) • Survivability (documents’ replication )

27. Is this sufficient ? • Is replication sufficient for the goal of long-term storage ? • Reliability ??? Peers are not reliable !!! • That means peers may : • not be available • lose data (or data may get corrupted) • not be able to complete tasks

28. Monitoring • Motivation : peers’ unreliability • Objectives : • deal with this unreliability • observe peers’ behaviour • control copies’ status (survivability) • gather information that can trigger actions

29. Use case : monitoring

30. Use case : delegation of monitoring tasks

31. If we could learn … • If we could learn about peers’ behaviour and reliability : • we could have better management of storage and delegation • the whole system could be more efficient

32. What kind of information we collect ? Information needed can be collected through monitoring activities and other ordinary interactions with peers, and it can be about : • peers’ availability • copies’ correctness • peers’ ability to complete tasks with success • peers’ communication times

33. What do we learn ? • For example : • about peers’ availability and uptime • which peers are more reliable for completing tasks • which peers are more reliable for long-term storage • …

34. Rating system • It’s desirable that the controller can use a rating (sub)system that gives information about peers’ behaviour and reliability in order to do better choices • This (sub)system should use a “Trust and Reliability Function” that implements some kind of Trust Metrics

35. An Adaptive system • With a rating system, the controller can “follow” the environment’s changes, adopting : • dynamic criteria (for example, “delegation of tasks to reliable peers” is dynamic because it means delegating or revoking tasks, according to changes in peers’ reliability) • multiple policies (by knowing peers’ behaviour and according to how much dynamic the environment is, the controller can change its policies)

36. Architecture principles • Peers should be a cut-down version of the centralized controller • Architecture should be modular

37. High level architecture

38. High level architecture • Information base : basic information module and rating information module • Monitoring module • Rating module • Engines for testing, storage, deletion, and retrieval • Registration module • keys and identities manager • Communication manager

39. Architecture “Intelligent” components Engines (store, delete, retrieve, etc …) Communication Manager

40. Information base Architecture Policy-based and “planning” components May influence May update Engines Interaction with peers (via communication manager) Monitoring

41. Monitoring module architecture List of tasks Tasks manager From/to engines requests Generator Delegation manager From/to information base Scheduler

42. Rating module architecture Rating information db Trust function Information on peers’ behaviour queries “events” generator notifications

43. Security solutions • Identity certificates (central controller acts as a CA, but there is not a fully deployed PKI) • Secure communications (SSL like) • Delegation based on a SPKI model

44. Work done • System architecture design • Mid-term HP Labs report, accepted by VIII IEEE Workshop FTDCS ’01 • Skeleton prototype implemented

45. Trusted Not trusted Trusted Trusted Not trusted Not trusted Future work : inter-enterprise

46. Conclusions • Trust and Trust Assessment are an important issue for P2P applications, and in general for new trust services • Our approach : • guarantees long-term survivability, confidentiality and integrity of e-records • is modular • is adaptive to trust and reliability assessment