View
7
Download
0
Category
Preview:
Citation preview
Basic Course on Onion Routing
Paul Syverson a U.S. Naval Research Laboratory f paul.syverson@nrl.navy.mil p
SAC Summer School Mount Allison University Aug 10, 2015
Course Outline ● Lecture 1: Basics and Formalization
• Usage examples, basic notions of traffic-secure communications, mixes and onion routers
• Onion routing design basics: circuit construction protocols, network discovery
• Formalization and analysis, possibilistic and probabilistic definitions of anonymity
● Lecture 2: Security for the real world • Simple demo of obtaining/using Tor • Security of obtain/using Tor • Adding network link awareness • Importance of modeling users • Importance of realistic and practical
• Adversary models Security definitions
2
“Our motivation here is not to provide anonymous communication, but to separate identification from routing.”
● “Proxies for anonymous routing”. Reed, Syverson, and Goldschlag. ACSAC 1996
A Motivational Use Case Example
● Navy Petty Officer Alice is on temporary duty out of the U.S.
Motivational Use Case Example
● Safe back in her hotel, PO Alice wants to read and/or post to sealiftcommand.com
1. The site is blocked where she is deployed 2. The Internet is monitored where she is deployed
6
7
Use Case Example
● Safe back in her hotel, PO Alice wants to read and/or post to sealiftcommand.com
1. The site is blocked where she is deployed 2. The Internet is monitored where she is deployed
8
Connecting when overseas
Navy PO Alice in her hotel
9
Connecting when overseas
Navy PO Alice in her hotel Contacted:
sealiftcommand.com 08/09/2015, 9PM, 20 min, encrypted
10
Connecting when overseas
Navy PO Alice in her hotel Contacted:
sealiftcommand.com 08/09/2015, 9PM, 20 min, encrypted Rm: 216 Ckout on: 08/14/2015 11
Security of operations concern as well as personnel security concern
Navy PO Alice in her hotel Contacted:
nrl.navy.mil 08/09/2015, 9PM, 20 min, encrypted Rm: 216 Ckout on: 08/14/2015 12
Some more government uses
● Open source intelligence gathering ● Sensitive communications with untrusted/
untrusting parties ● Encouraging open communications with citizens ● Reduce risk/liability from data breaches, DNS
hijacks,… ● Location protected servers for defense in depth ● Protecting the public infrastructure
– Interacting with network sensors
13
Officer Alice
● Setting up a sting operation: – as a collaborator – as a service provider
● Monitoring criminal activity online ● Encouraging anonymous tips
14
Corporation Alice
● Checking out the competition ● Exploration of collaborations and
partnerships ● Patent searches ● Protecting her customers
15
Researcher/Reporter/Rights Worker Alice ● Gathering information while protecting
sources ● Accessing information that is locally
censored or monitored ● Reporting information that is locally censored
or monitored
16
Ordinary citizen Alice
● Protecting her behavior from: ● Cyberstalking abusive ex-spouse ● Behavior tracking, DNS shenanigans by her ISP ● Misunderstanding from her employer when she
investigates disease info for an ailing friend ● Harassment for blogging her views ● Spear phishers watching her log into her bank
17
Recent U.N. Human Rights Commission Report Conclusion
“States should promote strong encryption and anonymity.” ● Also specifically mentions the importance of
protecting IP address, and Tor as an important technology protecting freedom to hold and express opinions.
18
First Anonymous Comms Design (Chaum Mix) ● Untraceable Electronic Mail, Return addresses, and
Digital Pseudonyms – David Chaum, CACM 1981
19
message 2
Key property: Adversary can’t tell which ciphertext corresponds to a given message
?
What does a mix network do?
Mixes
Invented by Chaum 1981 (not counting ancient Athens)
As long as one mix is honest, network hides anonymity up to capacity of the mix
Sort of - Flooding - Trickling
Many variants - Timed - Pool - ...
Athenian Jury Ballots (4th C BCE)
26
Also had cool randomized jury selection mechanism (kleroterion)
Mixes
Invented by Chaum 1981 (not counting ancient Athens)
As long as one mix is honest, network hides anonymity up to capacity of the mix
Sort of - Flooding - Trickling
Many variants - Timed - Pool - ...
Chaum ‘81: First Adversary Model 1. “No one can determine anything about the
correspondences between a set of sealed items and the corresponding set of unsealed items, or create forgeries without the appropriate random string or private key.”
Crypto is black-box secure (Dolev-Yao Model)
2. “Anyone may learn the origin, destination(s), and representation of all messages in the underlying telecommunication system and anyone may inject, remove, or modify messages.”
Active and Global Adversary
28
David Chaum: Way Ahead of His Time In 1981 ● SMTP was one year in the future ● IRC was seven years in the future ● The Web (Mosaic) was twelve years in the future ● (Dolev-Yao Model was two years in the future)
29
● Explicitly recognized and countered replay attacks
1993: The Web takes off
A useful adversary model must fit usage environment – Application protocols must function – Usability is a security property
Both interactivity and low-latency break Chaum’s assumptions
– Web comms mostly based on bidirection TCP connections – Web comms are low latency
30
Low-latency systems are vulnerable to correlation by a global adversary
Low-latency: Alice1 sends: Bob2 gets: $
Alice2 sends: Bob1 gets:
High-latency: Alice1 sends: Alice2 sends: $
Bob1 gets: ..... Bob2 gets: .....
Time
These attacks work in practice. The obvious defenses are expensive (like high-latency), useless, or both.
match!
match!
Connecting when overseas
Navy PO Alice in her hotel
32
Practical Secure Solutions Navy PO Alice
in her hotel
Solution System
Solution must • Carry traffic bidirectionally with low latency • But that is broken against our adversary model?!
33
Practical Secure Solutions Navy PO Alice
in her hotel
Solution System
Solution must • Carry traffic bidirectionally with low latency • But that is broken against our adversary model?! • So need a design making global adversary unlikely
- very large and diversely managed network
• Carry traffic for a diverse user population - not just Navy or U.S. govt. - cannot have single point of failure/trust for any type of user
• Diversely managed infrastructure • Open source
34
Network of diversely managed relays so that no single one can betray Alice.
R1
R4 R2
R5
R3
Bob Alice
35
A corrupt first hop can tell that Alice is talking, but not to whom.
R4 R2
R5
R3
Bob Alice
36
A corrupt last hop can tell someone is talking to Bob, but not who.
R1
R4 R2
R3
Bob Alice
37
Onion Routing: Circuit construction
R1
R4 R2
R5
R3
Bob Alice
38
Onion Routing: Circuit construction
R1
R4 R2
R5
R3
Bob Alice
39
Onion Routing: Circuit construction
R1
R4 R2
R5
R3
Bob Alice
40
Onion Routing: Connection creation
R1
R4 R2
R5
R3
Bob Alice
41
Onion Routing: Data Exchange
R1
R4 R2
R5
R3
Bob Alice
42
Onion Routing: Data Exchange
R1
R4 R2
R5
R3
Bobs Alice
43
That's onion routing in a nutshell
44
What onion routing is NOT: Mixes
● Entirely different threat model • mixes are based on an adversary not being able to
correlate inputs and outputs he sees • onion routing is based on an adversary not being able to
see both inputs and outputs to correlate ● Entirely different communications paradigm:
Circuit based encryption vs. per message • onion routing supports bidirectional communication • onion routing supports low-latency communication
● Can be combined to make mixing onion routers, but not typically done or desired
45
What onion routing is
● Uses expensive crypto (public-key) to lay a cryptographic circuit over which data is passed
● Typically uses free-route circuit building to make location of circuit endpoints unpredictable
46
Why call it “onion routing”? Answer: Because of the original key distribution data structure
47
R1
R4 R2
R5
R3
Bob Alice
Why is it called onion routing?
● Onion: Just layers of public-key crypto • Nothing in the center, just another layer
Bob Alice R1
R2
R5
R4 R3
KA,R1 R2
KA,R2 R5
KA,R5 ⊥ $
48
Circuit setup
● NRL v0 and v1 onion routing and also ZKS Freedom network used onions to build circuits
• Lacked Forward Secrecy • Required storing record of onions against replay
● Tor (NRL v2) uses one layer “onion skins” • ephemeral Diffie-Hellman yields forward secrecy • No need to record processed onions against replay • From suggestion out of Zack Brown’s Cebolla
KA,R1 R2
KA,R2 R5
KA,R5 ⊥ $
49
Aside: Why is it called ‘Tor’ and what does ‘Tor’ mean? ● Frequent question to Roger c. 2001-2: Oh
you’re working on onion routing... which one? ● Roger: THE onion routing. The original onion
routing project from NRL. ● Rachel: That’s a good acronym. ● Roger: And it’s a good recursive acronym. ● Plus, as a word, it has a good meaning in
German (door/gate/portal) and Turkish (fine-meshed net)
50
Aside: Why is it called ‘Tor’ and what does ‘Tor’ mean? ● We foolishly called the first Tor paper “Tor:
the second generation onion router” ● But this was very confusing
• ‘Tor’ stands for “The onion routing” or “Tor’s onion routing”. It does not stand for “the onion router”
• The paper is about the whole system, not just the onion routers
• Tor is not the second generation
51
Onion routing origins: Generation 0
● Fixed-length five-node circuits ● Integrated configuration ● Static topology ● Loose-source routing Partial active adversary ● Rendezvous servers and reply onions
52
Onion routing, the next generation Running a client separated from running an OR ● Variable length circuits (up to 11 hops per
onion---or tunnel for more) ● Application independent proxies (SOCKS) plus
redirector Entry policies and exit policies ● Dynamic network state, flat distribution of state
info ● Multiplexing of multiple application connections
in single onion routing circuit ● Mixing of cells from different circuits ● Padding and bandwidth limiting
53
Third-generation onion routing (Tor) Onion skins, not onions: Diffie-Hellman based
circuit building ● Fixed-length three-hop circuits ● Rendezvous circuits and hidden servers ● Directory servers, caching (evolved w/in Tor) ● Most application specific proxies no longer
needed (still need e.g. for DNS) ● Congestion control ● End-to-end integrity checking ● No mixing and no padding
54
Circuit setup
● NRL v0 and v1 onion routing and also ZKS Freedom network used onions to build circuits
• Lacked Forward Secrecy • Required storing record of onions against replay
● Tor (NRL v2) uses one layer “onion skins” • ephemeral Diffie-Hellman yields forward secrecy • No need to record processed onions against replay • From suggestion out of Zack Brown’s Cebolla
KA,R1 R2
KA,R2 R5
KA,R5 ⊥ $
55
Client Initiator
Original Tor Circuit Setup (Create)
, Hash( )
Onion Router
Client chooses first node, establishes session key over TLS connection "
TLS connection
56
Client chooses first node, establishes session key over TLS connection "
Client Initiator
Original Tor Circuit Setup (Create)
, Hash( )
Onion Router
57
Client chooses first node, establishes session key over TLS connection "
Original Tor Circuit Setup (Extend)
Client Initiator
, Hash ( ) OR2 OR1
, Hash ( )
OR2,
58
Slight simplification of actual protocol "
Original Tor Circuit Setup (Begin) and Data Flow
Client Initiator
OR1
Web server
Reply
OR2
Connect
Reply
59
Why a Tor authenticated key establishment protocol ● Designing your own authentication protocol is error prone.
Why not use an established protocol in the first place? ● Answer 1: We require only one-way authentication. Two way
wastes expensive computation. ● Answer 2: To fit whole messages inside Tor cells. A public
key and a signature don’t both fit in one 512-byte cell. ● Protocol was verified using the NRL protocol analyzer in the
Dolev-Yao model. ● In 2005 Ian Goldberg found flaw in the way Tor implemented
this protocol (checking that a public value was not based on a weak key).
● In 2006 Ian proved the (properly implemented) protocol secure in the random oracle model.
60
Circuit establishment efficiency ● Original Tor Authentication Protocol (TAP) uses RSA to encrypt the
Diffie-Hellman public key
● New/Old idea (1st considered in 1996): Let the nodes use published public DH keys
● Clients create ephemeral DH keys to combine with published node DH keys (ElGamal key exchange aka half-certified Diffie-Hellman exchange)
● Saves one exponentiation at client and one at node for each node in circuit (about half current load)
● Significantly reduces Tor overhead for running a volunteer node
61
Brief history of using Diffie-Hellman in Tor Circuit Establishment 1996: We (Goldschlag, Reed, me) considered including DH keys in layers of
circuit-establishment onion – For computational efficiency (not considering Forward Secrecy then)
2004: TAP replaces onions, includes DH for Forward Sec. (Dingledine, Mathewson, me)
– Verified using NRL Protocol Analyzer in Dolev-Yao Model
2005: Goldberg verifies TAP in Random Oracle Model
2007: We (Øverlier and me) propose “fourth protocol”, DH-based authentication and key-establisment (with informal security argument)
2012: Goldberg, Stebila, and Ostaoglu break fourth protocol, introduce ntor
2013: ECDH (curve 25519) version of ntor included in Tor stable release
62
Network and Route Discovery ● Alice has to know a set of nodes and pick a
route from them – Must know how to find R1 – Must learn more network nodes to pick a route – Cannot trust R1 to tell about the rest of the
network
Bob Alice R1
R2
R5
R4 R3 63
Network and Route Discovery ● Alice has to know a set of nodes and pick a
route from them – Must know how to find R1 – Must learn more network nodes to pick a route – Cannot trust R1 to tell about the rest of the
network
Bob Alice R1
R1’
R1’’
R4 R3 64
How do we know where to build a circuit? Network discovery. ● Important for all clients to get same picture of
network to avoid epistemic partitioning ● Initial onion routing design had trivial/brittle
solution – network and identity keys simply hard coded in
prototypes ● Next generation had a design for flat flooding of
network state to all relays – complex, tricky, scales in principal but ? – not ever deployed in practice
● Tor has a directory system: See next slides ● Bridge distribution: Should have gone to FOCI.
65
Tor Directory Version 1
● Directory authorities serve – Relay descriptors containing e.g. identity keys & IP
addresses – Network status: whether relays are up or down
● Network caches added to prevent DirAuths from being comms bottleneck
66
Tor Directory Version 2
Issue 1: ● As Tor network grew so did size of directory
– large downloads a problem ● Most descriptor info relatively persistent Solution: ● Directory authorities serve
– Network status summary: Hashes of each relay’s current descriptor
– Clients retrieve full descriptors only for relays they don’t know or that have changed
67
Tor Directory Version 2
Issue 2: ● Version 1 DirAuths function independently
– trust bottleneck – Risk grows with number of DirAuths
Solution: ● Clients trust statements about relays made
by majority of DirAuths
68
Tor Directory Version 3
Issue 1: Descriptors contain much useful info not needed for basic contact
Solution: Microdescriptors go into consensus – Identity key, address, exit ports
– Good for about a week typically
69
Tor Directory Version 3
Issue 2: Update and synch. Issues can lead to clients having different network views
Solution: Collective DirAuth vote on network consensus
Issue 3: Identity keys for DirAuths most sensitive data
Solution: Create DirAuth network info signing keys and keep identity keys offline
70
Onion routing started from a practical motivation ● How do we know the whole enterprise is not
fundamentally broken on an abstract level? ● Where’s the underlying theory to back this up?
● Note: OK not to have a rigorous notion of security at first
– Analyses based on state of the art would have been misleading
– Global Passive Adversary both too strong and too weak ● Cf. “Why I’m not an Entropist” and “Sleeping Dogs Lie in a Bed
of Onions but Wake when Mixed”
71
Anonymous Communication c. 2000
Mix Networks Dining cryptographers Onion routing Crowds
Deployed Analyzed
4 72
Adversary observing all traffic entering and leaving network breaks onion routing
73 R4 R2
R3
Alice
Bob
Low-latency systems are vulnerable to correlation by a global adversary
Low-latency: Alice1 sends: Bob2 gets: $
Alice2 sends: Bob1 gets:
High-latency: Alice1 sends: Alice2 sends: $
Bob1 gets: ..... Bob2 gets: .....
Time
These attacks work in practice. The obvious defenses are expensive (like high-latency), useless, or both.
match!
match!
Adversary observing all traffic entering and leaving network breaks onion routing ● “Towards an Analysis of Onion Routing Security” Syverson et al. PETS 2000
● Presented and analyzed adversary model assumed in prior onion routing work
– Network of n onion routers, c compromised onion routers – Security approx. c2 / n2
75 R4 R2
R3
Alice
Bob
Formal analysis of onion routing
1. Possibilistic characterization using I/O automata
2. Probabilistic analysis abstracting I/O automata characterization to a black box
3. Representing black-box results in standard cryptographic models
76
Possibilistic Analysis Overview ● Formally model onion routing using input/
output automata ● Characterize the situations that provide
anonymity
6 77
Possibilistic Analysis Overview ● Formally model onion routing using input/
output automata – Simplified onion-routing protocol – Non-cryptographic analysis
● Characterize the situations that provide anonymity
6 78
Possibilistic Analysis Overview ● Formally model onion routing using input/
output automata – Simplified onion-routing protocol – Non-cryptographic analysis
● Characterize the situations that provide anonymity
– Send a message, receive a message, communicate with a destination
– Possibilistic anonymity
6 79
Main Theorem [“A Model of Onion Routing with Provable Anonymity”, Feigenbaum, Johnson, and Syverson, in FC07
u 1 2
3
4 5
d
Main theorem: Adversary can only determine the parts of a circuit it controls or is next to.
u 1 2
8 80
Anonymous Communication
● Sender anonymity: Adversary can’t determine the sender of a given message
● Receiver anonymity: Adversary can’t determine the receiver of a given message
● Unlinkability: Adversary can’t determine who talks to whom
9 81
Model ● Constructed with I/O automata
– Models asynchrony – Relies on abstract properties of cryptosystem
● Simplified onion-routing protocol – No key distribution – No circuit teardowns – No separate destinations – No streams – No stream cipher – Each user constructs a circuit to one destination – Circuit identifiers
11 82
Input/Ouput Automata ● States ● Actions
– Input, ouput, internal – Actions transition between states
● Every state has enabled actions ● Input actions are always enabled ● Alternating state/action sequence is an execution ● In fair executions actions enabled infinitely often
occur infinitely often ● In cryptographic executions no encrypted control
messages are sent before they are received unless the sender possesses the key
16
83
I/O Automata Model
● Automata – User – Server – Fully-connected network of FIFO Channels – Adversary replaces some servers with arbitrary automata
● Notation – U is the set of users – R is the set of routers – N = U ∪ R is the set of all agents – A ⊆ N is the adversary – K is the keyspace – l is the (fixed) circuit length – k(u,c,i) denotes the ith key used by user u on circuit c
17 84
User automaton
85
Server automaton
86
Anonymity Definition (configuration):
A configuration is a function U→Rl mapping each user to his circuit.
20 87
Anonymity
Definition (indistinguishability): Executions α and β are indistinguishable to adversary A when his actions in β are the same as in α after possibly applying the following:
ξ: A permutation on the keys not held by A. π: A permutation on the messages encrypted
by a key not held by A.
Definition (configuration): A configuration is a function U→Rl mapping each user to his circuit.
20 88
Anonymity Definition (anonymity):
User u performs action α anonymously in configuration C with respect to adversary A if, for every execution of C in which u performs α, there exists an execution that is indistinguishable to A in which u does not perform α.
21 89
Anonymity
Definition (unlinkability): User u is unlinkable to d in configuration C with respect to adversary A if, for every fair, cryptographic execution of C in which u talks to d, there exists a fair, cryptographic execution that is indistinguishable to A in which u does not talk to d.
Definition (anonymity): User u performs action α anonymously in configuration C with respect to adversary A if, for every execution of C in which u performs α, there exists an execution that is indistinguishable to A in which u does not perform α.
21 90
Theorem: Let C and D be configurations for which there exists a permutation ρ: U→U such that Ci(u) = Di(ρ(u)) if Ci(u) or Di(ρ(u)) is compromised or is adjacent to a compromised router. Then for every fair, cryptographic execution α of C there exists an indistinguishable, fair, cryptographic execution β of D. The converse also holds.
22 91
Main Theorem
u 1 2
3
4 5
d
Main theorem: Adversary can only determine the parts of a circuit it controls or is next to.
u 1 2
8 92
Unlinkability Corollary: A user is unlinkable to its destination when:
93
Unlinkability
2 3 u 4? 5?
The last router is unknown.
Corollary: A user is unlinkable to its destination when:
94
OR
Unlinkability
2 3 u 4? 5?
The last router is unknown.
1 2 4 The user is unknown and another unknown user has an unknown destination. 5
2? 5?
4?
Corollary: A user is unlinkable to its destination when:
95
OR
OR
1 2 4 The user is unknown and another unknown user has a different destination. 5 1 2
Unlinkability
2 3 u 4? 5?
The last router is unknown.
1 2 4 The user is unknown and another unknown user has an unknown destination. 5
2? 5?
4?
Corollary: A user is unlinkable to its destination when:
Probabilistic anonymity
● Possibilistic result is nice, but we would like to quantify the anonymity provided by a system
● And we want to use a black box model, like this
25 97
Black-box Abstraction
u d
v
w
e
f
98
Black-box Abstraction
u d
v
w
e
f
1. Users choose a destination
99
Black-box Abstraction
u d
v
w
e
f
1. Users choose a destination
2. Some inputs are observed
100
Black-box Abstraction
u d
v
w
e
f
1. Users choose a destination
2. Some inputs are observed
3. Some outputs are observed
101
Black-box Anonymity
u d
v
w
e
f
• The adversary can link observed inputs and outputs of the same user.
102
Black-box Anonymity
u d
v
w
e
f
• The adversary can link observed inputs and outputs of the same user.
• Any configuration consistent with these observations is indistinguishable to the adversary.
103
Black-box Anonymity
u d
v
w
e
f
• The adversary can link observed inputs and outputs of the same user.
• Any configuration consistent with these observations is indistinguishable to the adversary.
104
Black-box Anonymity
u d
v
w
e
f
• The adversary can link observed inputs and outputs of the same user.
• Any configuration consistent with these observations is indistinguishable to the adversary.
105
Probabilistic Black-box
u d
v
w
e
f
106
Probabilistic Black-box
u d
v
w
e
f
• Each user v selects a destination from distribution pv
pu
107
Probabilistic Black-box
u d
v
w
e
f
• Each user v selects a destination from distribution pv
• Inputs and outputs are observed independently with probability b
pu
108
Anonymity Analysis Results of Black Box ● “Probabilistic Analysis of Onion Routing in a Black-box Model” Feigenbaum,
Johnson and Syverson WPES07
● Can lower bound expected anonymity with standard approximation: b2 + (1-b2)pu
d
● Worst case for anonymity is when user acts exactly unlike or exactly like others
● Worst-case anonymity is typically as if √b routers compromised: b + (1-b)pu
d
● Anonymity in typical situations approaches lower bound
109
Formal analysis of onion routing ● [FJS07a] - Onion-routing I/O-automata model
- Possibilistic anonymity analysis ● [FJS07b] - Onion-routing abstract model
- Probabilistic anonymity analysis ● […] - How do we apply results in standard
cryptographic models? ● [CL05] - “Onion routing” formalized with Universal
Composability (UC) - No anonymity analysis
● [FJS12] – Onion-routing UC formalization - “Free” probabilistic anonymity analysis
● [BGKM12] - Onion routing formalized with UC - Our work will provide anonymity
110
Problem ● [FJS07a] - Onion-routing I/O-automata model
- Possibilistic anonymity analysis ● [FJS07b] - Onion-routing abstract model
- Probabilistic anonymity analysis ● […] - How do we apply results in standard
cryptographic models? ● [CL05] - “Onion routing” formalized with Universal
Composability (UC) - No anonymity analysis
● [FJS12] – Onion-routing UC formalization - “Free” probabilistic anonymity analysis
● [BGKM12] - Onion routing formalized with UC - Our work will provide anonymity
111
Problem ● [FJS07a] - Onion-routing I/O-automata model
- Possibilistic anonymity analysis ● [FJS07b] - Onion-routing abstract model
- Probabilistic anonymity analysis ● […] - How do we apply results in standard
cryptographic models? ● [CL05] - “Onion routing” formalized with Universal
Composability (UC) ● “A Formal Treatment of Onion Routing” Camenisch & Lysyanskaya, CRYPTO 05
- No anonymity analysis, not onion routing [FJS12] – Onion-routing UC formalization
- “Free” probabilistic anonymity analysis ● [BGKM12] - Onion routing formalized with UC
- Our work will provide anonymity 112
Problem ● [FJS07a] - Onion-routing I/O-automata model
- Possibilistic anonymity analysis ● [FJS07b] - Onion-routing abstract model
- Probabilistic anonymity analysis ● […] - How do we apply results in standard
cryptographic models? ● [CL05] - “Onion routing” formalized with Universal
Composability (UC) ● “A Formal Treatment of Onion Routing” Camenisch & Lysyanskaya, CRYPTO 05
- No anonymity analysis, not onion routing ● [FJS12] – Onion-routing UC formalization
- “Free” probabilistic anonymity analysis ● [BGKM12] - Onion routing formalized with UC
- Our work will provide anonymity 113
Onion-Routing UC Ideal Functionality
u with probability b ø with probability 1-b
x
y
Upon receiving destination d from user U
d with probability b ø with probability 1-b
Send (x,y) to the adversary.
FOR 114
● “Probabilistic Analysis of Onion Routing in a Black-box Model” Feigenbaum, Johnson and Syverson ACM TISSEC 2012
Black-box Model
● Ideal functionality FOR
● Environment assumptions – Each user gets a destination – Destination for user u chosen from distribution pu
● Adversary compromises a fraction b of routers before execution
115
UC Formalization
● Captures necessary properties of any crytographic implementation
● Easy to analyze resulting information leaks ● Functionality is a composable primitive ● Anonymity results are valid in probabilistic
version of I/O-automata model
116
Problem ● [FJS07a] - Onion-routing I/O-automata model
- Possibilistic anonymity analysis ● [FJS07b] - Onion-routing abstract model
- Probabilistic anonymity analysis ● […] - How do we apply results in standard
cryptographic models? ● [CL05] - “Onion routing” formalized with Universal
Composability (UC) ● “A Formal Treatment of Onion Routing” Camenisch & Lysyanskaya, CRYPTO 05
● [FJS12] – Onion-routing UC formalization - “Free” probabilistic anonymity analysis
● [BGKM12] - Onion routing formalized with UC - Our work will provide anonymity
117
Ideal Functionality modeling more of reality
● “Provably Secure and Practical Onion Routing” Backes, Goldberg, Kate, and Mohammadi, IEEE CSF12
● Functionality can actually send messages ● Also presented ideal functionality covering key
exchange, circuit building – Needs wrapper to hide irrelevant circuit-building options
● Shown to UC-emulate FOR
118
Course Outline ● Lecture 1: Basics and Formalization
• Usage examples, basic notions of traffic-secure communications, mixes and onion routers
• Onion routing design basics: circuit construction protocols, network discovery
• Formalization and analysis, possibilistic and probabilistic definitions of anonymity
● Lecture 2: Security for the real world • Simple demo of obtaining/using Tor • Security of obtain/using Tor • Adding network link awareness • Importance of modeling users • Importance of realistic and practical
• Adversary models Security definitions
119
Recommended