1. Peer-to-Peer Information Systems Week 11: Trust Old Dominion University Department of Computer Science CS 495/595 Fall 2004 Michael L. Nelson 11/09/04

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 author’s private key… –…and access to the author’s public key

6. Digital Certificates & Certificate Authorities 1.Alice writes software package P 2.Alice gets a certificate from CA 3.Alice’s signature A=Sign(Pub Alice,Digest(P)) 4.Alice uploads P, A 1.Bob downloads P, A 2.Bob gets Alice’s public key from the CA 3.Bob computes B=Sign(Pub Alice, Digest(P)) 4.if A==B, then P is ok Alice’s webpageCertificate Authority cf. Figure 15-1, p. 247

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

8. 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?

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

10. Web Server Logging …a mix network will encrypt the traffic and hide your identity from the server crowds will hide your identity 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?

11. 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” –cf. C. Lynch’s “When Documents Deceive : Trust and Provenance as New Factors for Information Retrieval in a Tangled Web”, JASIS 52(1), 12-17. 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

12. Trust in Censorship Resistant Systems RiskSolutionTrust Principle Servers, proxies, ISPs, etc. may log your requests Use a secure channel and/or anonymity tool to disassociate you and your actions reduce risk; reduce # of people to be trusted Proxies & search engines may alter content Run your own proxy; try several proxies / search engines and compare results reduce risk; reduce # of people to be trusted Multiple parties may conspire to censor your document Publish your document in a way that requires many parties to conspire for censorship reduce # of people to be trusted Parties may censor your document through false updates Publish in an update-free systemreduce # of people to be trusted Censors may flood system with content in a DoS attack Impose limits/quotas; require fungible or non-fungible quid-pro- quo; use a reputation system reduce # of reduce risk; look for good reputations Censors may use legal tacticsPublish your document in a way that requires many parties to conspire for censorship reduce # of people to be trusted Censors may threaten you to delete you own documents Publish in systems that do not allow deletions reduce risk; reduce # of people to be trusted condensed Table 15.2, p. 269

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

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

15. 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”>

16. 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” \>

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

18. 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”\>

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

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

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

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

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