>> Jon Howell: Thank you all for coming. Today we have the
pleasure of having Bryan Ford here. He did his graduate work at
M.I.T. and is connected with Peter [indiscernible] out at MPI,
and makes his way out here to visit us this week and if you
didn't get a chance to visit him and after seeing this talk
you'll want to, we might be able to squeeze you into his schedule
today. We've got a few spaces. Or you can join us for lunch.
But we're going to find out about how he can help protect us from
the horrific security problems we're having currently in the
cloud.
>> Bryan Ford: Well, it's great to be here finally. I'm told
that this isn't really needed, and yeah. Good to see you all.
So yeah. As Jon mentioned, one of the projects that I've been
working on for the past few years is in anonymous communication,
and I'm going to give kind of a somewhat high level overview of
various aspects of this. I hope it won't be too high level and
fluffy. And feel to interrupt me and, you know cause me to drill
down into details that might be of interest, might have to, you
know, skip other parts of the talk based on time, but I'm totally
flexible in terms of kind of adapting to what you prefer.
So this is a joint work with a number of people, both at Yale and
UT Austin, Vitaly Shmatikov's group as well as Paul
[indiscernible]'s group, especially Aaron Johnson, at the Naval
Research Lab.
So what's the basic motivation? Imagine some mythical country
called Repressistan, where there's some kind of political
dissidents who want to talk and want to organize protests, and
one of these guys says let's protest tomorrow at 9:00 a.m. in the
square and some of his buddies say okay, I'm in, you know, and
they're all tweeting their organization stuff. But, of course,
you know, the Repressistani police don't really like to see this
happening and they say, okay, you know, who's actually running
shot here. Well, you know, there's too many protesters for us to
throw all of them in jail, you know so we just need to catch the
ringleader, right. So basically, what the problem here that the
Dissent is trying to attack is, immediately anyway, the strength
in numbers problem. How do we kind of get some kind of an
ability to communicate and get some assurance of anonymity in
that communication, some strength in numbers.
Now, there's a complementary problem that we call the
unobservability problem. How do you prevent the Repressistani
police from knowing you're communicating at all. That's not our
primary focus, but it's very complementary and I'm happy to talk
about that too.
So, of course, you know, as I'm sure you're aware, in actually
corresponds to real situations. We all saw the Arab Spring
developing and the kind of the central, the major role that
social media played in the organization of these protests and
major events. And we found in the aftermath, we found a number
of things, both, you know, not just how central a role these
plays, but also how, you know, once these repressive governments
did figure out, you know, this internet thing and how it works
and how they can monitor and control it, they started to really
push back and bloggers who weren't using anonymous communication
technologies started getting harassed and thrown in jail and
stuff.
So this is, you know, this is a significant thing for various
people around the world. But it's, you know, it doesn't matter
for us around here, right? You know, who would want to track us,
you know, and, you know, in Freeistan, right? Of course, you
know, nobody in particular. Only, say, advertisers if you ever
spend money, you know, they'd like to kind of figure out exactly
what you might be interested in. Websites, you know, vendors
who, you know, tend to like to change prices based on your habits
and, you know, if you're more seriously, if you're a domestic
abuse victim, a lot of people really need not to be tracked by
the creepy exes that like to stalk people online, and there's
even creepy exes coming out of well known agencies that we've
been hearing about.
So if you run a business, then it's been
then your competitors
might want to know when you're browsing their website and, you
know what you're doing. If you're in any kind of minority group,
there are probably extremists that, you know, might want to track
you, you know. So this probably isn't a problem for most of us.
But for many, it is. If you happen to be within three social
hops of anyone, the police, you know, your favorite police force
thinks is of interest, then, you know, you're probably in this
net.
>>:
[indiscernible].
>> Bryan Ford: Probably. Well, so I was at CCS and I was at
Jacob Applebaum's key note where he made the point that, you
know, he's almost certainly of interest and, thereby, anyone in
that room at that time is probably, you know, kind of within one
hop of that and so I'm afraid you all are, you know, no more than
two hops away from someone of interest. So sorry about that.
But then, you know, if you're, say, you know, if you're a police
officer, then, you know, you might need to do, you know,
investigation of, say, criminal activity and they probably don't
want to see your connection coming from FBI.gov or, you know,
whatever. So it's a real two way street. Lots of diverse
people.
>>:
Question?
>> Bryan Ford:
Yeah.
>>: So what's [indiscernible] about this slide is if you remove
the word online from the title, this slide just as it is.
>> Bryan Ford: Sure, sure, yeah. The only problem is I don't
know how to do anything about non online anonymity so, you know,
yeah. But absolutely fair enough, yeah. So how can we protect
ourselves online? Well, there's, you know, some very well known
weak defenses that actually tend to get used a lot, you know,
disable your cookies, clear your browser history, set the do not
track flag that basically says, hey, website, please, please
don't track me. Pretty please, promise, you know. And, you
know, hopefully they will if they're nice. You can
there's a
lot of commercial VPNs. This is a very common way that users get
around, say, the great firewall of China, for example, these
commercial VPN services. But, of course, they're all central
point of failure that that one proxy gets hacked or some sub
polluted, you're probably out of luck.
And so this is what motivated more serious decentralized
anonymity systems, such as Tor, which it NSA calls it the king of
anonymity so
and I believe that, you know, that's probably
true. It's the current state of the art in actual deployed,
usable systems, and basically the idea, you know, if you're not
highly familiar with it already is it creates a series of tunnels
through typically three different intermediate relays, encrypted
tunnels so each of these is an onion wrapper, basically, and it
and because one of the concentric tunnels ends at each of the
intermediate spots, the content flowing in to a given router is
differently encrypted from the content coming out of the router,
which hopefully makes it very hard to tell, you know, what
which packet going in corresponds to which packet coming out, at
least based on the content.
And so, you know, that's kind of the
just the super high level
summary. And we've gotten actually some good news recently, you
know, that the NSA hates Tor, for example. So the most powerful
agency in the world that wants to try to break Tor, you know,
doesn't seem able to break it, at least as of earlier last
summer. So that's good.
On the other hand, the bad news is Tor and onion routing, the
whole technique of onion routing are fairly well known in the
research community to have a variety of potential weaknesses, and
we're just not sure, you know, how low hanging these fruit are
for attackers and that's kind of still a big open issue. And I'm
actually going
I want to organize my talk not really around
the components or the architectural components of Dissent or of
our project, per se, but rather around these classes of attacks.
Now, this is kind of my own classification, but all of the big,
major, kind of unsolved classes of attacks against onion routing
systems, as I'm aware of, seem to fall into these categories as
far as I know. And if you have, you know, know of anything that
doesn't cleanly fall into one of those, I'd love to hear and
discuss.
>>: How do you [indiscernible] if you put something out there
that improves security, but it's still vulnerable, would you have
done more damage because people can get secure [indiscernible].
>> Bryan Ford: Well, that's absolutely a constant issue for this
whole space of tools, you know, and I talk about it with the Tor
project people all the time, and, for example, the fact that, you
know, for the first few years after they released Tor, they had a
big disclaimer, this is very experimental software. Might have a
lot of bugs, you know. Beware, you know. But then there was
these other projects that were coming out with basically
completely snake oil and saying this is unbreakable crypto, you
know, and it creates this kind of moral dilemma. Well, you know
if you put all these kind of, you know, if you, you know,
properly hedge and, you know, put all the disclaimers and be, you
know, completely honest, yeah, this is experimental stuff, you
know, that might be broken. Then, you know, people are very
likely to you know, flock to the really bad stuff, right, you
know. And so, you know, it creates, you know, this, you know, a
serious dilemma that. And I don't have a good answer to that
yet.
Now, Dissent, you know, the system that I'll be talking about is
not yet at the stage where it really can be used in the real
world. So we're not yet at the stage of having to make that you
know, those difficult choices, although we hope to be able to
deploy it in some form soon. But, you know, in general, it's
>>: [indiscernible] I think about it in general you think about
take decipher, for example, would you feel comfortable putting it
out there, the proper disclaimers?
>> Bryan Ford: Yeah, yeah. And we intend to so and I think, you
know, deploy kind of new untested technology, it's also good to
be able to deploy it in ways where, you know, where there's a lot
of kind of kicking the tires uses where, hopefully, nobody's life
is depending on it, you know, and
but, you know, we can kind
of still get a lot of people, you know, playing with it and
analyzing it and, you know, gradually harden it further. But
yeah, you know, it's definitely a big, big challenge.
Yeah. So yeah. So I'm basically going to organize the talk
around these classes of attacks. And if you look through the
research literature, there's a lot of examples of each of these,
like global traffic analysis, active attacks, and I'll get into
these briefly, denial of security attacks, intersection attacks,
software exploits, which actually got a lot of news recently.
And so basically, the goal of the Dissent project is to
it's
kind of a deliberate clean slate effort on anonymous
communication systems. So if we could just kind of completely
rethink how we build anonymous communication system to try to
offer quantifiable and measurable guarantees ideally provable
guarantees, how might we do that. And so that's kind of the goal
and most importantly to kind of not just kind of patch individual
issues, but try to architect the system to address whole classes
of attacks, all right.
And so, you know, to put a big disclaimer right at the front,
Dissent as a clean slate architecture currently certainly does
not and may never, you know, this approach may never actually be
a drop in replacement for onion routing. But I think the, kind
of the claim of, you know, partial success so far is that at this
point, Dissent has some answer, you know, some very incomplete,
imperfect, but some answer to all of these major classes of
attacks against onion routing systems. So I'm hoping it can be a
basis for a further really, you know, interesting area of work.
So how does Dissent design around these kinds of attacks in and
so that's what the rest of this talk is going to be about, and I
can
some of these will just be brief. I can gloss over, skip
around if appropriate for time or other reasons.
So to start with the first problem, traffic analysis. So I
assume a lot of you have at least heard of this, especially in
the context of the Snowden leaks. But kind of the high level
issue is, you know, even if you have every
even if everything
is properly end to end encrypted and the NSA or whoever your, you
know, adversary is not actually breaking the encryption, there's
still
you're still revealing a lot through, say, the packet
links and bursts of traffic that you're using to interact in a
system.
And so just as a standard example, basic scenario, suppose Alice
lives in Repressistan and she wants to use Tor, and all of her
three Tor relays are in the free world TM, and she's using an
onion routed connection to that to post on a blog server that
also happens to be in Repressistan.
Now, unfortunately, what she doesn't realize is the RepressCo
state ISP monitors, going into and out of the Repressistani
border, and they've gotten smart and figured out a way to
fingerprint the traffic going across their routers. And if they
can kind of develop this to a sufficient
to a sufficiently
scalable point, they can kind of put time stamp fingerprints on a
lot of this traffic and kind of match what goes in one side with
what comes out the other and figure out, you know that, aha,
Alice is talking to this blog server.
So now this is
this is in principle, we don't know that
anybody is really doing this right now, but there are plenty of
research results that kind of measure and provide proof of
concepts of how this kind of fingerprinting works. And like in
this particular example,
showed that, say, out of
easily fingerprint with,
you know, what a user is
websites a user is going
and stuff.
from a few years ago, some other people
the top 2,000 websites, you can fairly
like, 80 percent accuracy exactly what,
going to, you know, which of those
through just by the SSL traffic patterns
So now, you know, are there actually attackers doing this? Not
that I'm aware of yet, and the Snowden slides seem to indicate
that even the NSA is still having kind of trouble with this. On
the other hand, it looks like it's very actively in progress. So
this one slide has something about, you know, goes into, go
outta, you know, which it's anybody's interpretation, but this
sounds a little like traffic analysis to me. And the more
concerning part is it says GCHQ has a working version now. I
don't know what exactly they have a working version of, but it
sounds like it's in a similar space.
So I expect, you know, somebody's going to do this before too
long if they haven't already. From the research world, just in
this past CCS, our colleagues from the NRL produced some very
really interesting simulation based studies trying to be kind of
the
provide the most realistic possible simulations of what ap
attacker might be able to do if an attacker owns, say, an
one
or more entire big ASs or one or more, you know, appropriately
placed IXPs. And so they see a lot of traffic going in and out.
And the upshot is, you know, if
it really depends on how
unlucky
lucky or unlucky you are as a user, how well or poorly
you're placed. If you're
if you're fairly lucky user, then,
you know, you might actually hold out for quite a while before
you get deanonymized. But if you're poorly placed, then the
attacker might deanonymize you very quickly in this fashion.
So how can we build systems that actually resist this kind of
traffic analysis? Now, as far as I'm aware, there are basically
two general approaches. One is basically to keep the onion
routing paradigm but pad traffic to more uniform rate. This
works to come degree. I'm not going to talk about it in great
detail, and they're continuing work, for example in the last
Sigcomm. And it does work against passive attacks, it seems
like, but it often fails against more active attacks.
So but like I said, since Dissent is exploring a clean slate
approach, we decided to take a very different approach using the
alternative dining cryptographers approach to anonymity, David
Chaum also invented along with [indiscernible] back in the '80s
but hasn't really been used in practical anonymity systems other
than Gun Sirer's Herbivore system back a number of years ago.
>>:
Can you [indiscernible] why is that [indiscernible] attacks?
>> Bryan Ford: I'll actually get into that in just a minute, in
the next section. So yeah, that's a good question. Yeah. Yeah,
so just to give you very brief high level overview, how if you're
not familiar with the dining cryptographers problem, assume one
of these people, say in this case, Alice, actually has a one bit
secret that she wants to share, and but they all
the group
wants to collaborate to allow an anonymous
any of their
members to share this one bit message anonymously without
revealing who
which of the members of that group sent it.
So in this case, each
so the standard illustration is these
are three cryptographers sitting around a table, and they flip a
coin. They each pair of cryptographers flip a coin beneath the
edge of the table where only that pair and not the third one can
see the result of the coin toss, and each cryptographer looks at
the coin to his left and his right and XORs their value together,
except in the case of Alice, she XORs both of her coins and her
secret and they all write this XORed result on the napkin on the
table. And so then they look at all the napkins and XOR those
values together and all the coins basically cancel out because
each continue got XORed into exactly two napkins, and that leaves
exactly the secret value, but provably reveals no information
about who actually put that secret value in there.
So this has been
this approach has been attractive for a long
time because it has this provable security even against traffic
analysis. So, you know, the NSA
an adversary can see
everything that goes on on the network, in principle, other than
the individual coins and is still protected. But it has a lot of
practical issues. Yeah.
>>: That works only if Alice does the XOR. If more than one
does, [indiscernible] the XOR of what everyone selected and the
synchronization problem is exactly what you're trying to hide.
So I don't understand this at all.
>>: It's provably secure is the wrong term here. It's provably
confidential, but your availability just disappeared because if
two people tried to transmit it at the same time.
>> Bryan Ford:
>>
Yes, yes.
That's the disruption problem, and I
[indiscernible] availability for confidentiality.
>> Bryan Ford: That one of the big problems which I'm just about
to get to. Yes, indeed. Yeah, sorry.
>>:
[indiscernible].
>>:
Again, this is why the word secure is always interesting.
>> Bryan Ford:
>>:
Yes.
It's provable confidentiality.
>> Bryan Ford: Yeah. So provable, you know, yeah. Yes.
Anonymity against traffic analysis, I should have said, yeah.
And, you know, that should be qualified too if there are
colluding parties in there. You're only anonymous among the non
colluding, you know, honest parties. You know, so there's some
caveats. But in general, there's this big classic problem. Why
DC nets hasn't really been practical for at least three reasons.
One is just when you actually scale this up to large groups, the
natural way to get maximal anonymity is, you know, you actually
need to kind of any to any, all to all, you know coin flipping
relationships, not just kind of around the table because if you
just kind of use a ring of coins around the table, then if, say,
an attacker is immediately to your left and your right, they can
isolate and deanonymize you and stuff.
So there's the kind of end by end cost. Kind of more related to
what I think you were referring to, if any participant actually
disappears at the wrong time, you know, and doesn't produce their
napkin, then everything is useless and you kind of have to start
over. And even more seriously, if anybody doesn't want you to
communicate, they can just jam the whole system with random bits
all the time and the system is useless. And so this has been a
kind of a
one of the major technical challenges with DC nets
for a long time. In Dissent, so in our OSDI 2012 paper on
Dissent, we really address the scaleability issue.
And we did this by adopting a quasi, cloud like client multi
server model where we assume we have a set of independently run
servers, which may be cloud servers or something, and the clients
each of clients shares a coin with each of the servers, but not
directly with other clients. And kind of the upshot of the
anonymity property it provides is that as long as at least one of
those servers is not compromised, all of the others can be
compromised, but as long as least one is honest and not colluding
with the others, then that creates an ounce coin sharing graph
with all of the honest clients. In this case, the blue ones, and
you still kind of get the ideal provable anonymity set in that
context among the honest clients. Now, and this is actually a
way to make it scale, at least a lot better than it did before.
And we were able to demonstrate it up to, like, 5,000 virtual
clients on 300
the 320 physical test bed nodes we had and
basically we ran into test bed limitations before the system
stopped scaling.
>>:
[inaudible].
>> Bryan Ford: So this was 16 servers, as I recall. Either 8 or
16. And actually we found that this is elsewhere in the paper,
but we, having more servers actually, you know, made it scale
better in that at some point, the servers become a bottleneck as
you would expect and
yeah.
>>: [indiscernible] as to why you need the protocol if you have
an honest server?
>> Bryan Ford: So actually, one thing I should have been clearer
about, we assume
the trust model is that we assume there
exists an honest server among this set, but we don't assume that
anybody, any of the clients or anybody knows which that honest
server is. So the honest
the clients don't have to
don't
have to choose a particular server to say I trusted that server
is honest. The clients just say, okay, I trust that someone
there exists someone in this set of servers that I, you know,
that, you know, I believe is not out to get me, right. Does that
answer your question, or did I
>>
[indiscernible] with multiple servers?
>> Bryan Ford: So another thing I didn't really get into, I
guess, in enough depth is the
these coin sharing, the clients
are sharing secrets with each of the servers. But they don't
actually have to physically communicate directly with each of the
servers. In the actual physical communication protocol, in fact,
each client typically only communicates with one upstream server.
But it doesn't have to trust that upstream server. That one
upstream server that it's communicating directly with can't
deanonymize the client. Of course, it can DOS the client. It
can say, okay, I'm not going to serve you, but then the client
can go to a different server. That's easily detectable, right.
But, you know, even if the client's upstream service
server is
kind of silently malicious, it can't deanonymize the client by
itself.
>>: Is it hard to get [indiscernible] do you have a sense for
how many servers you would need [indiscernible].
>> Bryan Ford: Well, so yeah. So unfortunately, it's really,
really hard, you know, for a lot of reasons to compare Dissent
configurations against Tor. For one thing because they really
provide fundamentally different communication abstractions.
Dissent is providing a multi cast, you know, ethernet like multi
cast channel, you know. Whereas Tor is providing a big bundle of
point to point channels. And if you look at kind of how Dissent
scales, you know, compared to other multi cast communication
systems, it becomes easier to kind of compare scaleability and
reliability and performance.
At the moment, I really don't have a good way to compare, you
know, a Dissent configuration against a Tor configuration kind of
that I would really call apples to apples, you know.
>>:
[indiscernible].
>> Bryan Ford: So we can
one way we can use Dissent is as an
anonymous communication proxy, in which case one of the servers
ends up acting as an exit node, and that can be just a well
established one or all of them ka do that. So Dissent is more
kind of at the foundation is more of anonymity primitive that we
can kind of build a number of applications on and other
you
know, other applications you might like, you know, anonymous
chat, you might just have the chat room, the state just among the
servers and there's no need for an exit, you know, role.
>>: Are you trying to hide the fact that someone's using
Dissent?
>> Bryan Ford: So that gets back to this other unobservability
challenge, and the Dissent project isn't
currently isn't
primarily focused on that. At least our part at Yale isn't
primarily focused on that. The other hand, it's trying hard to
be compatible with that and to play well with some of the efforts
in that space to build unobservability protocols. And those
basically fit in as access, you know, as ways to get to Dissent
without, you know, the bad guy figuring out that you're going to
dissent. So that's synergistic. I think you were
>>: So my original confusion still stands. I understand how,
given this, that unless all of the servers are compromised you
can't tell whether a [indiscernible]. That's pretty easy to see
[indiscernible]. What I don't understand is that if you have
more than one client that might be flipping the bit, then in the
output of the whole system, you still on the get one bit out of
the system.
>> Bryan Ford:
>>:
Right.
So what you get is an XOR of all of the
>> Bryan Ford: Yeah so this is the
alluding to two problems. Jamming.
might maliciously
>>:
so this is
you're
So, you know, two clients
[indiscernible].
>> Bryan Ford: But you might be referring to scheduling as well.
So for this system to work well, basically, there has to be an
arrangement such that only one client, you know, is supposed to
transmit it at any given time slot. It's ethernet like.
>>: Doesn't that [indiscernible] the whole point of the system.
Because now I know both
I know which client is supposed to
transmit it and then I know the output of the system, I know that
that client transmitted that bid and the whole thing collapses.
>> Bryan Ford:
>>:
No, no.
Obviously, you thought of this.
>> Bryan Ford: Yeah, yeah, so this is actually in kind of
further down in some of the details that I
I will actually
allude to them briefly later on, but I don't really have that in
my talk. Basically what Dissent does is it uses a verifiable
shuffle as a setup phase. So before all of this DC net stuff is
happening, you have a bunch of clients that come online. They
all kind of register, say hey I'm online, I want to participate,
and then it runs this other, you know, cryptographic primitive
known as a verifiable shuffle among all of the servers. Each of
the clients kind of submits something like a ballot. These are
algorithms developed for voting systems. They deposit one of the
you know, a ballot, a constant sized blob into this verifiable
shuffle. The servers all collectively and verifiably shuffle
them into a random permutation, and those come out the end and
through that shuffle, each client basically gets a pseudonym. So
it injects a public key. Each client gets to put one public key
into the shuffle, one reencrypted, randomized public key comes
out, and that gets used as a schedule and so basically, the way
you can think of it is kind of in the first end bit time slot,
whichever client owns the first public key that came out of the
shuffle gets to transmit. And in the next time slot, you know,
the owner of the next public key, whoever that is, comes out.
And everybody knows what this schedule is, and everybody can
identify their own public key, their own kind of pseudonym key,
but any don't know who else owns which other key because the
shuffle anonymizes.
>>:
[indiscernible].
>> Bryan Ford: Yeah, yeah, so that actually
yeah, I have more
detail on that, you know, in other versions of this talk. But I
kind of
yeah.
>>:
[indiscernible].
>> Bryan Ford:
Yeah.
>>: So you said if you had more servers, then would the system
scale better?
>> Bryan Ford:
I mean to a point, you know.
>>: The down side on having more servers is that each connection
takes longer, or
>> Bryan Ford: So we haven't done a lot of
we haven't pushed
the kind of server side scaleability and really kind of tested
the boundaries in that space yet. So but there are some kind of
ultimately non scalable interactions at the server side, you
know, if we really scale up the number of servers a lot that for
one thing puts more load on the clients because the clients have
to compute more, basically more pairwise shared secrets and
stuff. But also, the servers have some, you know, all to all
communication among the servers and that's going to start not
scaling at the server side if we, you know, in the current
protocol.
Now, there's perfectly reasonable ways to make this multi level,
you know, and, you know, I'm pretty sure we could kind of build
multi level hierarchies and use that to scale it a lot further
but we just haven't gotten there yet. Yeah, so I'm probably kind
of going a little too slow here so I should probably kind of skip
through some of this. Maybe I'll just briefly
sorry, briefly
touch on the active attacks since it already came up and skip a
couple of the others and then look at the exploits. Yeah, let's
see.
So another major class of attacks that isn't so easy to deal
with, with padding, is called active attacks. One of many
examples is known as a congestion attack, where, for example,
let's say, I'm an attacker and I want to see who this particular
victim is talking with. And I just hypothesize, well, let's pick
an arbitrary relay. I want to test whether his connection goes
through that relay. So I just hammer it with some kind of
traffic, kind of congest it, slow it down and make I own the
public server or I can see what comes out of that, and I see,
well, did his traffic coming out of that slow down or, you know,
this can operate from either end.
And there are some, you know, kind of proof of concept prototypes
of this kind of attack in the research world that lends some
evidence that it's realistic, and, you know, I don't want to
dwell in great detail on that, but really kind of get into how
Dissent's architecture trials to deal with this kind of attack.
And it basically does it by making the system more collective,
make decisions more collectively. And in particular, we have the
idea, so the anonymizer is, if we kind of consider that whole DC
nets blob to be an abstract box, we consider that the data plane,
but then we also have an abstract control plane which we consider
to be collective. A collectively
we call it the policy oracle
that decides kind of who does what at a given time.
But the policy oracle doesn't know, doesn't have privacy
sensitive information. It doesn't know which users own which
pseudonyms or which slots. And so what it boils down to is the
policy oracle is running a game of Simon Says. Did any of you
play Simon Says as a kid? Still remember it? So basically, the
policy oracle is saying I don't know who owns what, but Simon
Says everybody, the owner of pseudonyms one through five each
gets a one bit slot. And that one bit slot is just there so that
if you want to send something for real, you can set that one bit
and request a bigger slot later. And so, say, pseudonym three
says I have something to send. It sets its bit in the next round
the policy oracle says I see pseudonym three, whoever that is,
wants to send. Okay. I'm going to give pseudonym three a 1K
slot next round and everybody else doesn't get anything, right.
So, you know, and, you know, there's all kinds of policies and,
you know, policy issues to explore in this space. But just kind
of the high level point, the high level picture is to
of the
goal is to kind of collectivize the decisions and sanitize the
timing of things going through the system. So the classic, say,
congestion attack is to create some kind of recognizable delay
pattern on traffic going into an onion routing system. And an
onion routing system will preserve that, because these are
individual streams, right, that it's trying to add as little
delay as possible. But those get preserved and that's how you
get deanonymized, whereas when you have this, basically this
collective control plane that kind of running everything in
lockstep, this Simon Says game basically the stuff that's coming
out is coming out exactly when the control plane says to come out
and the control plane doesn't know who owns what. So he can't
release deanonymized users even if you wanted to. So, you know,
I know this is kind of very high level to drill down just a
little bit into how it
how we actually implement this,
basically, because the control plane doesn't know
doesn't have
any sensitive information, we can just replicate it freely. So
in the case of Dissent, we basically replicate the logic across
servers in kind of a, you know, logically peer view type fashion
so all of the servers kind of have to be in agreement on what the
next step is and what the next result of this logic is. So yeah.
So without kind of getting into further detail on that, I should
probably skip through the next stuff.
So denial of security is basically a powerful and interesting way
to take denial of service attacks and use that to deanonymize
users. And it applies to DC nets. To some versions of DC nets
as well as onion routing. Basically how Dissent deals with it is
by designing the protocol so that if somebody does try to disrupt
the DC nets, there's a way to figure out how they did that. And
we've actually come up with a number of different ways. It's a
kind of difficult technical challenge, kind of the most recent
one, the scalable Dissent provided one way, one kind of blame
mechanism to figure out who's disrupters after the fact. More
recently, at USENIX security, we explored a way using zero
knowledge proofs and elliptic curve cryptography for all of the
encryption and DC nets, and that kind of gives us a more
proactive way of preventing disruption in the first place. And
so there's some interesting trade offs there, as you might
expect. Yeah?
>>:
[indiscernible].
>> Bryan Ford: Sure, sure, yeah so let's see. The brief
the
very high level version of it, so is we
instead of in the
basic DC nets protocol, we use bits and we XOR them together.
You know, bits are the alphabet that an XOR is the combining
operation. We place the bits with elliptic curve group elements.
So, you know, items are encrypted in elliptic curve group
elements, and the combining operation is multiplication or, you
know. And then for each communication slot, coming out of that
shuffle, we know that there is a public private key pair that
defines which anonymous user is supposed to be able to transmit
in that slot. Now, all of the users with their ciphertexts,
their ECC encrypted ciphertexts provide a zero knowledge proof
that's basically an either/or proof that says either I know the
secret key. Kind of proof of knowledge. Either I know the
secret key corresponding tonight current transmission slot, and
that allows me to transmit anything I want in that slot, or I
don't know the secret key, but I have transmitted an encryption
of zero, of a null, you know, an identity element that's not
going to step on anybody who might actually know that key and be
trying to transmit. So that's kind of the basic idea is just an
application of either/or proof. Zero knowledge proofs.
>>:
[inaudible].
>> Bryan Ford: Yeah. So in this case, all of the servers check
all of the proofs and we have several ways that can shake out as
far as kind of how aggressively and proactively we check, and
that leads to different, you know, performance trade offs as
well, yeah. Yeah, and I'm happy to talk more about that offline.
But yeah. And so since I'm, you know, really running out of
time, I should probably kind of skip most of this. So the
intersection attack problem is another really big problem in
anonymous communications in systems in general, in that, for
example if Alice is even trying to post a blog server in the free
world, but these blog entries are time stamped and the RepressCo
state ISP can see which of its local users were actually online
at each of the times that Alice posted something, aha, well,
there's only one
all of thor users are coming and going, but
only Alice was in all of those sets corresponding to each of
those time stamps, right.
And so in general, this is a very, very difficult attack that I
don't know any anonymity systems, including Dissent, that have a,
you know, a totally bulletproof answer to this. What Dissent
does is at a high level is basically first of all tries to give
users a useful metrics as to kind of what their vulnerability is,
and it uses this kind of policy oracle logic to simulate
adversary's eye view. You know, if the adversary can see all
these IP addresses coming online and going offline, what might
the adversary be computing from this, and it simulates the
adversary and uses that to give the user a set of anonymity
metrics. And we have a couple that kind of represent different
things. One is we call possinymity. It's a possibilistic
anonymity set size meaning, you know, what is the set of users
that could possibly have posted the messages that came out on
your pseudonym, you know.
And that's different from indinymity, which is a probabilistic
anonymity, which is what does the set of users who's kind of
intersection attack relevant kind of behavioral footprint is
completely indistinguishable from yours. And that's kind of a
much higher standard. You're going to get smaller numbers but
kind of better, kind of better guarantees. And so, you know, I
probably need to skip over. But basically, this was work we just
presented at CCS on kind of first cut approach to providing some
level of intersection attack resistance. And when we did some
analysis based on just IRC data sets to get a sense for kind of
how realistically can you get, you know, some level of anonymity
over some particular time, and that, of course, as you might
expect depends on how long you want to use a given pseudonym
before you refresh it and, you know, start clean or something
like that. And it also depends a lot on user behavior so, you
know, there's a lot of interesting issues in there.
>>:
[indiscernible].
>> Bryan Ford: Yeah, sorry, sorry. So this is basically showing
based on
yeah, I probably have to give this as context. So
this is a
represents an IRC trace of a big active football IRC
group. And basically, there's some subset of users that tend to
be on all the time, and a lot of, you know, a lot of the others
are on very intermittently. It's hard to get long term
intersection attack resistance anonymity sets with those kinds of
users, but we can get them out of those kinds of users,
basically.
And kind of analyzing what kind of anonymity you can get in those
kind of contexts, you know, it depends fundamentally on how long
you want to keep using a pseudonym. Like if you're just trying
to say go grab a web page, maybe you only need a pseudonym for a
minute, you know, for a brief TCP session, then let's see. I'm
yeah, yeah, I actually misremember
yes. This is actually
hm. Yeah. I misremembered which graph was this. So this
so
this is actually
there's actually two important factors. One
is how long you need to keep the pseudonym. The other is how
responsive you want that pseudonym to be. And the X axis here is
basically kind of the round time, meaning how often each round
completes. And so if you need a highly interactive session, you
need to be kind of down here. You know. If you're doing a kind
of Tor like use, you're trying to do interactive communication,
you need small communication round times. Whereas if you're in
kind of a micro blogging, say, or you just want to post a blog
entry once a day, you can have much, much larger round times and
Dissent can kind of aggregate the anonymity set
aggregate all
of the users that show up at any point in the day into one
anonymity set and then you can kind of be over here.
And the Y axis is basically kind of an estimate of how much
how big anonymity set you can expect to get over a long period of
time. In this case, the whole month of the trace. And so the
point was if you need really interactive communication, well
turns out unfortunately there's only like ten users that were
really online all the time that can't be intersected out of your
set the whole time and so it's really hard to get, you know, long
term, you know, anonymity with, you know, with high
responsiveness just because of, you know, user churn. Whereas if
you're willing to tolerate some delay, well, you can, you know,
get up to kind of a hundred member longish term anonymity set.
That still, you know, might not be what you really want.
So, you know, in a sense, this was just trying to kind of
illustrate it's kind of a hard problem in the long term and we
don't have good answers for that yet. It might ultimately depend
on, you know, can we build systems that encourage users to
interact in the right way to kind of be online in an
indistinguishable sense for long periods of time. So there's a
lot of interesting issues in that space.
So yeah. And so, yeah, I'm really out of time. But yeah, so the
last general attack category, which got a lot of attention
recently is basically software exploits. You know, the best
anonymity system, you know, even if it's perfect here, is still
vulnerable if, say, the website is malicious and it sends you a
browser exploit that attacks your browser instead of the
anonymity system and the browser is no ordinary process that goes
and the exploit goes and looks up its IP address and send it to,
you know, some arbitrary party. And this is one of the things
that happened over the summer to Tor.
And so this software exploits basically appear to be the low
hanging fruit that's actually getting used. And, of course, this
is, you know some what solutions to this are somewhat orthogonal,
you know, browser
to anonymous communication protocols, but
we're trying to do something about this too, and this was under
development since at least a year ago but it partly addresses
some of these recently revealed issues. And basically, the idea
is we package up the browser and all the plug ins that you might
want to use into a sand box of some kind, and you put the
anonymizing system outside of it so the only way that that
browser environment can actually get out is through the anonymity
system. It doesn't even know its true IP address or true Mac
address or anything. So even if it gets exploited, you know,
hopefully, you know, unless the bad guy can also escape the VM,
you know, you have a little bit better protection.
Now, this is, again, very ongoing work. I'll skip this. But and
we can actually do either Dissent or Tor or Dissent plus Tor in
this kind of complementary environment.
So yeah.
So
um hmm.
>>: So just to clarify, so the solution is basically, if I
understand correctly, to take the browser and the UI
[indiscernible] is that
>> Bryan Ford: Yes, exactly. So this is kind of a, in some
sense, a very conventional isolation sand boxing based approach
just, you know, applied to this problem. Yeah. And, of course,
as you know well, it has its strengths and weaknesses. So, you
know, where is Dissent? So, you know, it's a proof of concept.
It works for some things. But it's very preliminary. It's not
really ready for real deployment, but there's a lot of further
scaleability and other questions. But kind of the upshot is
you know, the high level take home point, I think, getting back
to your original idea, you know, is the question is is there any
way we can design anonymity systems that could eventually be
truly resistant to all of these many classes of serious attacks.
And although, you know, Dissent is still a lot
a long ways
away from kind of proving to actually providing that, it's at
least kind of through the ground up effort, I think we find
we're finding some really interesting ways forward in that space.
Yeah. And thanks, and sorry for going long and I'm happy to take
questions or further discussion, however you want to do it.
>>: A lot of these five classes, Tor's been out there for a long
time and it's been a large target, always [indiscernible].
>> Bryan Ford:
Yeah.
Yep.
>>: So is Dissent or do you have some
so Dissent clearly has
different properties from Tor. Do you think there's going to be
eventually a session on attacks on Dissent or
>> Bryan Ford: I hope so if we can kind of get it to a really
deployable and deployed level, then, you know, and can kind of
build a user base, you know, I would, you know, certainly hope
for that to happen.
>>:
[indiscernible] or are you pretty sure that [indiscernible].
>> Bryan Ford: Well, so I'm sure there
on the one hand, you
know, if Dissent were to become kind of popular, you know, and,
you know, comparable to Tor, I'm sure we would see a similar
stream of attack papers and I would want to see that. I feel
like I have some confidence that more of those papers would be
about kind of details, kind of patch like either particular
security bugs, where a patch is clear, and many of the Tor attack
papers are of that form, you know. Many of
a high percentage
of the Tor attack papers, you look through them and for each one,
oh, yeah, you just need to fix Tor that way and that way and that
way, and yeah, it's no kind of fundamental thing, whereas what
these five bullet points are kind of trying to bring out is the
area, the whole large areas where the whole onion routing model
just doesn't have an answer to the
to major broad classes of
attacks. And I have some confidence based on the fact that, you
know, Dissent is built on algorithms that actually have provable
properties and we actually have a number of team members working
on formal verification of these properties, I'm pretty sure
those, you know, those attacks will be more either bugs or places
where the assumptions, you know, the assumptions of the kind of
provable model fail to match the real world. And that's going to
be a big issue in any practical anonymity system too. Well, you
know, it said it's providing, you know, measurable, quantifiable
anonymity sets. But oops, the attacker found a way to stack your
anonymity set with malicious nodes because there's some symbol of
vulnerability in the way that nodes get into the system, you
know. There's that whole huge space and, you know, there's no
perfect answer, you know. There's going to be a lot of issues
like that.
>>: So I have a question about Tor and about these attacks in
general. So I understand the research community actually started
formulating attacks against Tor. Has there been any evidence
that sort of the bad guys, the Repressistans of the world have
used sort of these type of [indiscernible] system attacks where
introduce, you know, malicious nodes or you have [indiscernible]
attacks or things like that?
>> Bryan Ford: So we do have at least there's at least anecdotal
evidence of Repressistans running a few Tor nodes, for example.
Most of it's anecdotal. We're not really sure, you know, whether
it's truly the government or just some, you know, hacker Army,
you know. A lot of that is kind of anecdotal. We're not really
sure. There is also a lot of strong, you know, very clear
evidence of, you know, Repressistan's trying to, just kind of
trying to deanonymize and use whatever tools they can to track
their users and break in to and, you know, monitor them in
general such as this Iran's repeated hacking attacks against
certificate authorities to get CA private keys and men in the
middle, all these SSL connections and stuff.
>>: The question is about [indiscernible]. Who can attack
[indiscernible] systems attacks that have this nature of
attacking by introducing malicious nodes or Tor [indiscernible]
and then there is the sort of software attacks where you go after
certificates or [indiscernible] machine. I'm sort of trying to
my question is about the former class, because the second class I
can see how
>> Bryan Ford:
>>:
The former was
Was systems where you break the, sort of the algorithms.
>> Bryan Ford:
>>:
Yeah, yeah.
Then the keys or malware or
>> Bryan Ford: Right, yeah. So I don't
so I don't know of
I think, you know, most of the low hanging fruit for the
attackers at the moment is either in the software exploit space
or the, say, CA vulnerable, kind of the, you know, masquerading
as somebody else. Breaking the identity space. And not so much
in the kind of direct attacks on the distributed systems. So
>>: I mean, obviously, it's hard to know [indiscernible] I think
that the, what we know with certainty, because we actually have
the traces, we can actually see it happening is that countries
like China, Iran and Libya in the old days, et cetera, they have
launched numerous attacks to just completely block all possible
access to Tor and they've done a lot of work to fingerprint
connections to tell if this is a Tor connection or not and we've
actually seen and tracked and those are very well known attacks.
>> Bryan Ford: Yeah, so they're trying very aggressively, for
example to root out all the Tor bridges. So I didn't get into
the Tor architecture, but it also
besides the well known onion
routers, there's this layer of bridges that provide entries to
the Tor network that are
try to provide some blocking
resistance. But, you know, China tries really hard to kind of
sniff out is that node a Tor bridge? Let's try talking Tor with
it to see, you know, and, you know, I mean, so it's
those
kinds of concerted attacks very much exist. But yeah. But I
don't know of kind of really
>>: We definitely know, for example
I mean, it turned out to
be a [indiscernible] attack. It was done as a [indiscernible]
concept but that was launched where essentially attackers put in
their own nodes and they just intercepted a bunch of traffic and
it turns out lots of people weren't, for example, using SSL over
Tors, even though the Tor traffic was secure, the event traffic
wasn't and they used this to collect passwords and all sorts of
other information. And that was launched and successfully done.
But that was done by someone trying to prove a point that you
could do this.
>> Bryan Ford:
Yes.
>> Jon Howell: Okay. If you would like to chat more with Bryan,
we have a spot at 2:00 and a spot at 5:00. You can talk to me
afterward. But let's thank him again for speaking.