15-446 Networked Systems Practicum Lecture 16 – Trust/Reputation

Trust Trust involves human activities After trust is established We share the same interests. We had a satisfactory transaction. We are friends. After trust is established Can bootstrap other forms of security using crypto

Overview SybilGuard: trust in people Credence: trust in objects based on people Wi-Fi reports: trust in objects based on people with privacy Perspectives: trust in objects based on independent views

Overview SybilGuard: trust in people Credence Wi-Fi reports Perspectives

Impact of Sybil Power of the adversary: Unlimited number of colluding sybil nodes Sybil nodes may not follow SybilGuard protocol W.h.p., honest node accepts ≤ g*w sybil nodes g: # of attack edges w: Length of random route If SybilGuard bounds # accepted sybil nodes within Then apps can do n/2 byzantine consensus n majority voting not much larger than n effective replication

Background: Sybil Attack honest Sybil attack: Single user pretends many fake/sybil identities Creating multiple accounts from different IP addresses Sybil identities can become a large fraction of all identities Out-vote honest users in collaborative tasks malicious launch sybil attack

Background: Defending Against Sybil Attack Using a trusted central authority Tie identities to actual human beings Not always desirable Can be hard to find such authority Sensitive info may scare away users Potential bottleneck and target of attack Without a trusted central authority Impossible unless using special assumptions [Douceur’02] Resource challenges not sufficient -- adversary can have much more resources than typical user

SybilGuard Basic Insight: Leveraging Social Networks Our Social Network Definition Undirected graph Nodes = identities Edges = strong trust E.g., colleagues, relatives

SybilGuard Basic Insight n honest users: One identity/node each Malicious users: Multiple identities each (sybil nodes) honest nodes sybil nodes attack edges Sybil nodes may collude – the adversary malicious user Observation: Adversary cannot create extra edges between honest nodes and sybil nodes

SybilGuard Basic Insight Dis-proportionally small cut disconnecting a large number of identities honest nodes sybil nodes But cannot search for such cut brute-force…

Goal of Sybil Defense Goal: Enable a verifier node to decide whether to accept another suspect node Accept: Provide service to / receive service from Idealized guarantee: An honest node accepts and only accepts other honest nodes SybilGuard: Bounds the number of sybil nodes accepted Guarantees are with high probability Approach: Acceptance based on random route intersection between verifier and suspect

Random Walk Review a f e b d c pick random edge d pick random edge e pick random edge c

Random Route: Convergence f e b d Random 1 to 1 mapping between incoming edge and outgoing edge a  d d  e c randomized routing table b  a e  d c  b f  f d  c Using routing table gives Convergence Property Routes merge if crossing the same edge

Random Route: Back-traceable f e b d a  d d  e If we know the route traverses edge e, then we know the whole route c b  a e  d c  b f  f d  c Using 1-1 mapping gives Back-traceable Property Routes may be back-traced

Random Route Intersection: Honest Nodes Verifier accepts a suspect if the two routes intersect Route length w: W.h.p., verifier’s route stays within honest region W.h.p., routes from two honest nodes intersect Verifier Suspect honest nodes sybil nodes

Random Route Intersection: Sybil Nodes SybilGuard bounds the number of accepted sybil nodes within g*w g: Number of attack edges w: Length of random routes Next … Convergence property to bound the number of intersections within g Back-traceable property to bound the number of accepted sybil nodes per intersection within w

Bound # Intersections Within g must cross attack edge to intersect even if sybil nodes do not follow the protocol Verifier Convergence: Each attack edge gives one intersection  at most g intersections with g attack edges Suspect same intersection Intersection = (node, incoming edge honest nodes sybil nodes

Bound # Sybil Nodes Accepted per Intersection within w Back-traceable: Each intersection should correspond to routes from at most w honest nodes Verifier accepts at most w nodes per intersection Will not hurt honest nodes Verifier for a given intersection

Summary of SybilGuard Guarantees Power of the adversary: Unlimited number of colluding sybil nodes Sybil nodes may not follow SybilGuard protocol W.h.p., honest node accepts ≤ g*w sybil nodes g: # of attack edges w: Length of random route If SybilGuard bounds # accepted sybil nodes within Then apps can do n/2 byzantine consensus n majority voting not much larger than n effective replication

Overview SybilGuard Credence: trust in objects based on people Wi-Fi reports Perspectives

Problem: Pollution P2P pollution What are the solutions? Non-authentic content Corrupted or missing contents Viruses What are the solutions? Ranked by popularity Ranked by submitter (how many filed submitted)

Credence: Reputation based on Voting Is the file authentic?

Credence: Reputation based on Voting Randomly choose peers to collect votes Is the file authentic? Is the file authentic? Is the file authentic?

Credence: Reputation based on Voting Randomly choose peers to collect votes Yes! No Yes!

Credence: Reputation based on Voting What is the reputation of each response? (correlation coefficient) Yes! No Yes!

Credence: Reputation based on Voting Probably not authentic… Yes! No Yes!

Credence Reputation Graph

Overview SybilGuard Credence Wi-Fi reports: trust in objects based on people with privacy Perspectives

Problem: Commercial AP Selection Jiwire.com Hotspot database tmobile attwifi (ap 1) attwifi (ap 2) seattlewifi linksys Free Public Wifi $3.99 $9.99 Free! Which networks will run my applications? Which ones have good performance? Quality = ??? Many of us have been in the situation where we are in a new area and want to find wireless connectivity. We might do this by looking up hotspots in a directory service like Jiwire.com. Or we might just open up our laptop and see lots of wifi access points or APs. But today, we can’t know the performance that we will get at these hotspots before we go to them and even then, we may have to pay money first. This is because we can only see the quality of the wireless link, not its backhaul connectivity or if it rate-limits users. Only then might we determine whether or not that the AP that we selected has poor performance or blocks our applications. We often have many choices of wireless access points (APs), but little information about each

Goal: Provide More Information Improved Hotspot database Bandwidth: 300 kbps Blocked ports: None tmobile attwifi (ap 1) attwifi (ap 2) seattlewifi linksys Free Public Wifi I need to use VoIP so this is the best network for me Bandwidth: 30 kbps Blocked ports: Email Bandwidth: 100 kbps Blocked ports: None Bandwidth: 300 kbps Blocked ports: None Bandwidth: 100 kbps Blocked ports: None Doesn’t work! Bandwidth: 100 kbps Blocked ports: Email, Skype Doesn’t work! Doesn’t work! Bandwidth: 300 kbps Blocked ports: None Bandwidth: 5 Mbps Blocked ports: None Doesn’t work! Our goal in this talk is to provide users with more information. That is, we would like to annotate hotspot directories with performance information about each AP. In addition, if users cache part of this directory while mobile, we would like them to accurately determine the performance information about APs that are visible so they can pick the best one. Bandwidth: 300 kbps Blocked ports: None Doesn’t work! Provide information about AP performance and application support

Users automatically report on APs that they use Goal: Wifi-Reports One way to provide this information is to have users that use APs submit reports about them to a database. Future users can then obtain this information to predict their performance. Our goal is to build such a system which we call wifi-reports. In such a system, first a client would measure the APs that he uses. Then, he would login to the service via an account authority, like Google. This account authority would give him the right to submit the report to a database where all reports would be summarized. Future users can download and cache these summaries, like with the iPass hotspot client today. Then they can find the best APs nearby. Users automatically report on APs that they use

Strawmen Protocols authenticate Alice Location Privacy submit: R Alice’s locations: cafe1 tmobile #3 Bob’s Network Alcohol Anon Net CMU … Location Privacy authenticate Alice submit: R If Alice has already submitted a report on cafe1 then abort, else save the report measure cafe1 Given these assumptions, we first try some simple protocols. The first thing we might try is to submit the reports over a mix network… Anonymous Report on cafe1 Bandwidth: 100 Mb Anonymous Report on cafe1 Bandwidth: 5 Mb Anonymous Report on cafe1 Bandwidth: 100 Mb Anonymous Report on cafe1 Bandwidth: 100 Mb Anonymous Report on cafe1 Bandwidth: 5 Mb Anonymous Report on cafe1 Bandwidth: 100 Mb Anonymous Report on cafe1 Bandwidth: 100 Mb mix network submit: R R  report on cafe1 Limited Influence

Report Protocol List of all APs authenticate and download list of APs cafe1 starbucks2 cafe2 … Report Protocol List of all APs cafe1 cafesolstice tmobile #4 AT&T #54  authenticate and download list of APs {kcafe1, k-1cafe1}  new key pair {kcafe2, k-1cafe2}  new key pair … Blind the token kcafe1  Tblind request: cafe1, Tblind If Alice requested cafe1 before then abort else sign the token  Sblind reply: Sblind Unblind the signature  Scafe1 measure cafe1 To achieve both properties, we need to do something less obvious. First we assume that the account authority has a list of APs in the system. We can build this list and update it in the same way that hotspot directories build their lists today, e.g., by having the owners of hotspots add them. Now, at some point either before or after using APs, Alice logs in and downloads the list. For each AP in the list… For clarity, we’ll just look at the token for cafe1, we do the same thing for each one she generates. The idea is that we require alice to sign reports for cafe1 with this token. To achieve… To get these properties with respect to the account authority… Alice blinds the token… The account authority signs the token but makes sure Alice can only request one token for cafe1. Although cafe1 is revealed in the request, the AA has no information about what it just signed. Alice unblinds… Then when Alice wants to submit a report… Of course, all this can be done automatically by a software client. mix network submit: cafe1, Scafe1, kcafe1, R, SR Report on cafe1 Bandwidth: 5 Mbps Report on cafe1 Bandwidth: 5 Mbps Verify the signatures Delete old reports signed with kcafe1 R  report on cafe1 Sign the report  SR

Report Protocol authenticate and download list of APs {kcafe1, k-1cafe1}  new key pair Blind the token kcafe1  Tblind Location Privacy request: cafe1, Tblind If Alice requested cafe1 before then abort else sign the token  Sblind Limited Influence cafe1 Report on cafe2 Bandwidth: 5 Mbps cafe2 reply: Sblind Unblind the signature  Scafe1 measure cafe1 Report on cafe1 Bandwidth: 5 Mbps Remember, Alice will get tokens for many different APs. The protocol achieves location privacy because the properties of the blind signature scheme ensure the account authority doesn’t know the actual value of the tokens each user has. The mix network prevents the database from determining who submitted which report. However, we still get limited influence because when requesting a token, a user names the AP it is for. Thus, even though the account authority doesn’t know what the token is, it can still regulate the number of tokens each user gets for each AP. And the database can determine which reports are signed with the same token. mix network submit: cafe1, Scafe1, kcafe1, R, SR Verify the signatures Delete old reports signed with kcafe1 R  report on cafe1 Sign the report  SR

Overview SybilGuard Credence Wi-Fi reports Perspectives: trust in objects based on independent semi-trusted views

“Man in the Middle” (MitM) Attacks secure channel Alice needs Bob’s public key to establish a secure channel (e.g., SSL/SSH) to him. Hello,Bob KA Alice Bob

“Man in the Middle” (MitM) Attacks Is KB really Bob’s key? “secure” channel Mallory Hello,Bob KB Alice Bob If Alice accepts KB Mallory can snoop and modify all traffic!

Obtaining Authentic Public Keys Two standard approaches to handling MitM attacks: Public Key Infrastructure (e.g., Verisign certs) Prayer Its not exaggerating by much to say anyone who has typed “yes” or clicked OK on a menu like this has been entrusting the security of their data to a higher power. It is possible to use SSH or self-signed certs securely, but that requires each user to essentially fulfill the role of a certificate authority themselves. Our experience suggests that even people with a healthy understanding of Internet security tend to cross their fingers and continue in the face of such warnings.

Perspectives Overview N KA Bob’s Key? KA N Bob’s Key? Hello,Bob Alice KA Bob KA Bob’s Key? KA KA KA * Notary response with key(s) they have seen bob using over the last month… Offered Key Observations N KA Client Policy Consistent Accept Key, Continue Inconsistent Reject Key, Abort Connection