L-23 Trust and Reputation + Worms

advertisement
L-23 Trust and Reputation + Worms
Trust

Trust involves human activities
 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
2
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
3
Overview

SybilGuard: trust in people

Credence

Wi-Fi reports

Perspectives
4
Background: Sybil Attack

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
honest
malicious
launch
sybil
attack
 Out-vote honest users in
collaborative tasks
5
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
6
SybilGuard Basic Insight:
Leveraging Social Networks
Our Social Network Definition



Undirected graph
Nodes = identities
Edges = strong trust
 E.g., colleagues,
relatives
7
SybilGuard Basic Insight


n honest users: One identity/node each
Malicious users: Multiple identities each (sybil
nodes)
honest
nodes
attack
edges
sybil
nodes
Sybil nodes may
collude – the
adversary
malicious
user
Observation: Adversary cannot create
extra edges between honest nodes and
sybil nodes
8
SybilGuard Basic Insight
honest
nodes
sybil
nodes
Dis-proportionally
small cut
disconnecting a large
number of identities
But cannot search for
such cut bruteforce…
9
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
10
Random Walk Review
f
a
b
c
pick random edge d
d
e
pick random edge e
pick random edge c
11
Random Route: Convergence
f
a
b
randomized
routing table

ad
ba
cb
dc
d
c
de
ed
f f
e
Random 1 to 1 mapping between
incoming edge and outgoing edge
Using routing table gives Convergence
Property
 Routes merge if crossing the same edge
12
Random Route: Back-traceable
f
a
b

ad
ba
cb
dc
d
c
de
ed
f f
e
If we know the
route traverses
edge e, then we
know the whole
route
Using 1-1 mapping gives Back-traceable
Property
 Routes may be back-traced
13
Random Route Intersection:
Honest Nodes

Verifier
Suspect
Verifier accepts
a suspect if the
two routes
intersect
 Route length w:
~ n log n

honest nodes
sybil nodes
 W.h.p., verifier’s
route stays within
honest region
 W.h.p., routes
from two honest
nodes intersect
14
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
15
Bound # Intersections Within g
must cross attack edge to intersect even if sybil
nodes do not follow the protocol

Verifier
Suspect
same
intersection
honest nodes
sybil nodes
Convergence:
Each attack edge
gives one
intersection
 at most g
intersections with
g attack edges
Intersection =
(node, incoming edge
16
Bound # Sybil Nodes Accepted per
Intersection within w
Verifier
for a given intersection
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
17
Summary of SybilGuard Guarantees
Power of the adversary: If SybilGuard
 Unlimited number of
bounds #
colluding sybil nodes
accepted
 Sybil nodes may not follow
sybil nodes
SybilGuard protocol
within
 W.h.p., honest node
n/2
accepts ≤ g*w sybil
nodes
n
 g: # of attack edges

 w: Length of random route
Then apps
can do
byzantine
consensus
majority
voting
not much
effective
larger than n replication
18
Overview

SybilGuard

Credence: trust in objects based on
people

Wi-Fi reports

Perspectives
19
Problem: Pollution

P2P pollution
 Non-authentic content
 Corrupted or missing contents
 Viruses

What are the solutions?
 Ranked by popularity
 Ranked by submitter (how many filed submitted)
20
Credence: Reputation based on Voting
Is the file authentic?
21
Credence: Reputation based on Voting
Randomly choose
peers to collect votes
Is the file
authentic?
Is the file
authentic?
Is the file
authentic?
22
Credence: Reputation based on Voting
Randomly choose
peers to collect votes
Yes!
No
Yes!
23
Credence: Reputation based on Voting
What is the reputation
of each response?
(correlation coefficient)
Yes!
No
Yes!
24
Credence: Reputation based on Voting
Probably not authentic…
Yes!
No
Yes!
25
Credence Reputation Graph
26
Overview

SybilGuard

Credence

Wi-Fi reports: trust in objects based on
people with privacy

Perspectives
27
Problem: Commercial AP Selection
Jiwire.com
Hotspot database
tmobile
attwifi (ap 1)
attwifi (ap 2)
linksys
seattlewifi
Free Public Wifi
$9.9
9
$3.9
9
Quality
= ???
Free
!
Free
!
Which networks will run my applications?
Which ones have good performance?
We often have many choices of wireless
access points (APs), but little information about each
28
Goal: Provide More Information
Improved
Bandwidth: 300 kbps
Blocked ports: None
Hotspot database
Bandwidth: 100 kbps
Blocked ports: None
Bandwidth: 30 kbps
Blocked ports: Email
Doesn’t work!
Doesn’t work!
Bandwidth: 5 Mbps
Blocked ports: None
Bandwidth: 300 kbps
Blocked ports: None
tmobile
Bandwidth: 300 kbps
Blocked ports: None
attwifi (ap 1)
Bandwidth: 100 kbps
Blocked ports: None
attwifi (ap 2)
Bandwidth: 300 kbps
Blocked ports: None
linksys
Doesn’t work!
Bandwidth: 100 kbps
Blocked ports: Email,
Skype
Doesn’t work!
Free Public Wifi
seattlewifi
Doesn’t work!
Bandwidth: 300 kbps
Blocked ports: None
Doesn’t work!
I need to use VoIP so this is the
best network for me
Provide information about AP performance
and application support
29
Goal: Wifi-Reports
Users automatically report on APs that they use
30
Straw men Protocols
Alice’s
locations:
authenticate Alice
submit: R
R
Location Priva
If Alice has already
submitted
a report on cafe1 then
abort,
else save the report
measure cafe1
Anonymous
Report on
cafe1
Bandwidth: 5
100
Mb
report
on
cafe1
Mb
cafe1
tmobile #3
Bob’s Network
Alcohol Anon
Net
CMU
…
submit: R
mix network
31
Limited Influence
starbucks
cafe1
Report Protocol
…
authenticate and
download list of APs
List of all APs
cafe1
cafesolsti
ce
tmobile
#4
AT&T #54

{kcafe1, k-1cafe1}  new key pair
{kcafe2, k-1cafe2}  new key pair
request: cafe1, Tblind
Blind the token kcafe1 
…
If Alice requested cafe1
Tblind
before
reply: Sblind
then abort
else sign the token 
Unblind the signature 
Sblind
Scafe1
measure cafe1
Report on
cafe1
Bandwidth: 5
Mbps on cafe1
 report
R
Sign the report  SR
submit:
cafe1, Scafe1, kcafe1,
SR
mixR,
network
Verify the signatures
Delete old reports signed
with kcafe1
32
Report Protocol
authenticate and
download list of APs
{kcafe1, k-1cafe1}

new key pair
Blind the token kcafe1 
Tblind
cafe2
cafe1
Unblind the signature 
Scafe1
request: cafe1, Tblind
If Alice requested cafe1
before
reply: Sblind
then abort
else sign the token 
Sblind
Location PrivacyLimited Influenc
measure cafe1
R  report on cafe1
Sign the report  SR
submit:
cafe1, Scafe1, kcafe1,
SR
mixR,
network
Report on
cafe1
Bandwidth:
Report on 5
Mbps
cafe2
Verify the
Bandwidth: 5
Mbps
signatures
Delete old reports signed
with kcafe1
33
Overview

SybilGuard

Credence

Wi-Fi reports

Perspectives: trust in objects based on
independent semi-trusted views
34
“Man in the Middle” (MitM) Attacks
Alice needs Bob’s public key to establish a
secure channel (e.g., SSL/SSH) to him.
Hello,Bob
secure channel
Alice
KA
Bob
download code at:
http://www.cs.cmu.edu/~perspectives/
“Man in the Middle” (MitM) Attacks
Is KB really
Bob’s key?
Hello,Bob
“secure”
channel
Alice
KB
Mallory
If Alice accepts KB Mallory
can snoop and modify all
traffic!
download code at:
http://www.cs.cmu.edu/~perspectives/
Bob
Obtaining Authentic Public Keys
Two standard approaches to handling MitM attacks:
 Public Key Infrastructure (e.g., Verisign certs)
 Prayer
download code at:
http://www.cs.cmu.edu/~perspectives/
Perspectives Overview
KA
Bob’s Key?
Bob’s Key?
Offered
Key
Client
Policy
KA
N
Hello,Bob
Alice
KA
N
KA
Key?
KA KA Bob’s
KA
Observations
KA
Consistent
Inconsistent
Accept Key,
Continue
Reject Key, Abort
Connection
download code at:
http://www.cs.cmu.edu/~perspectives/
N
Bob
Worm Overview

Worm propagation

Worm signatures
39
Threat Model


Traditional
High-value targets
Insider threats
Worms & Botnets
 Automated attack of
millions of targets
 Value in aggregate,
not individual systems
 Threats: Software
vulnerabilities; naïve
users
... and it's profitable

Botnets used for

Flourishing Exchange market
 Spam (and more spam)?
 Credit card theft
 DDoS extortion
 Spam proxying: 3-10 cents/host/week
 25k botnets: $40k - $130k/year
 Also for stolen account compromised machines, credit
cards, identities, etc. (be worried)?
41
Why is this problem hard?
Monoculture: little “genetic diversity” in
hosts
 Instantaneous transmission: Almost
entire network within 500ms
 Slow immune response: human scales
(10x-1Mx slower!)?
 Poor hygiene: Out of date /
misconfigured systems; naïve users
 Intelligent designer ... of pathogens
 Near-Anonymitity

42
Propagation

Random scanning: grow exponentially

Localized scanning: biased scanning
towards local network

Multi-vector: use multiple propagation
methods simultaneously

Hit-list Scanning: collects a list of
vulnerable machines
43
Propagation (contd.)

Permutation scanning: generate random
permutation of all IP addresses, scan in
order

Hide worms in inconspicuous traffic to avoid
detection
44
Overview

Worm propagation

Worm signatures
45
Context

Worm Detection
 Scan detection
 Honeypots
 Host based behavioral detection
 Payload-based ???
Worm behavior

Content Invariance
 Limited polymorphism e.g. encryption
 key portions are invariant e.g. decryption routine

Content Prevalence
 invariant portion appear frequently

Address Dispersion
 # of infected distinct hosts grow overtime
 reflecting different source and dest. addresses
Content Sifting

For each string w, maintain
 prevalence(w): Number of times it is found in the
network traffic
 sources(w): Number of unique sources corresponding
to it
 destinations(w): Number of unique destinations
corresponding to it

If thresholds exceeded, then block(w)
Next Lecture (Last Lecture)


Privacy
Required readings
 Infranet: Circumventing Web Censorship and
Surveillance
 Improving Wireless Privacy with an Identifier-Free
Link Layer Protocol

Optional reading (on privacy)
 Information Slicing: Anonymity Using Unreliable
Overlays

Optional readings (on worms)
 How to own the Internet in Your Spare Time
 Automated Worm Fingerprinting
49
Download