ODISSEA Mehdi Kharrazi Kulesh Shanmugasundaram Security Issues

SYN  SYN  P2P Security Basics  Introduction to ODISSEA  Security Issues in ODISSEA  Trust via Reputation  FIN

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

Network Maps  Partial map of Gnutella Network  Note the hierarchical structure of the network

Network Maps…  Gnutella Neighborhood Map

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

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 ”

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?

ODISSEA: A p2p Search Engine

Security Issues  Three Categories: 1.P2P Search Engine Related 2.P2P Network Related 3.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

Content Poisoning  Crawler: –Crawler associates wrong URL with some document –E.g.: Associates playboy.com/index.html with ODISSEA web site!  Suggested solutions: 1.Random Re-Crawling: At random re-crawl a URL Simple but has re-crawling overhead No verification from the source! 2.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

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!

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”

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

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 Local Trust

Aggregate Local Trust  Normalized local trust  Aggregate local trust values  If C = matrix [c ij ] : t i =C T c i  To get a wider view peer i would ask his friend’s friend: t i =(C T ) 2 c i....and so on …. t i =(C T ) n c i  For large n, the trust vector converges to same vector for every peer i

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

Distributed EigenTrust Algorithm

Distributed EigenTrust Algorithem  Fast convergences

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)

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

FIN Questions, comments, concerns?