ODISSEA

1. ODISSEA Security Issues Mehdi Kharrazi Kulesh Shanmugasundaram

2. SYN • SYN • P2P Security Basics • Introduction to ODISSEA • Security Issues in ODISSEA • Trust via Reputation • FIN

3. P2P Basics • All nodes are created equal. Not really! • Network classification based on network connectivity • Exponential Networks:Homogenous network, [average] node connectivity is equally distributed • Scale-free networks:Follows power-law for connectivity, that is there are some highly connected nodes and many not too highly connected nodes • Current P2P systems are scale-free networks

4. Network Maps • Partial map of Gnutella Network • Note the hierarchical structure of the network

5. Network Maps… • Gnutella Neighborhood Map

6. Failure vs. Attack • Failure: • Random failure of nodes and/or infrastructure elements • Attack: • Systematic failure of nodes and/or infrastructure elements • Scale-free networks are failure-tolerance • Exponential networks are attack-tolerance • Why? • Most P2P systems give priority for failure-tolerance over attack-tolerance

7. Possible Targets • Underlying protocol layers • P2P routing mechanism • Nodes themselves • Trust system • Homeostasis (of the system) • Applications/Application Protocols • Users More on that: “Security Issues in Peer-to-Peer Systems ”http://vip.poly.edu/kulesh/skunk/talks/

8. ODISSEA: A p2p Search Engine • A p2p search engine • Applications: • Search in p2p networks • Search in intranets • Web search • Middleware • How the search engine works?

9. ODISSEA: A p2p Search Engine

10. Security Issues • Three Categories: • P2P Search Engine Related • P2P Network Related • General Security Issues • Search Engine Related: • Content Poisoning: • Crawler • Parser • Query Processor • Protocol Security • Protection against MIMs • Truthful Execution of Ranking Algorithms • Compartmentalization • Search on a multi-level security network • Anonymity • P2P networks are used for anonymity

11. Content Poisoning • Crawler: • Crawler associates wrong URL with some document • E.g.: Associates playboy.com/index.html with ODISSEA web site! • Suggested solutions: • Random Re-Crawling: • At random re-crawl a URL • Simple but has re-crawling overhead • No verification from the source! • Signed Documents: • Have the web server sign the document (Just another header) • Parser verifies the signature prior to parsing • No re-crawling overhead • Requires PKI and web server needs to support signatures

12. Content Poisoning • Parser: • Malicious parser associates wrong keywords • E.g: Associates ODISSEA with porn! • Suggested Solutions: • TruthSayer for XML documents (Oakland ’01) • Query Processor: • Censorship by query processors!

13. Protocol Security • ODISSEA Search Protocol • Has no security primitives at all • MIM a good and easy possibility • Queries, query results can be altered • Postings and documents can be altered • E.g. Integrity of copies • Ranking Algorithms • Users have the option to send their own algorithm • There is no way to assure proper algorithm is used • I say “PageRank” query processor uses “PigeonRank”

14. ODISSEA for Multilevel Security Architecture • Ideal Setting: NSA Information Processing Facility • Environment: • Large secure intranet (100,000 nodes) • Multi-level security (from Unclassified to Umbra) • Users/nodes move between levels • Design Goals: • Optimal use of resources across levels • Enforces multi-level security via compartmentalization • Allows for a fast, scalable search engine • Agile enough to allow users move back and forth • Withstand malicious users, nodes etc. • Simple, Stupid, Scheme: • Assign a key (bit string) to each level • XOR every token of a document with the corresponding key • Search for (keyword XOR key) • Trivial to break and not scalable

15. Trust

16. Local Trust • Local trust value (ebay): • Problems: Does not get a wide view about the peer’s reputation Or It aggregates the whole network and causes congestion • Solution Transitive trust, if I trust you, then I would trust the one you trust

17. Aggregate Local Trust • Normalized local trust • Aggregate local trust values • If C = matrix [cij] : ti=CTci • To get a wider view peer i would ask his friend’s friend: ti=(CT)2ci ....and so on …. ti=(CT)nci • For large n, the trust vector converges to same vector for every peer i

18. Distributed EigenTrust • Each node can calculate it’s eigen trust value by: • Were p is a distribution over pre-trusted peers • Pre-trusted peers are essential for breaking malicious collectives • For example the very first nodes in the network i.e. designers

19. Distributed EigenTrust Algorithm

20. Distributed EigenTrust Algorithem • Fast convergences

21. Secure Eigentrust • Calculate the trust value of each peer by more than one peer (score managers) • If there is difference of opinion then vote! • Use DHT to assign score managers, using different hash functions. • Upsides: • Anonymity (can’t tell who’s trust your computing) • Randomization (can’t make yourself your own score manager) • Redundancy (more than one score manager)

22. Load distribution • Deterministic algorithm • Chose the responding peer with highest trust value • Probabilistic Algorithm • Choose peer i with probability . With probability of 10% select a peer j with zero trust value. • Why 10%? • A balance between allowing new users to gather trust, at the same time not granting malicious users a high chance of providing inauthentic files

30. FIN Questions, comments, concerns?