18771
>>: Good morning, everyone. It's my great pleasure to welcome Tom Ristenpart.
Tom is a Ph.D. candidate from UCSD. And his advisor is Mihir Bellare, a very
famous cartographer. And he also collaborated extensively with Stefan Savage,
Tadayashi Kohno and all those folks that we are very familiar with.
So, Tom is interviewing drum lay with the Security and Privacy Research Group
and the Crypto Research Group. He's intervening for bold researchers in postDoc positions. And Tom is going to talk about his dissertation work, how he has
improved the interface between systems and cryptography.
>> Thomas Ristenpart: Thank you very much for that kind introduction. So it's
great to be up here in Redmond, talk about my work in computer security.
And so the background, of course, for working computer security is that it's
incredibly hard to get our complex computing technologies of today to be secure
in the face of malicious users.
And, of course, the -- you know, the consequence of having security, as we all
know, can be quite drastic, whether it's criminals breaking into corporate or other
organizations, data centers and making off with data on hundreds of millions
credit card accounts or growing privacy concerning the fact we are carrying smart
phones with us all over the place and these are notifying third parties of our
locations. Or even some resent work highlights knew technology, in this case,
cloud computing can really give rise to interesting new threats that we really need
to consider.
And so, to handle all of these, you know, to help us in building more secure
systems, we really like to have powerful tools. And one such is cryptography.
This allows, for example, encrypting a message that can be sent securely and
privately over an insecure public network.
And the reason that cryptography is so powerful is not necessarily what we set
out to do so much as how we verify that we've accomplished our goal.
And here, what cryptographers do is make use of a framework known as
approval security. So the idea is that a cryptographer sits down and decides
precisely and mathematically the algorithms involved and what the tools are
supposed to be accomplishing and quantifying the adversarial resources that
they expect attackers to have, whether this be running time or access to their
information.
And then, now, relative to this abstract model what a cartographer does is give
approved security in MP complete style reduction showing that any attacker who
can break a cryptographic scheme, well this implies the ability to break some
underlying, simpler primitive. And what this reduction does is actually gives a
very strong guarantee of security if we make a judicious choice of our underlying
primitive. For example, basing it on factoring large composite numbers or some
very thoroughly studied primitive such as the AES block cypher.
So then we go to a very strong validation tool. We can use proofs to understand
that attackers, at least if they are working within this abstract model that we've
designed, really have very little chance of breaking the cryptographic
mechanisms.
So what's the catch? Well the problem is really in the handoff, right? Because
on one hand, we have systems with real implementations of cryptographic
protocols and real threats. And on the other hand, we have cryptographers using
abstract models to design and verify their algorithms. And so the problem is if
there's any mismatches between these two worlds, then these mismatches can
be found and exploited by attackers.
So to give back some of the examples on the first slide, right, we have problems
like breaking into databases, and here the cryptographic tools we have aren't
deployable due to Legacy constraints, so this leaves plaintext vulnerable.
Location privacy really isn't achievable by cryptography alone. Of course you
have other systems-related phenomenon like the fact we are using the internet
and this reveals our location already to third parties. And then there's more
subtle issues about using cryptography in new environments that were not
envisioned by designers and implicit security critical assumptions end up being
invalidated.
So, my work over the last bunch of years has really been about trying to tackle
these problems that occur at the intersection of cryptography and systems.
Understanding the types of a gaps between models and reality, how these types
of gaps can be exploited by attackers, and then, of course, trying to figure out
ways to improve the situation and fix the problems. And so, consequently, I've
taken a pretty broad view of research, working both on understanding threats, so
really this is just a nice way of saying -- finding attacks against systems that are
using cryptography.
Also, building systems, so starting from scratch to create a system that uses
cryptography in some broader system security context. And then also working
on improving the cryptographic theory and tools that we have in order to make
them more useful for practical situations.
So what I'm going to do in this talk is basically go over a bunch of different
projects at a pretty high level and relatively quickly. I'll talk about this issue of
encrypting credit card numbers in databases, problems related to the use of
randomness in cryptographic protocols. I'm looking at building a security system
in the complex of device tracking. And then I'll talk about my most recent work at
the end in the context of cloud computing and revealing knew threats there.
So I say, I'm going to be going over things relatively quickly and kind of high level.
I encourage you to jump up and ask questions or interrupt at any time. We can
make this quite interactive, it would be good.
Okay. So let me start off by talking about this -- this problem with credit card
numbers. And the fact is that we just have millions of databases out there that
are storing account information about people, and these databases, you know,
so they are storing names and also credit card numbers, for example, and the
fact is, if we wanted to encrypt these credit card numbers so that if an attacker
does succeed in breaking into a system, now you would only have access to
ciphertext as opposed to the plaintext credit card data. The fact is our existing
traditional cryptographic tools aren't going to help us with the job very well. And
this is for a relatively simple reason. Say we want to use something like AES, a
traditional block cipher. It's a map that uses a key to encrypt a client text of 128
bits to a cipher text of 128 bits. So if we use this to encrypt a credit card number.
Well, the result is that we get a ciphertext that is 128 bits. And there's no way to
encode 128 bits into a 16 decimal digit number. And so literally, the ciphertexter
can't fit back into the data base in lieu of where the plaintext was.
>>: How about a stream cipher?
>> Thomas Ristenpart: You can use a stream cipher, but it won't give you much
security. So we'll talk about that in part in a minute.
So the problem is, so this is kind of a gap where our cryptographic tools, stream
ciphers, block ciphers, these things don't really solve the task at hand, and so in
practice, we don't end up using encryption in databases as much as we might
like. And so there is always that, when criminals break into companies like T.J.
Max or credit card processing systems like Heartland Payment Systems, they
ended up make off with quite a bit of data. So we'd like to fix this situation.
>>: So this is a particular database scheme? Somehow it's used by all of these
people.
>> Thomas Ristenpart: Uh-huh.
>>: Is that just another [inaudible].
>> Thomas Ristenpart: Excuse me. This is just an example. But the point is
that there's a lot of software in database systems that are built around the idea
that you have a 16 or 18 digit credit card number and to use the existing
cryptographic mechanisms that are actually secure for this setting, then you
would have to redesign the database and the software around that cryptographic
mechanism because you can't just replace and place the credit card number with
a ciphertext and so the -- yeah?
>>: This assumes that the method of entry would be stealing this data can be
solved with encryption if the vast majority is on the [inaudible] sharing or trust or
bribes, then encryption is no more -- it is no better than no encryption at all, true?
>> Thomas Ristenpart: That's, you know, partly true. The point is that we would
like to use encryption in this setting to narrow and limit the focus of what we need
to protect, right? So your moving from having to protect the database from
multiple copies of a database in various places on various systems to having to
protect the cryptographic key, right?
>>: Example of stolen identify solved?
>> Thomas Ristenpart: Yes. That's the idea. And I'll talk about that. It happens
-- to a certain extent. We'll talk about details later, in a minute.
So the suggestion actually for ->>: Can you explain why the extreme [inaudible] wouldn't have been secure?
>> Thomas Ristenpart: The problem is if you use a stream cipher, right, you
have to -- you're going to encrypt with like a pad, basically, right? And so if you
use the same pad for multiple plaintext.
>>: So [inaudible] with the user.
>> Thomas Ristenpart: So where do you store the salts, right, is the question?
>>: The salt is, you've got other information in those fields. Why not use the salts?
>> Thomas Ristenpart: Well, the question becomes, then you have to ensure
that all the information is unique in every single field in the database. And so this
becomes a usability issue for the ->>: [inaudible] presumably one of the things you can solve with, correct?
>> Thomas Ristenpart: Right. So ->>: I mean it's almost any database is going to have a unique ID so that ->> Thomas Ristenpart: Yeah, so this is -- these are all great questions, and I
think the fact is, I don't know all of the details about the deployment requirements
in the settings. But when we talked to people in industry who are deploying or
wanting to deploy credit card encryption mechanisms, they find that these --
there's too many constraints to use things like stream ciphers. And so what they
really want is a stand-alone solution that you're basically handed a credit card
number and under some particular key that's easy to start like in a hardware
security module, you get back the credit card number that you can then place
into the database.
And the way it's actually ended up being deployed is they actually taking credit
card numbers when they first enter a network, for example, and send it off to
HSM right away and get that credit card number even before it ends up landing in
a database. So this provides, like global security, no matter where the credit
card information ends up appearing, not just the database but throughout the
whole network.
Okay. So the solution that I've basically just kind of highlighted a little bit is this
idea that we want to have what's called format preserving encryption. And the
idea is that we want to have encryption mechanisms that can take, for example,
a credit card number and map it under a key now to a cipher text that is also a
valid credit card number. And this reply for this particular example in place
replacement of the plaintext with the cipher text, and the surrounding systems
that also use this credit card number now can just treat it, the cipher text as
before. So how can we build such a format reserving encryption scheme? Well,
we can of course use AES and just truncate the output, but this isn't going to
work, right? You've thrown away some of the values you need to decrypt the
cipher text.
Okay. We can also, of course, use something like electronic code book mode.
This actually does allow format preservation. And, for example, what this would
do is associate each plaintext digit encryption of it. So this key is the table now.
And so to encrypt a credit card number we replaced literally two with the seven,
and three with four, et cetera.
>>: And that would be the same as a salt to stream cipher product?
>> Thomas Ristenpart: Yes, this is the same as a salt to stream cipher problem,
right.
Yeah, so of course this isn't secure because as soon as you have one plaintext,
cipher text pair, you learn the code book.
>>: [inaudible].
[laughter.]
>> Thomas Ristenpart: Okay. I'm talking to too expert of an audience.
Noncryptographers love this example.
So anyway that is horrible idea from a security standpoint. It's the same as the
unsalted stream cipher.
>>: [inaudible.]
[laughter.]
>> Thomas Ristenpart: What's that?
>>: [inaudible] five.
>> Thomas Ristenpart: Well, I could go through lots of different attempts. We
can spend all day talking about bad ideas.
Okay, so, yeah, these things are bad straw mans, right?
So what we really want, okay, so we want a format encryption scheme for credit
card numbers. But then when we came and looked at this problem, we said why
are we restricting our attention to credit card numbers? We may also want to
encrypt, say, a valid postal address back to a cipher text that's also chosen from
the space of a valid postal addresses for some sub-set of all postal addresses, or
maybe we want to apply this to some formatted medical record and retrieve, get
a ciphertext back that is also a medical record. So what we said is actually
maybe we should actually try and target a more general tool, right? Providing an
encryption mechanism that actually can preserve membership in, say, any
arbitrary regular language. And this is actually the problem that we -- we set out
to solve and we did solve.
So, let me just tell you a bit at a high level about what we did. We provided the
first formal cryptographic, modern cryptographic treatment of the format
preserving encryption problem. This means defining what it means to have a
scheme, providing security notions, for example, resistance to messenger cover
attacks if we don't want people from a bunch of -- from a ciphertext be able to
recover the credit card number and other information. And then we provide
practical construction.
But doing this formalization actually us to take advantage of quite a bit of
cryptographic theory, and also and if your related to, for example, ranking of
regular languages.
And so just to give a flavor of what the proposed solution looks like, at least for
the specific case of credit card numbers, not for an arbitrary regular language,
but for credit cards, we end up using a modified variance of [indiscernible]
networks, so the idea is you take a 16-digit credit card, split it into two sides and
run the right half through AES, and now you have 128-bit value that you can
encode as number and you add this mod ten to the eighth with the left-hand side
and you get the right half output, and you just drop down the right-hand side to
the left-hand side. So the point is this round is invertible so we can go backward
through this. And then we can do many rounds of this to achieve security and
provable security, so that we can show that for any arbitrary A, for example,
that's trying to break our scheme in terms of, say, message recovery, well, then,
this is actually going to imply the ability to break AES in some nontrivial way.
And so the conch positive gives us a nice guarantee of security that the format
serving encryption scheme is as secure as AES. And this means that we haven't
introduced any problems in the development of the FP scheme.
>>: Are there any boundary cases or like odd length [inaudible] that you need to
encrypt?
>> Thomas Ristenpart: Right. So in the general case, right, you have to deal
with this underlying problem of encrypting on any arbitrary size finite set. So, for
example, if you have a prime ordered set, then this becomes problematic. So
there's a bunch of techniques that I didn't talk about to deal with this, but for that
particular case, you end up using a -- actually relatively old technique called
cycle walking. Actually it dates back to the 1910s or something in World War I.
That is you can iterate a cipher that works on a slightly larger domain to get back
into a prime workset with one that can be split evenly in half, for example.
>>: Do you have to know something about the distribution of plaintexts?
>> Thomas Ristenpart: Yes. Well, yes and no. See, the -- the definitions and
the scheme don't require any knowledge of the distribution of plaintext. Of
course, if there's only one plaintext and you get the missing inscription of that one
plaintext, you know that there is one plaintext. So in general, if there is a very
low entropy in terms of the plaintext size, and you see lots of examples, there
could be concern that you are learning information about partial information
about messages. But in these -- in these -- we still have a security wing here
because we are still encrypting it so you -- you would have to have access to an
encryption box to actually check to see. So say you have some relatively small
set of potential plaintext that you know occurred, you'd still need to do trial
encryptions with the box to actually check if the ciphertext matches the one you
have in hand. And so this can be handled by, for example, metering the number
of encryptions allowed, you know, per second or something. And, you know, it's
a concern, but it's ->>: They can steal the whole database. Can't you say oh, well, the one that
occurs most is California. The one that occurs next most, that's New York?
>> Thomas Ristenpart: Oh, I see what you're saying. Yeah. So in deployments
we, of course, suggest using salts as well, so these are actually tweakable
encryption schemes is what they call it technically. So what you can do is not
only include the message and encrypt the message and encrypt under key B, but
you can actually in some situations you can salt the other elements. And so that
is an important way to -- important help to deal with that type of variation issue,
uh-huh. But it's fundamental in this case that if you need determinous encryption
which is what we need here to achieve this Legacy compatibility that the industry
people are asking for, then you have this concern about small message spaces.
So, this work we were talking to people at various companies when we were
working on this, and the result is that there's a standard that's been proposed to
NIST based on this work, and, in fact, some of these companies are actually
already deploying this technology. So Heartland Payment Systems is one of the
companies saw that had problems before, and they are prototyping the system
based on FP, you know, from that voltage. So they actually do like this
functionality. Okay?
So, that was an example of a kind of mismatch between cryptography and
systems. There was a simple stay, we just didn't have the right type of tools to -Yeah?
>>: One thing before you move on, I'm not sure if this is the appropriate place for
it, but when you say this is the first modern attempt at this sort of thing, are you
intentionally dismissing Schroeppel's Hasty Pudding?
>> Thomas Ristenpart: Oh, yeah, yeah. So -- so -- well, he didn't formalize
format preserving encryption, right? He formalized having a bit-oriented cipher,
right? And he did it by hand. So the problem with Hasty Pudding is -- so it gives
you something that works on bit strings, bit strings of arbitrary size but not
something that works in arbitrary formats. And so there is an extra step to
actually ->>: [inaudible] work on arbitrary formats, but it was very cumbersome.
>> Thomas Ristenpart: That's may ->>: He described it as an ominous site for a decorative, encrypted any forum and
put it back in exactly that forum is just [inaudible.]
>> Thomas Ristenpart: So that's just -- he didn't talk about doing things like
encrypting regular languages I think at all. So he does -- it's a very flexible cipher,
it's true, and we cite the work extensively, of course. The -- you know, the
basically recognized problem with Hasty Pudding is no one looked at it in terms
of security, so no one knows if it's secure because it was designed by hand
whereas with these types of schemes, you can take advantage of the analysis of
AES that's, you know, been going on for the last ten years and is ongoing.
Okay. So let me move on to talk about a second problem which is the use of
randomization in cryptographic algorithms and how this causes problems in
practical settings. So just as a bit of background, you know, we have modern
public key encryption schemes is a good example that I'll keep coming back to.
This allows generating a public key secret key pair and, you know, distributing
the public key so others can encrypt messages so only the person with the secret
key can decrypt.
But the point is that many or the goal now for modern public key encryption
schemes is that they are randomized which is that -- which means that the
encryption mechanism not only takes the message in the public key, but also
takes a string of random bits or bits that are -- should be choosing uniformly at
random from the set of all such bid strings. And the reason for this is that it
provides a stronger security in some applications. So, for example, if we are
communicating between one party to another, and we -- and we have an
adversary that's seeing some of the ciphertext going by, and the adversary can't
even tell if the same message was encrypted twice, and so this can be important
in certain contexts.
So, in theory, of course, we can just assume that we have access to some
algorithm that samples this value R at random. But in practice, we have to
implement this somehow. And so what's done typically is using a random
number generator. So software-based random number generators, for example,
measure certain unpredictable events like keyboard presses from the user or
mouse movements. And then try to extract from these measurements a string R
that should be hopefully -- should be uniformly uniform at random from an
adversary's point of view.
But the problem is, of course, that there's been a long line of work showing that
random number generators are really hard to get right. So this ends up with
problems that are -- is exposed to attackers or repeated or even predictable in
the worst case. So there is this famous example, at least in this community it
should be pretty well-known about the dubbing open S cell mod where they
commented out a couple of lines of code in the source base, and these are the
lines of code they are actually responsible for adding measurements to the
random number generator. And so you ended up with a very small set of
possible R values that are predictable to an adversary's point of view.
>>: This is a problem not just with randomness in primitive calls, but keys are
generally from the same source, right?
>> Thomas Ristenpart: This is true. So -- so, yeah, of course, if you have keys
that are generated with bad random string, your host, I mean, I think there's
distinction here between -- and then one that is important here is that, you know,
between frequent and infrequent operations. So if you're generating a key, you
can only generate the public key secret key pair once for a long time, but then
every time you encrypt a new message you need knew randomness constantly.
And so it seems intrinsically more difficult. I mean, you need more randomness
to deal with the problem of generating randomness for message encryptioning
and you need it in a variety of context where you can at least, now in your case,
sit down with and generate the public key secret key pair once, and then
distribute the public key.
>>: You can. But you're all certainly using the same underlying random number
generator. So if it's got a small set of R ->> Thomas Ristenpart: Right.
>>: Then not only are your protocol randomness [inaudible] but so are your keys.
>> Thomas Ristenpart: Right, yeah. And there's something fundamental there
that we can't change crypto to make up for that problem, right? If you don't have
any randomness anywhere, well cryptography doesn't work.
>>: Doesn't work.
>> Thomas Ristenpart: Absolutely.
So what I'll -- to lead in a little bit, what I'll deal with is one of these two problems
which is dealing with the routine randomness. And if you have good keys, then
we'll show that you can do something quite a bit better than what's currently done
with a bad routine randomness.
I want to talk about another place from my recent work where randomness -random number generators kind of failed. This is the context of virtual machines.
And the idea is that security experts and companies are advertising the idea that
you should do browsing within a virtual machine. And so the idea is pretty
straightforward.
So, you set up a guest operating system and run, say, your Firefox or some other
application within it. And then you can take at this point a clean snapshot of the
virtual machine. What is this? It's a copy of the entire state including active
memory and persistent storage.
And the snapshot, then, you can reset to every time you want to do a browsing
session, okay. So with the idea that now in one browsing session you visit a bad
site and you are -- have a vulnerability exploited, well, then, the virtual machine
ends up getting compromised, but the isolation guarantees the hypervisor should
ensure that the host operating system remains virus free.
And so next time you go surf and you reset to your snapshot, then, well the
Malware is gone and you have security -- a new secure session.
So this has some very tangible security benefits, but some recent work showed
this actually causes problems for cryptographic protocols, and it's because of
random number generation failures. So if you're in this setting and you reset to
your virtual machine and now visit a secure website, so use HTTPS, then what
happens is the TLS clients on the browser picks -- uses random number
generator to generate some secret randomness that's now encrypted and sent to
the server, so this shared secret is used to bootstrap a secure session to do your
banking.
Now, the problem, of course, maybe not of course, the problem that we found out
is that if you then reset to this snapshot, and visit a new website that's using
HTTPS, you actually end up, the random number generator spits out the same
values for the browser. And so you end up sending this secret value to the next
server you visit. And this, of course, is a problem because this is all the secret
data needed to decrypt a transcript of the banking session.
So it isn't an abstract problem, it's a problem with real browsers, Firefox and
Chrome had this behavior. And again, the problem is that the random number
generation process is being undermined by this snapshotting. And this isn't
limited just to browsers. We also looked at TLS servers, particularly we looked at
Apache, MOD S, Excel. And there, if your running it multiple times from the
same snapshot, then you end up -- and you're using DSA mode, then you can
actually end up stealing the secret key from the server.
And in general, we think that this -- these -- what are the first examples of what
we are calling VM reset vulnerability really seem to be a big -- you know, the tip
of the iceberg, so to speak, type of problems here because there's a lot of
Legacy software being run in virtualized environments and whether they deal
with snapshots is an open question.
Back to the story about [inaudible] randomness, well ->>: [inaudible] easy to fix.
>> Thomas Ristenpart: So ->>: [inaudible.]
>> Thomas Ristenpart: That's actually -- so we haven't worked on this. So this
brings up two issues which I'll talk about in this slide, right? You know, one is
that we need to revisit the design of our keys in these applications. So there
seems like in the short term, there could be a good fix which is just that you don't
have Firefox, for example, cache randomness up front and it just does it every
time you do a new HTTPS request. Whether in all virtualized environments this
is actually giving you good, knew, different randomness each time you run from
the snapshot is an open question and something we don't know. And we think,
actually fixing the problem in general is going to require more extensive changes.
You're going to have to revisit hypervisor design, understand that the random
number generators need to be backed up by something from the hypervisor,
either hardware or software base and also have all your applications aware of the
fact they can't cache randomness for long periods of time because this would still
allow this type of reset problem.
>>: [inaudible] Firefox having read -- well, it's an application.
>> Thomas Ristenpart: It's a good question. We notified the VMM designers as
well. They said it was a Firefox bug. But, you know, the -[laughter.]
>>: [inaudible] random number generator actually taking the snapshot into
different substantiations. You take the snapshot, you [inaudible] in and then you
do the same thing again where you get ->> Thomas Ristenpart: Well, that would be true if you had hypervisor that gave
you a random number generator. In this case it's not set up that way.
>>: [inaudible.]
>> Thomas Ristenpart: No, no, no. No, no, no. No, no, no. Okay, so there's
two things here. If you have a hypervisor that's providing a rectangle, so for
example your placed at random with something the VMM is supplying the
randomness for, then you would be okay, I think. But this requires a change to
some of the virtual machine hypervisor design. If you just called DEV random
and rely on the guest operating system to generate the randomness, well the
problem is DEV random gets rolled back with the snapshot as well. So it's not
entirely clear that you are going get randomness.
>>: [inaudible.]
>> Thomas Ristenpart: No, it's open question. I don't know newly. It depends
on a lot of things, right? What measurements they are taking. Whether there's
enough differential entropy from one run to the next run and this is something we
want to study and measure to understand. I mean, to conjecture, I think, having
software based RNGS in this setting inside the guest OS almost seems like
doomed failure at some point. But whether it's actually a vulnerability or not is a
question.
>>: So can you always reliably reset the snapshot after the point that the
randomness is cached through Firefox.
>> Thomas Ristenpart: The way it works is the ->>: If you go back before it's cached, then that's no good, right?
>> Thomas Ristenpart: Right. Yes, yes, yes.
>>: So you do ->> Thomas Ristenpart: So the way it worked with Firefox, for example, is that
the random number generators used the time the Firefox generators booted up.
So if you snapshot at any point after Firefox is run -- and the particular
experiment, we loaded Firefox, let it sit for a second, took a snapshot, and then
went back. And this is consistent behavior, the same randomness got taken all
the time. If you took a snapshot in the middle of it booting up or something, then
you get inconsistent behavior, but this is unlikely to happen from a usage point of
view.
So ->>: So a simple fix from the snapshot functionality with VM could be you
drawback your [inaudible.]
>>: [inaudible] but you can't really take a snapshot, right? Or ->> Thomas Ristenpart: Yeah, it ->>: [inaudible.]
>> Thomas Ristenpart: Yeah, it's -- I don't know if there is a -- I mean one simple
fix would be to have an architectural -- like an Intel instruction that gave you
randomness and maybe you would be okay. But this is totally circumventing
hypervisor.
>>: [inaudible.]
>> Thomas Ristenpart: So there's multiple layers of prongs here. The
applications need to be aware of the fact they are being taken -- having
snapshots taken of them. And the fact is, the way purposely the way hypervisor
is designed is so that applications don't need to be aware of these things like
snapshots, right? And that's a functionality thing which is allowing Legacy
compatible deployment of systems in virtualized environments. So there's this
tension between functionality and security here, and I think this is, as I was trying
say before, indicative of abroad set of issues there. I mean we are take all this
Legacy code, we are throwing it in virtualized containers there's fundamentally
new things going back. We are rolling things back, setting, making copies,
duplicates and launching them off and this is only going to become a bigger
problem.
And so finding the -- so, to have a complete system solution I think is an open
question and something that needs -- that I'm looking at. But you know, I don't
think there's really a quick fix that's sound in any principled sense.
>>: I think the [inaudible] from a systems perspective, I mean there is one fairly
easy trigger point, which is these role backs, when you force like a DMp address
change, that's something the applications your used to dealing with so.
>> Thomas Ristenpart: You still have to modify all the applications that could be
vulnerable.
>>: To say, you know, you don't have to introduce new event. You just have to
introduce the knowledge and the developers that ->> Thomas Ristenpart: Right.
>>: -- when you see the address change, you ought to go get a random number
[inaudible.]
>> Thomas Ristenpart: So that -- that's going to be a significant amount of work.
So you're going to have to develop all the developers here at Microsoft on this,
right.
>>: [inaudible.]
>> Thomas Ristenpart: Yeah, so there's two things, right? This basically -- and
this is funny, because when I was talking to Chrome or Firefox, one of the guys
they are saying look, we are using best practices for random number generation
in our code, and so we should be fine. And I'm like, well, okay, the problem is
with virtualization we are now going to have to rethink best practice per random
number generation usage. I mean, that's just a fact, I think. So that's a hole host
of issues that I'm not going to talk about.
What I'm going to talk about in the next few slides is this kind of somewhat
embarrassing fact, maybe, that you know, our cryptographic operations in the
face of doing this repeat randomness like fall over completely, right. Session
keys get revealed. Okay. Also secret keys for DSA, stream interest scheme,
you can steal them from the server. So our question that we -- the question that
this work motivated in part was, you know, can we make the cryptography more
robust to these type of failures of routine randomness?
So to reiterate, you know, we have kind of varying levels of randomness. We
have a proper energy that providing always fresh randomness. We have these
settings like VM reset where you get repeat usage of randomness. So you even
have things like the [inaudible] debacle which you end up with a very set of
predictable values being output. And with our traditional cryptographic
mechanisms, basically they are designed in this context where you assume good
randomness always and so you get strong security guarantees given a good pop
per random share but otherwise everything failings.
And so our idea is okay, let's fix this situation and we call this hedge
cryptography. So we want our routine cryptographic operations to be as secure
as possible. In given whatever randomness they are given. So, for example,
with public key encryption when you get good randomness, we achieve our
traditional strongest security goals.
We get, for example, repeat randomness given to our encryption algorithm then
we are not going to be able to improvably reach our strongest security goals but
what we will do, instead of failing completely, we'll achieve some weaker but still
very meaningful level of security. And so, for example, here your only going to
leak the fact that you plaintexted quality which is something that randomization
requires to get rid of that leak.
And then if the randomness is predictable then we will again get I slightly
degraded security level, but still very strong and here, then, only plaintext quality
gets leaked. Assuming that there's sufficient entropy in your message
randomness pair combined.
So let me talk briefly about this last case which in some sense is the hardest for
public key encryption. And if we sit back and think for a second about our
encryption mechanism well there actually always exists an attack against public
key encryption and it's just a BruteForce attack that works as follows. Right. You
enumerate the set of all possible messages and the set of all possible R values,
and then you just it attacker rate during trial encryptions over each pair and then
check to see if the output ciphertext is equal to a target one that your given. And
if it is, then you know what the message of that target ciphertext is. Okay so this
doesn't always exist, but it's not always practical. So of course if the set of
messages or the set of randomness is very large, then this is inefficient and it's
not going to be practical in practice. And so at a very high level what are target
for hedge public encryption is that security -- a secure hedge public encryption
scheme basically mandates that this attack is in some sense the best attack
possible. That any other attack will essentially work only as well as this
BruteForce attack.
So how can we achieve such a thing? Well, we had this idea that we could -- if
we could design our i\encryption scheme to behave like a randomness extractor
we could achieve this goad. So randomness extractors are these plastic objects
that have been used quite extensively in computational complexity. They are
used in contexts like derandomization of randomized algorithms and studied
extensively.
What do they do? Well, they are a map that uses a seed S to map values from
some large domain to a smaller range, but with special properties. So, for
example, if you choose any sub-set of the domain, that's smaller, but still of large
size, then any point chosen randomly from the sub-set actually gets mapped to a
uniform point in the range.
And so in particular, if we design -- if we just have our encryption mechanism
actually act as an extractor so we choose our public key to be such a seed, then
this -- this property of the extractor basically makes it look like if you have a
message randomness chosen randomly from some sub-set of MR's, then the -an output ciphertext given to an adversary is just going to look like a randomly
chosen ciphertext. So you actually hide information about the message.
So this approach has a critical failing which is that we need to be able to decrypt
messages, and extractors are fundamentally compressing objects. To get these
properties, you need to go from a large space down to a smaller space. So
you're throwing away some of the Information you would need to decrypt.
So we can circumvent this, actually using some new cryptographic objects called
Universal Lossy Trap Door functions. And the idea is actually at a high level,
somewhat simple. We have a function, now, that actually there's two different
types of keys. So you choose a normal key, PK, which has a trap door
associated to it, and actually maps to a set of a range of fitness size that you can
decrypt properly. But at the same time there exists another way of generating a
key, S, such that the encryption algorithm now works like an extractor. And so
what it does is actually it only uses some relatively small sub-set of the entire
range to -- to map values from D2. And moreover, the point is that these public
key and S values are indistinguishable. So from an attacker's point of view, he's
given the encryption of an MR, and the -- and another value, either the PK or S.
He can't distinguish between the two. So it might as well have been encrypted
with this extractor key S. And so that means that we get back to this place where
we get the nice properties from extractors that they are hiding information about
sufficiently high mid entropy inputs.
Yes?
>>: [inaudible].
[laughter.]
>>: Okay, yeah.
>>: [inaudible.]
>> Thomas Ristenpart: Say again?
>>: Can you give us an intuition for those of us not [inaudible.]
>> Thomas Ristenpart: Okay. So a high level, what's the motivation here? That
we want to take advantage of any entropy in the message space to make up for
a lack of entropy in the randomness. So we like to basically take advantage of all
entropy in the MR -- in the message and the randomness combined, and extract
that out fully. And so what it -- you know, extractors being used in other cases
where you actually have some set of measured events, right, these are using
used in some sense for random generation. And what they do is take inputs and
map it to an output, and it looks like a uniform point, okay. But the fact is, to do
that, to get that property, you need to have a smaller set, and so that comes the
cryptographic component that's actually designed a functional encryption scheme
we need to actually do something more clever, and that's where this notion of
LTDFs comes in, these Lossy Trap Door Functions because they actually have
two operating modes. When you actually use it in practice, you use a public key
that actually maps to a set that's big enough to decrypt from, okay. But when
you're doing your security proof, you can then say, well, from an adversary's
point of view, you can just imagine that this public key behaves like an extractor,
and it gives this property that it's -- the output just looks like a random point.
>>: [inaudible] security proof, why can't you say that?
>> Thomas Ristenpart: Why? Well, I mean, there's a lot of details, but.
>>: [inaudible.]
>>: Many other cipher.
>> Thomas Ristenpart: I'm sorry, say again.
>>: Why does the security property continue at all. You've proven the secretary
property when you're using it in one mode and using it in this producing mode.
To actually apply a different mode.
>> Thomas Ristenpart: Right. So the key thing is this last kind of mumbo jumbo
at the bottom, which is that if I hand you a ciphertext and a key, let's call it D or
something, and now D is either a public key or an S, and you can't tell the
difference. So in the proof, we take advantage of that fact to say, okay, if we are
encrypting a message in the regular world with public key, you get a ciphertext.
It might as well, from an adversary's point of view been encrypted with this value
S.
>>: You say might as well, I mean prior to C adversary can reasonably assume
that your actually using this practice. It really is a publication.
>> Thomas Ristenpart: Right. But the point is that if you can distinguish
between -- if you can learn something about M, then you're going to violate -- we
can show using these reductions that you can -- you're violating the fact that
these two things are indistinguishable which we've proven under some
complexity assumption like -- well, not factoring because we haven't shown that
relation here, but something like solving discrete logs or CDH or DDH, I guest in
this case [inaudible].
So the point is if in the proof you -- if you show this, what you've shown is that
any attacker that does learn message about M is fully able to do something hard.
And that's what the proof is in there. So I was just giving you intuition about one
of the steps that proof in trying to gloss over quickly.
Okay. So we -- yeah, there's proof stuff. And then the -[laughter.]
>> Thomas Ristenpart: The fact is that you know, we can take these ideas,
basically -- oh, good. And we moved -- and it -- and moving from the starting
point, this is actually -- these construction are not practical, but what we show is
that we actually can do a practical framework for hedging a variety of randomized
primitives. And we'll talk about it, but the fact is you can just go and implement it
and it's employable, that's backwards compatible.
Yes.
>>: [inaudible.]
>> Thomas Ristenpart: So in the end, it's like doing two more HMAT calls over
RSA by itself. Or an RSA based encryption scheme.
>>: They are almost identical, right?
>> Thomas Ristenpart: Yeah, right. Uh-huh. Uh-huh. Yeah, not the
construction we are showing, but there's a simpler, less mathematically
interesting construction, but something that's very practically interesting, yeah.
And so we implemented in the open SSO library and the take away is that now
what we get is that we have implementations of the cryptographic cools that
provided us nice defense in-depth, right. Graceful degradation of security in the
face of bad randomness, right. So if some randomness occurs our crypto
operations are no longer going to just fall over completely, but give you graceful
degradation of security.
Okay. So we're still on the last two examples, right. Problems where we identify
some issue of practical concern, and dealt it by modifying the crypto, okay. And
the next -- the next example, which is kind of systems building example, we are
going see is that while we can do a bunch of machinations in design with
cryptography, we are going to see this doesn't actually solve the problem. So
here it's going to be important to understand the role of the crypto in a broader
systems security context. And in this context is device tracking.
So let me tell you a little bit about device tracking systems. The idea is
straightforward, right? You install on your mobile computing device a tracking
client which is going to use the internet to update a remote storage service
operated by some third party about the current whereabouts of your device. This
could be the time, the IP address, what wireless network your connected to, and
maybe other forensic data like pictures taken with a web cam. And then the idea
is that if it goes missing or stolen, the tracking client should nevertheless keep
updating the storage service with this data. And the user, excuse me, can -excuse me, retrieve this data, work with the authorities and try to attempt
recovery of the device.
>>: [inaudible.]
>> Thomas Ristenpart: It's exactly like Lo Jack, yes.
[laughter.]
>> Thomas Ristenpart: So Lo Jack is a great example of this. And the point is
that there is actually a big industry surrounding these products now and there's a
lot of companies offering them, and they are all competing on this engineering to
ensure the tracking succeeds in the face of physical adversaries, right. So this
laptop has a Lo Jack client actually in it's bios, for example are, to survive, you
know, hard disk formats and that time of thing.
We are interested in actually a different aspect of this prong which is the privacy
issue, right. That of course that these tracking services are also as designed,
tracking the legitimate owner when -- via their devices. And so from a
psychological acceptability standpoint, this seems a bit uncomfortable. And so
we pose this question, that can we provide a tracking service that at least the
tracking service provides the functionality that its required in the sense of tracking
the system after it goes missing, but at the same time, protects the privacy of the
owner when it's -- when it's in their hands.
And so, of course, the first idea you have is that we'd like to just encrypt this
content before sending it over to protect it from people at the remote storage site
that's being operated by the parties. And so we can do that, but there's two
problems with this. One is that, of course, other users are going to be making
use of this remote storage service, and so there's going to be a big database of a
anonymous encrypted content. And so the question is, how do you actually
efficiently retrieve a particular users updates if by definition you want this stuff to
be anonymous?
So we can actually soft that using some fancier cryptography that I'm not going to
talk about because I talked about crypto. I'll just put up this kind of scary looking
flow chart. But the idea is that you want to provide mechanisms that provide fast
search over encrypted data, and so allow the user to retrieve his data efficiently
without revealing information about past locations.
There's a second problem here which is that, okay, even if you do this, all this
fancy stuff, the -- the fact is that when you're talking over the internet, your
revealing your IP address to the remote storage service. And -- yes? Is there a
question or a half question.
>>: The problem that -- isn't there -- you said there are two problems. Isn't there
a third problem that once the bad guy gets your device he also has your
encryption keys and say ah, I lost my device. I wonder who had it in the past?
>> Thomas Ristenpart: That's a great question. Yes. So all the fancy crypto is
providing for privacy. So as the device uses up encryption keys, it basically
pictures knew once in a deterministic fashion, but such that you can't recover
previous keys.
You can think of it that way it's like AES, uh-huh. It gets a little complicated
because we want to build in things like a cache on the side so you can cache the
last few locations inside the clients, so you have to encrypt this and kind of
rerandomize encryptions before sending them off and this type of thing. But
yeah, we dealt with that issue uh-huh.
>>: I'm a little confused about model. Is it assumed that I don't have some home
trust in store that I can keep? Because if I do, then ->> Thomas Ristenpart: Right. You want to take advantage of a third-party
serves to provide the storage of your.
>>: The storage, yes. But if I at home can just store a key and sort of match the
forward sequencing of the key that's going on, then I just, you know, encrypt with
that key from the device and the third party can't read it and nobody else can
read it.
>> Thomas Ristenpart: When you say at home, do you mean on your laptop?
Because I'm here right now and my laptop is updating
some ->>: No, I mean some -- a floppy disk.
>>: Yeah.
>>: Or the USB.
>> Thomas Ristenpart: So a floppy -- I don't have any floppy -- I'm confused
about the question, I'm sorry.
>>: I have ->>: [inaudible.]
>>: Either safe in my house a small amount of data.
>> Thomas Ristenpart: Yes, that's the exact idea, yes so we are going to initial
lies the client with some small like AES key and that's going generate even more
material that we use to encrypt and index our updates. The client needs access
to those values and needs to send them off. Okay. And that's the intuition
behind the cryptographic component.
>>: But the [inaudible] seems like a big issue at this point. That everything I'm
seeing on the third-party service is already encrypted and the third-party service >> Thomas Ristenpart: Right. So that -- and that brings me to the next point,
why is this point that your revealing IP address potentially damaging? And the
idea is that there's partial information leakage here that you can do based on
traffic analysis, right? So, okay, we send an update now that it's totally
anonymous and encrypted from a particular IP address at a particular time we
are sending it remote storage service. So this is what the remote storage service
sees.
Now, what you can do is take this IP address, and this already reveals the
location, right, because you can use a geolocation service to identify where the
IP address is physically in the world. And so, okay, now you know it's home
residence, right? And so the point is, next time you see an update from this
home residence, you have a good guess that that person now returned to it, for
example. And so while it's not a hundred percent damage and like you're not
revealing everything all the time, and you can hide to some extent in crowds, the
fact is, there is partial information being leaked about locations via just the fact
you have just an IP address. So we set out to solve this issue as well, right? We
don't want to just rely on the crypto. There's a systems security issue here. And
so can we -- can we deal with this? Mitigate this threat of traffic analysis even
beyond what the crypto can provide?
So there's actually a long literature on inhibiting traffic analysis which -- woops
which revolves around doing onion routing. So the idea is you just bounce your
packets off distributed -- randomly chosen set of nodes to kind of launder the
source IP address. And so we can use this type of system as well. But we
thought, well, maybe we should -- we actually thought, okay, there's overheads
with these types of things, like latency and code complexity and such. And the
question was, so we motivate, say, can we actually improve privacy from traffic
analysis in some sense for free by using some decentralized storage
infrastructure to store updates. And so the idea is we ended up using what are
called distributed hash tables. Now these are systems that are decentralized so
you have something like Vuze or Azureus which has millions of nodes in it and
it's being used for things like bit torrent and it provides a very simple API that you
can put data under some index and then retrieve later that data by providing an
index.
So what we ended up doing is saying okay, let's take advantage of this
decentralized architecture. So when we do all this cryptographic work, we also
pick cryptographically random indices ones that can be recomputed later by the
owner, but from the adversary's point of view, without the original key, they just
look like random values. And then when we to a put, we do a put under that
random indices. And what that does is choose a random node to talk to in the
architecture so the next time you do an update it choose another node. So the
idea is we diluted trust across this decentralized storage structure for free without
having to use onion routing. And so even if some sub-set of the nodes are
compromised, they -- well, they only see one if ever, if that many updates is the
idea.
Okay, so, with privacy systems, okay, we interested in seeing, you know, is this
actually deployable, could people use this type of set up, both from the
cryptographic side and with DHT's. So we went ahead and implemented and
released a tool, these pictures were taken from our art client. We had a lot of fun
playing around with the web cam there. And we were very happy with the results,
that quite a few people downloaded it, and have been using it. And then maybe
more importantly, this work, this idea of using DHT's as a secure privacy tool
picked up a bit of steam and there's been some follow-up work in the community
about the efficacy, this idea of using DHTs.
So, okay.
>>: [inaudible.]
>> Thomas Ristenpart: Uh-huh.
>>: Actually run open DHT clients?
>> Thomas Ristenpart: No, no, they took advantage of the existing open DHT
architecture, yeah. So most of the client.
>>: [inaudible.]
>> Thomas Ristenpart: So open DHT might not be the best realization of this,
but we used it because it was the simplest to work with. And it has, I think at the
time it had something like 160, 170 nodes. So from that point of view, yeah, you
may end up talking to all the nodes at some point over the lifetime of the client.
You're still achieving some benefits in terms of privacy, but not going to be to the
scale of like if you linked in with Vuze or Azureus where you have millions of
nodes, but we wanted to use open DHT because it was simplest to work with at
the time and as a prototype to see if people would actually be able to use and
would want to use this.
>>: [inaudible] with this is that if it compromises nodes from the DHT picture,
pretty easy to create.
>> Thomas Ristenpart: Right.
>>: I mean you can assemble a packet if you really wanted to.
>> Thomas Ristenpart: Right.
>>: That -- I'm asking if the question is currently that that you would get to see
information about some IP addresses that we are sending things, but it would be
randomly selected from among the set, so -- right. You get good information but
you wouldn't be able to target it, is that's what is happening?
>> Thomas Ristenpart: Right. Right. So some portion of the updates you're
going to miss the compromised codes, right, from a particular client.
>>: Most of them.
>> Thomas Ristenpart: Most of them, yeah, that's the idea. So if you had a civil
attack where he took over the whole DHT, then you're back to the fact that you
have encrypted anonymized updates you have a little bit of privacy leakage, but
not that much. If you have a DHT that resists civil attacks, you get much stronger
privacy improvement against these particular traffic type cipher attacks. That's
the idea yeah.
>>: But if you do onion routing.
>> Thomas Ristenpart: Then you get.
>>: A stronger report.
>> Thomas Ristenpart: Right. And then onion routing of course has its own
issues about whether it's secure all the time or not, right. So you could do both,
right. You could route the DHT puts across onion routes and then you would get
like you know the most paranoid level of privacy ever or something, assuming all
the components are good.
>>: Although there's something to be said to you only need to keep the -- you
only need to be private up to a point that it's easier for somebody to just stick a
web cam outside your house and you see you walk in.
>> Thomas Ristenpart: Right, right, right, right. Exactly. And that raises a good
point that there is plenty of other ways that location privacy can be violate by
someone's laptop, right? Even. So if you contact G-mail every time you sit down
at your laptop, of course your notifying Google of all the locations you're visiting.
But solving the location privacy in the global sense is a much more and at
moment intractable problem. So we are trying to say just for device tracking
component, can you ensure that we are not doing anything?
>>: Does onion routing really help here? Because if the first node you touch is
compromised your screwed either way, aren't you?
>> Thomas Ristenpart: But you choose a different node each time so you get
the same type of guarantee you get from the DHT that we are using.
>>: Yeah, but I don't -- [inaudible.]
>> Thomas Ristenpart: Well, there's another layer of potential -- yeah. I mean,
yeah. It's actually a great point. So if you're -- if you're -- yeah. You get the
same level of guarantees. That's good.
>>: [inaudible.]
>> Thomas Ristenpart: Yeah, there's a lot of details I'm glossing over the DHT's
that ->>: That's like a factor of Y.
>> Thomas Ristenpart: For example, we have to do replication as well to get
functionality of the DHT. So you actually -- it's not just one node. You talk to
three, and then if you actually have to communicate with multiple nodes for each
put, then -- then you are leaking more. So, you know, there's a bunch of details
there.
>>: Is this really -- is this less complex than [inaudible] because the other reason
you gave for superiority over onion routing was latency, which I can't imagine is
an issue here.
>> Thomas Ristenpart: Well, so, yeah. It may not be an issue, a killer issue,
right? You know, one thing, to be perfectly frank is it's easier to work with open
DHT when we are implementing it than to work with TOR, right. It's big code
base. We want to have a very small client to fit in something like a bios at some
point.
The latency issues, I mean you have to complete this circuit, right, so yeah, in
general, it may not be a killer issue, but the idea is we want to we wanted to
experiment with the DHT and get TOR free and you don't have to have TOR and
rely on other people's TOR notes and all the security issues there. So in the end
it's going to be a choice for deployment, right if you want to use both or one or
the other, it's up to the people who end up designing the system.
>>: But TOR is [inaudible] because you really just need send one packet in one
direction. You don't really need to establish.
>> Thomas Ristenpart: Right, right. So you can you use a mixed router or
something.
>>: The tracking theory is offline.
>>: If there was a latency in the sense [inaudible.]
>> Thomas Ristenpart: I'm sorry, say again.
>>: Here, the location tracking was open DHT is offline.
>> Thomas Ristenpart: Right. I mean, you still need a remote storage service,
either way, I guess I'm not understanding your question.
Let me move on. I have a whole another topic I wanted to cover. We can take
more questions at the end.
So let me just get into it in the interest of time. And this work was about cloud
computing security. And, of course, you know cloud computing is going to have - is going to be quite the consumer of cryptographic services. It already is. So
we were interested in what type of threats exist in this context and whether
there's really knew threats that come up here or if there's kind of the same old
issues.
So what is a cloud computing service? Well, we were focusing on so-called
infrastructure of service systems. You have a provider that has a bunch of
physical hosts with a virtualization layer running on top of it. Users can come
and pay the provider to run their computational tasks in the -- in the sense of
running virtual machines on their service.
They are quiet dynamic so you can start and stop virtual machines at will, start
them up again. And an important facet of -- and feature of these types of clouds
is the use of multi-tenancy, that simply put, users are sharing physical resource
and of course this is important from the provider point of view because they can
statistically multiplex their physical resources across a wide user base and get
economies of scale that way. So again, this is powered by virtualization, so each
physical server has a visual machine running on it and the idea is that it should
provide the appearance of having a dedicated machine to one's self.
So we are interested in the following hypothetical threat that lies at the
intersection of this use of multi tenancy is the fact that these clouds are public,
that anyone can start running virtual machines on them. So the idea is the
following. The attacker is going to identify one or more victims running in the
cloud and then try exploit what we call a placement vulnerability. So, for example,
the attacker could launch lots of virtual machines and have each of these
checked somehow for co-residence on the same server as the victim. And
should this be successful now, the attacker can mount attacks to take advantage
of this close physical proximity. So he could, of course, exploit some know VMM
vulnerability and just take over the whole box and have a targeted to use a
known vulnerability. You could also do denial of service attacks, degrade -- used
up resources trying to degrade the efficiency of the victim. And then the perhaps
most subtle threat would be that of physical side-channeled attack which is just
the fact that your sharing the same physical resource, cache memory, hard disk,
might be sufficient to already extract some confidential information out of the
victim.
So this is a, you know, a hypothetical threat. We were curious to see if it's
actually a real threat. So we did a case studies with Amazon's EC2 service. And
what we were able to do, despite, you know, being white hat researchers and
abiding by the typical use policy of Amazon's service, we were nevertheless able
to do the following. Engage in what we call cloud cartography. So this is
mapping out some of if not all of the internal infrastructure of the service. With
particular and being that given a target, a public IP address, we can locate
approximately where in the infrastructure this target is running. And in particular,
identify launch parameters that would be advantageous for malicious virtual
machines to be ran under to try to end up on the same physical server as the
victim. Learn how to do co-residents checking, so actually understanding when
you're successfully on the same physical server. And then we did measurements
to experiment -- experimental measurements to see if this is frequently
achievable, and it is. And so the problem is that of course, there is -- it already
reveals a placement vulnerability that attackers can knowingly achieve coresidence with the victim. And so it's dangerous for a bunch of reasons. We
were interested in the aspect of physical side-channel attacks, and we were able
to show cross-VM side-channel attacks that can spy on the momentary load,
computational load of the victim. So I'll talk about each of this in a bit more detail
now.
But first, let me give a very high level overview of the some of the instance
networking of EC2. So you have you a virtual machines running on -- within a
XEN virtual machine manager. Each virtual machine has an associated to it an
external IP address and an internal IP address. Conveniently, from the attacker's
point of view, the internal GNS service in EC2 serves to it by any party to the
internal IP address associated to it. And this is to I think encourage people to
communicate via internal IP addresses within the cloud. They are priced
differently and it's more efficiently for Amazon presumably.
Our experiments indicate that internal IP addresses are statically assigned to
physical servers, so each machine, for example, hosting the smaller type of
instances ends up having eight contiguous internal IP addresses associated to it.
And, in fact, the way they did their networking actually provided in hindsight a
very simple way of doing co-residence checking. We did a lot of work to
establish that this works, but, in the end, it's simple. You can just do a trace
route to a target, internal IP address or public IP address, and if you only have
one hop, then you know you're on the same box. Because what happens is the
VMM actually routes to traffic right back to the guest operating system.
So with that in mind, we know how to do co-residence checking, but how do we
actually kind of figure out where in the cloud a victim is, and how can we
understand how to get to that portion of the cloud? So what we did is this
measurement study that we call cloud cartography. So we identify a bunch of
launch parameters for virtual machines in the EC2 service. For example this
includes things like the availabilities which advertises disjoint portions of the
internal infrastructure for redundancy purposes. The type of virtual machine
instance requested, and there's just a varying levels of virtualized resources that
are handed to the virtual machine. And then, of course, things like the user
account are also identified.
So what we did is run, using account under our control, virtual minutes and
changed each of these parameters one at a time. So here we have a graph of
the internal IP addresses of the resulting virtual machine instances colored by the
requested availability zone. And so what this shows is that the internal IP space
is segregated according to the availability zone which makes sense in light of
what their advertising availability needs to be used for. You can repeat this for
current instance types. Here we have a bunch of virtual machines that we ran
that are colored by the instance type. And again, we see quite a bit of regularity
in terms of which portions the internal IP address space is being used by which
type of instance.
And then this bottom half of the chart is using a second account, and we end up
in the same portions of the internal IP address space, and in fact ended up with
the same internal IP address many times.
So we can take this idea kind of logical conclusion and basically provide a map
now that associates, for example, to each slash 24. So the first three octets of
internal IP address an estimate of the availability zone and instance type that we
think are running on that chunk of IP addresses. And so this proves quite useful
because then given a set of public IP address, for example, we can map all those
to internal IP addresses using the internal EC2 address and look at the first three
octets to get an estimate of the availability zone and instance type. And this is
just a chart showing colorings of a bunch of publication P servers that were
running at the time of the study. But the point being that we get quite good
coverage across the internal IP address space.
So. Okay. So now we know how to locate approximately in the cloud where a
victim is, and we know specifically what launch parameters would be good for us
to use, and so now that we've kind of narrowed the search down, can we actually
get on the same physical server with good frequency? And so we did a bunch of
different experiments to assess the likelihood of this. And I'll just tell you about
one of them. And the setting here is that we are able to launch the attack virtual
machines relatively near in time to when the victim was launched. And so we did
an experiment where you lunch a target virtual machine and then you launch
from another account a few minutes later just 20 quote/unquote attack virtual
machines, and these -- all these did was check to see if they are a co-resident
with the target.
So out of ten trials, this already succeeds 40 percent of the time, so immediately
you end up on the same physical server as the victim. And this is actually very
cheap, you know, at the time it was 2 U.S. dollars. I think it's gone down since
then.
>>: You say [inaudible] from the same client?
>> Thomas Ristenpart: I'm sorry?
>>: In other words, the same ->> Thomas Ristenpart: IP address?
>>: Yes.
>> Thomas Ristenpart: For these experiments, no. I changed between different
IP addresses. I mean, it was from the same UC San Diego domain. So they
could be ->>: [inaudible.]
>> Thomas Ristenpart: We didn't exhaustively experiment. I also did some
lunches from home. It seems they are not taking that into account. Of course,
they could, but my sense is that they are not. And, of course, there are some
portion of the EC2 infrastructure that we don't have access to. I mean, they have
large corporate clients that maybe get some portion privately. But for this kind of
public portion of the cloud, it seems that you can really get on the same systems.
We did use, for example, there are some free demos from some companies that
use EC2 service. So they had like -- they call them cloud appliances or
something. And you can launch a free demo using their web interface under
their -- so it's their account, and we are able to achieve co-residence with those
as well.
Okay. So what can you do once you end up on the same physical server? Well,
we experiment with the idea of physical side-channel attacks. And in particular
showed how to do a cross VM load measurement using CPU cache contention.
So at a high level it's straight forward. You have a attacker and victim virtual
machine on the same CPU architecture, and so what the attacker does is first
read in a large array of data to basically, ensure that he use the entire CPU
cache.
And then the attacker idle loops with the idea that it will allow the victim to run
hopefully on the same cache architecture. And if the victim is -- you know, has
computational load it's going to use up some portion of the cache for its own
purposes. And so when the attacker runs again he can now measure the time to
read in this large array, and this becomes the load measurement. And the point
is that it's going to be correlated quite strongly with the amount of cache usage
by the victim and consequently the amount of CPU load that the victim is
currently under.
>>: So is your impression -- what's your impression about how [inaudible] sidechannel attacks might get and how hard would it be to defend? Are we worried
about private keys disappearing or are we really worried about core stuff.
Because load [inaudible] victims HTTP server and see how latent it is anyway.
So the question is, how scary is the threat? I mean, if we look at this for another
ten years, are we going to be getting private keys or ->> Thomas Ristenpart: So, yeah. My sense is that I don't know, and I think in
general the -- there needs to be a lot more research on these side-channel
attacks. Basically they are all kind a black art at this point. You have someone
sit down, some grad student who has not enough free time on their hands and
figures out how to do an attack for a particular architecture in a setting. And the
granularity there is basically depends on a lot of different factors, how many
cores you're floating between, how much -- how much noise is on the system.
And we don't really have good tools as far as I can tell of quantifying this type of
attacks. And I think it's a great open research question.
The concern, of course, which I'll talk about, is that these attacks that we used
are based on the side channels that in nonvirtualized settings were able to
extract AES keys across process boundaries in certain settings. So there's
looming concern that, yeah, as you get more refined attacks, then you're going to
be pulling out more and more dangerous confidential information. AES may not
be a huge threat in the future because we will have an AES architectural chip for
-- you know, an Intel architecture will have AES infrastructure. But the problem
with side channels are difficult to close down.
>>: It seems like you have separated [inaudible.] There's the getting information
a particular VM host and I'm interested in getting information from.
>> Thomas Ristenpart: Uh-huh.
>>: And then there's how I actually get information. Side-channel attacks are
probably [inaudible.]
>> Thomas Ristenpart: Right.
>>: But this ability to target, I mean, do you think that this is important? I mean,
Amazon's placement [inaudible] were optimized for impacting.
>> Thomas Ristenpart: Right.
>>: For efficiency and they have a relatively small cluster. So in the same way
that you used to be able to check information and check the [inaudible]
predictable sequence numbers, we thought that was a bad idea. We started to
randomize. I mean, aren't we just going to make this co-residency impossible in
the future?
>> Thomas Ristenpart: So the fact is if you're doing multi- tenancy, co-residency
is not impossible, right? If you're sharing physical servers between mutually
untrusted parties.
>>: [inaudible] arbitrarily ->> Thomas Ristenpart: Can you make it arbitrarily? I think it's an interesting
question.
>>: [inaudible] difficult to ->> Thomas Ristenpart: So certainly in -- yeah, sorry. Finish your ->>: Can I make it arbitrarily difficult to achieve co-residency with a particular
target?
>> Thomas Ristenpart: You can make it arbitrarily difficult if you don't allow
someone else to get on that box. So I mean, there is one way to make it
impossible which is to shut down multitasking which is something we suggest as
the only sure fire solution here. I think if you allow -- if you allow multi-tenancy,
the question is, can you make it arbitrarily hard? I don't know. It's good research
question. I think you could close down a lot of the things that we took advantage
of like network configuration issues, right? But that's only going to slow an
attacker down, right. So it's a good question. I don't know. Whenever you have
multi-tenancy you have potential forgetting on the same box and you have side
channels. So it's something you need to think about.
And the point of the researchers saying look, there's this new aspect in cloud
computing, right, where you have this first step. You have to get onto the box
first before you can tank advantage of close physical proximity. And so is this
something that's realizable? Well, it turns out, yes. Can we defend against it?
That's an open research question, yeah.
So application across VM load measurement. So we can do things like measure
relative traffic rates across virtualization boundaries. So, for example, we set up
an Apache server and a -- an attack VM that is co-resident running EC2, and
then we just buried the level of traffic sent to the blue server here. And the bar
chart on the right reveals the cross -- the VM -- I'm sorry. The load
measurements that were taken by the attacker. And so we see the strict
differentiation of -- of load measurement and so information is certainly leaking
here across boundaries.
>>: What do you mean by load characteristics? Load is clearly in a CPU load.
>> Thomas Ristenpart: I mean in an abstract sense. The load measurement
here is the read time from that third step in the algorithm. And so it could -- it
could be a bunch of different features. But the point is that you can correlate it to
other things that are happening with the box, right.
>>: You can correlate what? I'm not understanding what the "it" is.
>> Thomas Ristenpart: Correlate what? So here, it's the relative traffic rates,
right? So you know that if you saw -- in this -- in this, granted experimental
setting, right, you see higher levels of load measurements. You know there's
more activity going on, more HTTPS -- HTTP requests occurring.
>>: [inaudible.]
>> Thomas Ristenpart: Oh.
>>: I'm thinking it looks like ->> Thomas Ristenpart: Oh, this is the mean CPU cycle.
>>: [inaudible.]
>> Thomas Ristenpart: Right.
>>: Okay. But this has ->> Thomas Ristenpart: To load the array in the third step, yeah.
>>: This happens to be a metric where you're going to have a strong correlation
between memory use and CPU use because your CPU is ->> Thomas Ristenpart: I see what you're saying. So ->>: From memory so -- so this doesn't seem like the right -- it seems like if your
only using this test, your getting the wrong -- your measuring the wrong thing.
>> Thomas Ristenpart: For what exactly? So for some applications, yeah,
maybe you're not hitting the cache as much and then you won't get any signal
even though you have CPU load, right.
>>: [inaudible] cryptographic load on. It's not going to detect the cache too much.
>> Thomas Ristenpart: That's the exact problem like AES does use the cache,
right? And so that's where we get issues with AES side-channel attacks across
process boundaries which could end up being a problem here.
So, I mean, they -- yeah, I mean you do use the cache for lots of different things.
The question, maybe there are some things that literally only registers on the
CPU property and not using the L1 cache or the L2 cache at all. And then you
wouldn't be able to measure those type of behaviors, you're right. So it's cache
load measurement, I guess would be ->>: [inaudible] what fraction of time your actually sitting in your busy route? I
mean, see how much just look at how much you can schedule.
>> Thomas Ristenpart: So it is -- yeah, so you'll see that if other instances are
busy, for example, you'll get float more frequently between cores and stuff. So
these are other ways that information is leaking across. That doesn't take
advantage of the cache. I mean, the point -- yeah, this is just one example
where we said, okay, here is to prove a concept, in EC2, we can get information
leaked across virtualization boundaries, right? We can get on the same box and
then we can do it. Now maybe this isn't the most damaging thing to be learning
in the first place, but it's something you shouldn't be learning. The virtualization
is supposed to be stopping this type of leakage or at least that's the concern that
people think that this is the case. And so, you know, in general, there's going to
be a whole wide range of side channels that you might be able to take advantage
of. We also looked at, you know, taking care of memory contention, hard disk
contention. Of course, I was talking to someone about network card contention,
and they are saying, oh, yeah, this seems like a great way to get in a good
position to take advantage of network card contention to identify encrypted
streams and these types of things.
So there's a lot of different ways you kind of play as an attacker with various
shared resources once you're on the box. I mean, you still look confused, but
maybe we can talk about it later. We are running low on time.
>>: [inaudible.]
>> Thomas Ristenpart: Yeah. Okay. So, you know, we show these things in
EC2 like I said, keep rest timing, you can do this and get even finer grain
information. Of course, the future work is -- concern is about AES cryptographic
keys or other cryptographic keys being taken across virtual machines.
We think this is a big problem, you know talking to people at certain companies
and others, they seem to agrees that this is an issue that people should be
concerned about. There's a lot of potential counter measures we could look at,
but you know, this is an open research question about what are the trade offs
and whether you can even quantifiably come up with any resistance to sidechannel attacks. It's an open -- open problem.
Let me just finish off very quickly with saying a bit about my future work, and I
think, you know, I've cast cloud computing stuff in a negative light in the last
bunch of slides. But actually, the project made me quite excited about cloud
computing in general that, you know, really looking forward, we can kind of see
that this is going to take off. It has a lot of value added for customers. And we
are going to end up in a world where a lot of competition classes, not the majority,
are going to be done with cloud. In some sense we are going forward, but we
are also going backwards. We had long ago many to one systems where you
had shared mini frames with many users sharing one single computer and we
had this personal computing resolution with kind of one-to-one mapping. And
with cloud computing we have this now many users sharing heterogenous
distributed infrastructure, say this many to many mapping and with this change
we have lots of security looming. We side for one, but there's others and I want
to understand these. So, for example, I think investigating more how the
mismatch of our Legacy extracting, so how engineers have been designing
software now for the one-to-one personal computing era really have mismatches
with the current realities of running these things in cloud computing settings. And
understanding if this is going to give rise to further security vulnerabilities.
I think another interesting line of work is about understanding whether we can do
cryptographic auditing of cloud services. So the idea is that right now, cloud
services are quite opaque from a user's point of view. And they want to have
guarantees about the -- their data and their services, and so can we even provide
technical mechanisms that could compliment any contractual mechanisms to
audit, you know, for example that a cloud is truly using enough redundancy for
our data, for example.
And then, finally in a bit farther out there, I think that, you know, we saw with the
move from many-to-one to one-to-one personal computing, we had this kind of
revolution in electronic crime. And I think it's interesting to at least start thinking
about what type of repercussions, moving to this new setting is going to have on
the underground economies that are occurring going on out there. Whether we
can get a head of this is one question, but also just understanding and measuring
electronic crime is a considerable challenge and something I think is fascinating.
>>: [inaudible] by the computing model such as main frames to personal
computers, or just by the fact that it got a whole lot bigger and so there's a lot
more opportunity.
>> Thomas Ristenpart: Does it -- I mean, from a crime point of view, I guess it
doesn't really matter exactly what the motivation was. The point was having the
one-on-one personal computing kind of enabled this new wave crime, right? So
yeah, in some sense it's from more people using it, but then we'll see a similar
exclusion, a variety of new service because of cloud computing and so similar
affects might be going on. So you know, it -- yeah.
Lastly before I finish I just want to thank, of course all my collaborators. Without
them this work wouldn't have been possible. And at this point I guess I'll just take
questions. Thank you.
[applause.]
>>: I think we already asked the last of the questions.
>> Thomas Ristenpart: Yeah. Thank you. Thank you very much.