1. Disrupting Peer-to-Peer Networks Sybil & Eclipse Attacks Lee Brintle University of Iowa

2. Sybil & Eclipse Attacks Many organizations may wish to disrupt some part of a P2P network Motivations Intellectual Property Owners Both piracy and legitimate content Governments Banned content, censorship Corporations Advertising, reputation, public relations

3. Sybil & Eclipse Attacks More subtle actions than just shutting it down Disruptions Missing Results Only censor some items Degraded Results Intentionally provide damaged or slow results Delayed Actions Function normally until a point in the future

4. Sybil & Eclipse Attacks Single entity posing as multiple entities Sybil Attack One attacker with many identities Named after character with MPD Many real-world examples John R. Douceur, Microsoft Research

5. Sybil & Eclipse Attacks How does a peer know about the trustworthiness of other peers? Three Sources of Information Itself Results of protocol interactions Other peers Trust in a large number of strangers External agencies Direct or indirect vouching for uniqueness of peers

6. Sybil & Eclipse Attacks Weed out duplicates by asking all to performing a task that a single entity cannot Direct Entity Validation Tests Ask all to perform task that one cannot do Make the attacker “too busy” to simulate all of them Simultaneously validate peers The attacker should not be allowed to focus on one Limit number of Sybil identities Ratio of resources – attacker / weakest legitimate user

7. Sybil & Eclipse Attacks Ways to see if a number of peers are sharing resources Sample Validation Tests Storage Require each to prove they can store Y GB Computation Require each to solve a “hard” puzzle Communication Require each to prove they have X Mb/s bandwidth

8. Sybil & Eclipse Attacks Trust a new entity based on the word of an already-verified entity Vouched-For Entities Verified Users May Vouch for Sybils Once they gain your trust, invite in other Sybils Faulty Verifications are Amplified One Sybil Vouches for them All Pushes the problem around

9. Sybil & Eclipse Attacks Attacking entity has more resources than the average user of the network Attackers Have Resources Lots of Bandwidth Lots of Disk Space Lots of CPU Lots of Identities

10. Sybil & Eclipse Attacks Knowing information about a peer beyond the peering protocol Direct Physical Knowledge Explicit Signing authorities, well-known users, software authors Implicit IP address allocation, network locale Irrelevant Ignore bad results, accept performance loss

11. Sybil & Eclipse Attacks Attackers gain disproportionate influence compared to legitimate users Eclipse Attack Fewer attackers Disproportionate level of influence Attackers eclipse legitimate users Singh, Ngan, Druschel, Wallach

12. Sybil & Eclipse Attacks Constrained routing table networks are difficult to attack – but perform poorly Structured Networks Topology is “fixed” – nodes have constant influence The routing is hard-wired based on address No flexibility in neighbor selection Cannot take advantage of proximity Some resistance to Eclipse attacks The more structure, the less susceptible

13. Sybil & Eclipse Attacks Eclipse attacks target the neighbor peering decision Unstructured Neighbor Selection Neighbors are selected, not assigned Each node picks “good” neighbors Nodes that look “good” have influence If a node is selected more often, gains more influence Potentially vulnerable to Eclipse attacks Attacking nodes become more influential

14. Sybil & Eclipse Attacks Mitigate Eclipse attacks by additional network structure, proximity, or degree bounds Eclipse Defenses Enforce strong structural routing Routes are dictated randomly, but performance suffers Select neighbors based on proximity But... most non-LAN nodes have roughly same delay Place a limit on number of degrees Degree bounds prevent nodes from being too influential

15. Sybil & Eclipse Attacks Detect hostile nodes, so they can be avoided in neighbor selection Profile of a Hostile Node High in-degree Must have higher influence than average High out-degree Tries to consume resources of average nodes Extremely effective 20% of nodes eventually have almost complete control

16. Sybil & Eclipse Attacks Avoid peers with large numbers of in-degree links Enforce In-Degree Bounds Refuse to peer with overloaded nodes Force each node to have “typical” influence Bound based on expected average degree Lower bounds more defense, worse performance Performance hit is 25% at average degree Degree bounds mean that less-optimal nodes are selected

17. Sybil & Eclipse Attacks Anonymously verify link set contains known nodes Catch a Lying Node: Audit Links Ask each peer for list of in-nodes For now, assume peer tells truth Drop peer if list is too long Do not allow a peer to gain too much influence Drop peer if list does not contain us If peer returns sub-set of true list, drop peer

18. Sybil & Eclipse Attacks Ask someone else to verify the node list Catch Lying Nodes: Distributed Audit Random node among the l closest to H(x) (chart from paper) Use random seed point Select multiple nodes Audits are aggregated

19. Sybil & Eclipse Attacks The auditor may be lying too... Distributed Audit Results Pass Fail Auditor legit, Target legit Auditor hostile, Target hostile Auditor legit, Target lucky hostile Audit legit, Target hostile Audit hostile, Target legit

20. Sybil & Eclipse Attacks Parameters which impact detection and performance Distributed Audit Tuning f: fraction of hostile nodes (.2) n: number of audits (24) (.2% false ID) k: number of successful audits (n/2) r: overload ratio on hostile nodes (1.2) t: permitted overload ratio (1) audit period (2 minutes) churn rate (0%, 5%, 10%, 15%)

21. Sybil & Eclipse Attacks Profile before auditing starts Distributed Audit Results Without prevention, malicious nodes have great influence (chart from paper)

22. Sybil & Eclipse Attacks Profile during auditing Distributed Audit Results f/(1-f) Auditing is effective in mitigating Eclipse attacks (chart from paper)

23. Sybil & Eclipse Attacks Optimized neighbors with auditing is still faster than non-optimized neighbors Performance Gain At t=.2, auditing rate=2 min, churn = 5 min: 4.75 msg/node/min messaging overhead

24. Sybil & Eclipse Attacks Yeah, but.... Caveats “The idea of churn as shelter from route poisoning attacks...” Unstructured networks need structured auditing BitTorrent can use a distributed tracker, for example Does not help super-node networks (KaZaAa) Asymmetry is part of performance gain Still weak against localized attacks Can target users on same network