1. Peer-to-Peer Information Systems Week 13: Trust Old Dominion University Department of Computer Science CS 495/595 Fall 2003 Michael L. Nelson 11/17/03

2. Trust (in Real Life) Trust in real life is increased by: –establishing positive reputations and networks for conveying these reputations –decreasing the number of people that have to be trusted –reducing risk However, in chapter 15 the focus is not on increasing trustworthiness, but rather reducing the requirement for trust –“the ideal trusted system is on that everyone has confidence in because they do not have to trust it”

3. Trust When Downloading Software RiskSolutionTrust Principle S/W doesn’t behave as advertised, and may even damage your system Only download s/w from companies/individuals who have established a good reputation, or those you know where to find should a problem occur Look for positive reputations S/W is modified (on server or in transit) Check for digital signature on message digest and verify signature against author’s certificate Use tools that accurately convey reputations Your downloads (and other activities) are logged by your ISP or other parties Use an anonymity tool so other parties do not get access to information that might link you to a particular download Reduce risk Table 15.1, p. 245

4. S/W Reputations in P2P Systems Not every P2P software package ties into an established entity with significant reputation credentials –e.g.: how would you bootstrap the distribution of the s/w we have developed in class? –similarly, where does one go to get a canonical Gnutella client? P2P and traditional notions of trust (or “branding”) are somewhat incompatible…

5. Detecting Tampering Assuming the organization / person you are downloading from is trustworthy, how do you know that: –the s/w was not modified on their server? –the s/w was not modified in transit? Message digest (e.g. MD5) can be used to alert to modifications –but clever attackers will modify the digest value Digital signatures can be used to “tamper-proof” the message digest –assumes integrity of the authors private key…

6. Sandboxing & Wrapping Many programs are in place to limit damage to the computer system, whether malicious or unintentional –for example, the OS limits your actions to your files, not the the files of others Java applets, for example, run in sandbox mode to prevent nasty things like file deletion But what of open source software? –if you install MS Office, you are trusting that it will not do anything bad –how would you convince others to trust your P2P app?

7. Web Server Logging anonymizer.com this portion of the transaction is visible will not reveal your IP (and thus your identity) to the remote server presumably, the anonymizing proxy can be trusted… is this a good assumption?

8. Web Server Logging SSL will prevent eavesdropping, but reveal your identity to the remote server

9. Web Server Logging …a mix network will encrypt the traffic and hide your identity from the server crowds will hide your identify and provide plausible deniability on the local side… but what if the mix network was installed by the RIAA? what if a crowd participants returned random pages?

10. Trust and Searching How well do you trust the query results of: –an Internet search engine? –100s - 1000s of distributed clients? Do the results really match your query? –malice, e.g.: RIAA returns MP3s that say “stealing music is bad” queries are changed to reflect the preferences of node operators –accident, e.g.: nodes are down query is damaged lack of authority files (“which version of _Louie Louie_”) content is 404

11. Building Trust / Reputation Into Our P2P Application What if we built a reputation metric into our system? Possible ideas: –content quality 1 = perfect transaction 0.5 = peer was confused or had errors 0.0 = peer lied about the content –duration keep track of the number of transactions

12. Trust: Local vs. Remote Certainly users are best suited to determine their own experience of trust… But this is simply automating what a single user experiences anyway… –this advises based on past transactions, but does not advise regarding unknown partners How do we: –bootstrap the system? –share reputations with friends? –avoid “bad” nodes? –not punish late arrivers?

13. Proposed Solution modify the friends list to be: cirrus.cs.edu 3923 mln@cs.odu.edu VTRULZ <trust average=“0.95” total=“25.65” frequency=“27”>

14. Remote Trust further modify the friends list: cirrus.cs.odu.edu 3923 mln@cs.odu.edu VTRULZ <trust average=“0.95” total=“25.65” frequency=“27” \> <friendsTrust average=“0.90” total=“315” frequency=“350” contributors=“11” \>

15. Exchanging Trust “listFriends” verb –can be issued periodically or on demand –of course, you would issue this only on the friends you trust –also would increase the list of known peers

16. Identifying Bad Sites Listing “bad” friends will inform others as well as maintain your own “opinion” of a host … riaa.cs.odu.edu 4000 badguy@cs.odu.edu VTRULZ <trust average=“0.125” total=“0.5” frequency=“4” \> <friendsTrust average=“0.066” total=“1” frequency=“15” contributors=“6”\>

17. Managing the Lists listFriends –returns a element listBadFriends –return a element borrows the same schema from

18. Peer Configurability Trust comes at a price -- increased semantic load for the user: –specify trust metric threshold only interact with friends I trust at >= X –specify age preference only interact with friends I trust at >=X and have N trusted transactions logged

19. Late Joiners So I find out about your client 6 months after everyone else… how do I join the system if everyone is only trusting peers with age and longevity? Options: –allow user specifiable “grace” period for new nodes; e.g.: trust >= 0.5; transactions <=10

20. Friends of My Friends is a cumulative metric… –but how much more important is it than my experiences? User parameter example: –local trust = 0.7 –remote trust = 0.3 Total trust is now a configurable weighted metric –must account for situations where either local or remote trust is not (yet) defined

21. Extracting Feedback From the User Don’t annoy the users… –should be able to turn the whole thing off/on –should be able to specify semantics of: “trust this user now” “always trust this user” –silently give all their transactions top marks “never trust this user” –no matter what my friends say etc. –have (configurable) default values for transaction rating