17533
>> David Molnar: All right. Thank you all for coming. I'd like to introduce Raluca Popa, who is
completing her internship here after concluding a very successful undergraduate period at MIT
during which she published multiple papers at prestigious conferences. So we anticipate a very
successful career ahead of her, starting with this work she's done with us on cloud computing.
>> Raluca Popa: Hello everyone. I'm raluca and this is my internship talk. Too bad it's ending.
So I will talk about enhancing cloud SLAs with security, and designing a secure and practical
cloud storage system.
So this is work with Helen Wang, Jay Lorch, David Molnar and Li Zhuang.
So cloud technology is emerging rapidly and more and more users are using it. The reason is
that it provides more resources such as more storage, also more computation power.
It's also more reliable in the sense that the cloud can produce replication for you and more
available because the cloud is available from parts of the world as long as you have connection to
the Internet.
Also, it tends to be inexpensive. And it's much easier to buy cloud compute powers than have
your own personal cluster. So there are various use cases for the cloud and that's personal
storage, in which a user can store his personal file system on the cloud and that's benefit from the
reliability the cloud provides and also able, is able to share it with his friends across the world.
Also, in enterprise storage, because it allows companies to focus on the target of their business
rather than have to maintain clusters and pay people for various, for maintaining such clusters of
computers.
However, the problem is security. So so far in the traditional computing model, we have our data
on our own computers, enterprises ->>: Could you speak up a little?
>> Raluca Popa: Okay. I'll speak closer. Is this better? Okay. So in the traditional initial
compute model people store the data on their own personal computers, and they're the only one
responsible for taking care of the confidentiality of the data, integrity, correctness of the data and
the same for enterprises storing the data on personal clusters.
However, by moving the data in the cloud, the cloud is now the one who can read the data and
thus can control the confidentiality of the data, can modify the data. It can return stale data to the
user by not placing certain updates, or it can discard writes. And this can be a problem, because
there are bugs or misconfiguration in any software. There can be disk failures or cloud can be
curious or inattentively malicious.
And also criminals or hackers can get access to any computer. So the problem is that right now
cloud services do not guarantee security. They only guarantee availability. So, for example, if we
look at the Windows Azure service level agreement, for computing, the user will have external
connectivity 99.95 percent of the time. And they guarantee for storage, correctness of requests
at least 99.9 percent of the time and they don't mention anything about security.
Similarly, in SNS 3 service level agreement, they claim that the service will be available at least
99.9 percent of the time and for the cases when it's not, they reimburse the client using the
so-called service credit.
However, because there's no security guarantees, clients with sensitive data will refuse to place
their data on the cloud. Numerous clients have expressed concerns. For example, this is a
concern guiding with Azure in which a user says it's more dangerous than you think.
They say what the purpose of Microsoft is to control the data and to have unfettered access to the
data, to read it, find out about the business model, the various people, about the customers, to
change it and so forth. Also, similarly about Amazon. Amazon confirms openly that their service
is not PCI level 1 compliant, and they recommend not to store credit card information because
they do not provide any security guarantees.
Therefore, our goals is to enhance a service level agreement with security guarantees such as
confidentiality, integrity, freshness and writes realizability. So basically confidentiality is clear. It
means that no one else besides the users that the customer allows should be able to read the
data.
Integrity means that the data in the cloud should be some version of the data placed by the user
and not some junk data that the cloud put or some bag cost. Freshness means that any read to
the data on the cloud returns the data from the latest update.
And writes realizability means that any update to the data on the cloud is performed on the latest
update. Okay. So of course we'd like this to be efficient and scaleable, especially if we look at
enterprise case, which has a lot of data, a lot of users, a lot of access control groups and so forth.
So we have two main contributions. We provide a security mechanisms needed to enhance a
service level agreement with security guarantees.
We also design, build and evaluate the first end-to-end secure and practical storage system.
Okay. So I motivated our work. Now I'll go on and present related work, our model. Security
protocols in how we do access control.
So there are two kinds of related work. There are cloud services and there's research on secure
file systems and data store. So in the case of cloud services, there's Windows Azure and MS3,
for example, because as I mentioned they don't offer any guarantees regarding integrity,
freshness or writes realizability.
There's another cloud service Tahoe, which is a peer-to-peer cloud service which attempts to
provide more security guarantees. And in this case the users can check whether their integrity is
validated. However, they can detect this however they cannot prove this because they can
always be the case, a case in which a client falsely claims that the cloud changed their data when
that didn't happen.
Also, this service doesn't have financial contract, so if indeed the cloud, because it's peer-to-peer,
so if indeed the cloud changes the data of the client, the client -- no one will pay the client back
for damages.
Also the system doesn't provide freshness and writes realizability. The second part of the related
work is in secure file systems and data store, which is an extensive literature and contains
systems such as Sirius, SUNDR, Plutus and so forth. How are we different? First, by the fact
that we can detect cloudness behavior, we can prove it.
Also the cloud can disprove client accusations so why do we do this? Because in our case the
cloud is a liable entity and there's a financial contributing between the client and cloud. The client
pays for service and the cloud pays back for damages.
We also provide all of confidentiality integrity, freshness and writes realizability and we're highly
scaleable. So how come we managed to provide all of the four when most related work only
provides the first two?
Well, we envision the enterprise scenario in which there's an enterprise and multiple clients and
the enterprise is trusted by the clients and can perform some minimal checking. In the case of
this previous systems, they were just independent users having some access to remote server
and not talking to each other.
So in our model there are three parties, cloud and enterprise and many clients. The cloud is not
trusted for the reasons I mentioned before. It can change the data. It can return stale data. It
can leak the data and so forth.
The clients are trusted to do whatever they want with the data they have access to, because
they're allowed to change it. But they may attempt to access data outside of their access control.
And outside of their permissions and they are not trusted not to do this.
Also they may try to collude with the cloud to try to achieve this goal. [inaudible] perform
membership of it because they're the employees of the enterprise. Also the clients and the
enterprise together are not trusted to not falsely accuse the cloud of changing the data. Okay.
So a service level agreement to security would sound like this. If the enterprise or the user pays
a certain amount of money, then the cloud guarantees integrity, freshness, writes realizability,
with a certain percentage. If the cloud does not meet this, then it has to pay a certain amount of
money.
So now that we don't mention confidentiality here because this is entirely controlled by the clients
by just putting encrypted data in the cloud. So in order for this to make sense -- yes.
>>: Encrypting the data in the clouds, doesn't snooper let's what's in the data but you can look at
access patterns?
>> Raluca Popa: Yes.
>>: Cause traffic analysis.
>> Raluca Popa: Yes, I agree with that. We don't prevent the gains that -- yes.
>>: Looking at SLA down time is well understood as a percentage because it's inaccessible.
You're saying that some of the times the cloud can violate writes realizability and the client, the
metric of the client the client would pay 50 percent of the time, writes realizability?
>> Raluca Popa: No, what happens is that the latency in the cloud does not need this. They
agree to pay a certain large amount of money? So whenever the client improves.
>>: 50 percent, is 50 percent 100 percent of the time?
>> Raluca Popa: Maybe I didn't phrase it properly. So what I mean is the cloud says, okay, if
you pay this much amount of money, 99 percent of the time you'll have, you'll have all of the
security guarantees. When you don't have it, I'll pay you this much back. If you pay with more,
then I'll give you more.
>>: 99 percent says that [inaudible] you can violate it and within the SLA.
>> Raluca Popa: What I mean here is that when you violated the cloud it has to pay back
damages.
>>: That would be one hundred percent.
>> Raluca Popa: Sure, in the way you phrase it.
>>: It's easy for the client to verify the writes as realizability, it's a write that's violated?
>> Raluca Popa: Yes, so we'll get to all of this. I will explain how everything is verified.
But the bottom line is that there is some auditing going on at the enterprise that's off line that's
lightweight. And it's easy to check in that auditing. I will explain. It's quite fast.
Anyway, so in order to be able to have such an SLA underlaying, for such an SLA to make sense
the customers need to be able to detect and prove cloud behavior. Also, the cloud would not
provide service if clients can falsely accuse him of damages and then get money from the cloud.
Therefore, the cloud needs to have a way to be able to disprove invalid client accusations.
So our solution is based on sign resets. So at high level then I will explain in more detail. The
clients and the cloud exchange receipts every time the client makes a request.
By the receipt, when the cloud returns a receipt to the client, it means that the cloud, the cloud
agrees to perform the update that the client requested or that the cloud states that the request,
that the response to read is correct.
When a client gives a receipt for a write to the cloud, it means that the client says that, yes, I
allow this cloud to make this verification, make this change.
Okay. So the design principle of our work is to unload as much work from the cloud as possible
but verify. So these are the operations that should be performed in our system. So there's
read/write operations. There's integrity, freshness and realizability checks and access of the
users, key distribution needed for access control, confidentiality and membership updates.
And in fact we manage to off load most of the work for the first four to the cloud which are the
most expensive ones, as I will explain. The clients are the ones performing confidentiality by only
uploading encrypted data.
And the enterprise only gets to do membership updates, client vocational, client granting
permissions, and some lightweight auditing to verify that the cloud has properly performed the
first four tasks. As we'll see, both tasks are done off line, and in particular auditing can be
outsourced maybe to a second cloud or to a cluster and we'll see it's lightweight.
And both are inexpensive as they'll argue.
>>: What membership can [inaudible].
>> Raluca Popa: I said the enterprise has employees, the clients. And some employees are
given access to particular amount of data and some are not. So membership in a sense that who
are the members allowed to access the data.
>>: This is an authorization?
>> Raluca Popa: Access control, yeah.
>>: Access control is [inaudible].
>> Raluca Popa: Yes, access control in the sense that only certain clients can access the data
on the cloud or not. And the membership here, I mean which are those clients that can do that.
So the cloud makes sure that whether this kind is valid or not it can act as a data but we have the
enterprise to maintain that.
>>: So if you audit, what would be the access control.
>> Raluca Popa: Well you need access control because some clients should not be allowed to
read it.
>>: Even if they visit.
>> Raluca Popa: Yes, but some clients should be allowed.
>>: If they write it.
>> Raluca Popa: Need it for both. So for read -- if a client has read access he should be able to
get the key and he should be able to decrypt. If a client doesn't have read access he should not
be able to get the key and decrypt and write access the same. Shouldn't be able to write if he
doesn't have access.
>>: [indiscernible].
>>: I guess the question is who stores these keys? The cloud stores the keys?
>> Raluca Popa: I will get to all of this. This is just high level -- I'm illustrating how our design
point is into the system.
Okay. I'll get to all of this. Okay. So first confidentiality. So as has been done in many previous
work, each block is encrypted with a cypher such as AS. The clients have the key. And to know
the decrypted value of the block. The cloud only gets to see the encrypted block and no key. So
he cannot encrypt the block. Integrity. Again this is similar to what's been done in previous work.
The client now has an additional sign-in key that's secret and only the clients with certain access
permissions know it. Now, this key is used to sign a hash of the encrypted block, and this
signature is given to the cloud.
Now, the cloud needs to ensure that a client cannot make a modification to a block without
providing a valid signature. This is because later if a client wants to verify the signature and it's
invalid, it's junk, it means that the cloud modified the data. The cloud wouldn't be able to produce
such a correct signature without knowing the sign in key. He can verify it because he knows KP,
which is the public key.
Okay. So now I'll present the receipts and how the receipts exchange between the clients and
the cloud goes before I go into freshness and writes realizability. Okay. So when the client
performs a write request, he has to provide a signed request, a signed receipt to the cloud in
which he says, yes, I would like you to make this change. Override the existing data and make
this change.
So this receipt has to contain an old hash and a new hash, basically saying I'm changing the data
from this state to this new state.
Now, the cloud has to respond with another receipt signed by the cloud saying, yes, I agree to
move this block from this hash of the block to this new hash of the block. For read, the client
doesn't provide any receipt. And the cloud has to provide the receipt in which he says, yes, this
is the latest version of the file. It has this hash.
So it only contains the current block hash.
>>: This in the read/write does it have a cloud to verify the client is authorized to do this or ->> Raluca Popa: I will get to access control as well.
So okay so now how do we do writes realizability. So as I mentioned writes realizability means
that a write is performed on the latest right. So the cloud must ensure that updates are performed
in the last version of the data. The way he does it is he looks at the client receipt and sees the
hash from all the receipts corresponds to the current block on the cloud. Means the cloud had
the right version.
For example, this is a time line showing a block which initially had the hash H1. Client A comes
and reads and the hash is H1. Then client B comes and he reads the block and the hash is H1
and wants to change it. Client B comes and he wants to write it. So he advanced the hash from
H1 to H2. Client A doesn't know of the change and he wants to write block and change the hash
from the previous H1 which he was aware of to a new H2 prime. The cloud should prevent this
and should inform client A that a change has been made.
It's up to client A what he does. Maybe he merges the versions, maybe he overwrites it, maybe
he takes the old one. But any subsequent client request that client A makes has to have the new
old hash, which is H2.
>>: Why is there a requirement for hash in the version, if these are [inaudible].
>> Raluca Popa: You can use a version, but that won't work for later for freshness. I will explain
that, yes.
>>: What if the same data is written twice? Would it have the same hash?
>> Raluca Popa: Yes, so if it's written twice and it's the same, you mean is the same content?
>>: Yes.
>> Raluca Popa: You mean the same content?
>>: Sure.
>> Raluca Popa: Well, it turns out that it's fine if there are cycles in the hash, it will work out
theoretically it works out. Our auditing will work out.
>>: I'm not so sure that it will, because can't you pretend that certain things that happen do
happen, so say -- so let's say that it's -- if there's a loop and then I've gone and the next step in
the loop you can then remove that step and make it look as if it never happened.
>> Raluca Popa: You can remove that step only if you're the only one updating in the loop. If
there are other people in the loop as well, they will be sending as I will explain receipts for
auditing. You can't copy those people's receipts, those people's updates. I will explain because
everyone is sending receipts to the enterprise for auditing. I will explain. I will talk more about
that.
And the enterprise will see, hey, this receipt is nowhere. This didn't happen and then something,
the cloud did something wrong.
I will present it. Okay. So freshness. So in freshness we like to guarantee that a read to a block
sees the last write. In order to guarantee freshness we add a chained hash called CH to each
cloud receipt.
So the chained hash for a certain receipt is equal to a hash of the previous chained hash and
concatenated with the current receipt. So the chained hashes for a certain block of a chain,
basically what happens is that the chained hash for a certain receipt is, contains in it information
about all the previous receipt history for that block.
Now the reason why this gives us freshness, and I'll discuss more, intuitively the reason is that if
a client comes and performs a read after a certain write, and the cloud attempts to put the read
before that write, giving it stale data, then the chained receipt of the write won't change with the
read before it because the person who did the write had already received the chained receipt a
long time ago, and that cannot be changed. I'll explain in more detail. This is intuition for now.
Okay. So, for example ->>: Leads to verification. So the clients who is reading right now there's no way that the client
can make sure it's freshness?
>> Raluca Popa: No, correct.
>>: So this could be a problem of someone saying how much balance this guy has, is it
$100,000, I get the $100,000 and I run away.
>> Raluca Popa: Well ->>: See what I'm saying?
>> Raluca Popa: Sure, but the problem is that the bank -- here is we are trying to prevent the
cloud from being malicious. If the cloud is malicious by saying you have a lot of money coming ->>: It's not malicious, it's a bug. It's a bug in the cloud, and you cannot guarantee, like a found
read it's a fresh, because the client cannot verify it. See what I'm saying? Like in that scenario,
like who do you blame? Do you blame the cloud? It's a bug. It's in the one percent, even though
it's a million dollars, I'm not going to pay you that.
>> Raluca Popa: Well, yeah, basically so what happens -- in our system all the security
guarantees are checked at the end of the month and they are proven, proven that they were
wrong. So if you're not fine with that, I know so if you're not fine with that, someone proving at the
end of the month you just want to know every every second, then you should either decrease the
auditing period and do it all the time.
>>: No, you can do it off line I'm just saying this freshness is not in real time.
>> Raluca Popa: Yes, if you want to do it in real time you can do it in real time. You can have
the enterprise in real time checking receipts all the time. But it's more cheap to do it off line. Yes.
>>: My question is, so when you're audited when you find a problem, how -- do you have to reset
all these chains again, say yeah it's a bug, everybody agrees let's fix the bug, how do you reset
everything?
>>: Because now you ->> Raluca Popa: Yeah.
>>: Basically ->> Raluca Popa: You keep the current state. Basically what happened is you realize the bug.
You say the cloud did something bad. The cloud pays you for damages and you keep going.
>>: That has to be several transactions between the cloud, enterprise and the client -- don't have
to agree that, yeah, that was a bug and now we all start with a new --
>> Raluca Popa: It's easy -- the enterprise is the one performing the audits and gets all the
receipts. The receipts are proofs in itself. And then just the enterprise in the cloud reconciled
and the cloud pays it back for damages. Of course, if you would like to roll back, then you should
maintain additional state, like loggings.
Let's see how the train hash is working, example. So a client comes and performs a write, write
one. And his receipt is for write one and the chain hash is just the hash of the current receipt
because there's no previous chain hash.
Okay. Now, another client comes and performs a read and now the chained hash is the hash of
the current read receipt, and the previous chained hash, which was just the hash of write one.
Similarly, a third client comes and performs a write and his chained hash is now a hash of the
write receipt in the previous chained hash.
So finally auditing. So the enterprise periodically audits each block with a certain probability.
Logs are more sensitive and enterprise cares more for them they should have high probabilities
or they should have a probability of 100% which means they're consistently being checked and
they have full guaranteed consistency.
The cloud doesn't know which blocks are going to be audited at a certain time. The blocks that
are going to be audited, the clients send receipts back to the enterprise. Send the receipts, goes
from the cloud back to the enterprise.
Okay. So the enterprise performs the following check. It groups the receipts for each block
together. Then it tries to arrange the receipts in a sequence such that the new hash of a receipt
is equal to the old hash of the following receipt. So, for example, here I have three receipts for
the same block. Two of them are writes, because they're advanced the hash from the block, from
the old one to the new one. And receipt number three is a read.
We can see they're chained by the value of the hashes. The new hash of the first receipt is equal
to the old hash of the second receipt. The new hash of the second receipt is equal to the hash of
the read receipt, the third receipt.
Okay. Now the enterprise has to check that all these receipts form only one chain. If they do, it
means we have writes realizability. Here is why. Assume that they form multiple chains, that the
chain is being forked. And there's a certain client four who did the write four and send the receipt
back to the enterprise.
Well, it must be the case that either client four or client four reached the enterprise first, sorry,
reached the cloud first, sent the write request first.
Without loss of generality let's say that the client did the write first. Then he went from hash B to
hash C. Everything is fine correctly. Now client four comes and he wants to perform the write.
Then the cloud should not have allowed client four to perform this write and should have informed
him of the client two update. Here's where writes realizability was not respected.
>>: It doesn't seem right.
>> Raluca Popa: If it's the same write, he should still send a receipt.
>>: No, but I mean the new hash is still C, right? Client four -- client four -- client four and client
two the same update to the data.
>> Raluca Popa: The cloud is still the same client four, because what client four did -- you don't
know what work he was trying to do. He was just trying to get the state of the data and advance
it. Maybe if he saw that the state of the data was C he would have done something else.
So, yeah, the cloud is still informed of change. Yes.
>>: You talk about sorting the receipt. This is a topological sorting, named as such. And you
don't have a little date stamp get very expensive.
>> Raluca Popa: I agree. You should have some time stamps. You should have some version
numbers. In actual implementation I have, because it was easier to. What also you can use is
the fact that these receipts will pretty much arrive in the order in which they were generated. Of
course, it's not a guarantee but that will help with efficiency, because clients will perform the
writes in order.
>>: Let me finish my question. When you verify now, what do you verify? So between those two
records, the one in red and the one in blue. You verify that the new hashes are in time or do you
verify that they're sort of different lines?
>> Raluca Popa: What you verify right now with enterprise verify is are these receipts just one
chain? If the chain forks, the cloud was bad.
>>: I see.
>> Raluca Popa: And so the enterprise, just one chain because that means a total order on the
writes. Each update for the first one. If it's a forking, it's bad. And it was not maintained. If
there's a gap, then the enterprise will compact the cloud, say there's a gap here, maybe some
client stand out and send in the receipt, you should have their receipts, can you give them to me.
If you don't have them you did something bad. You just skipped the hash. Okay.
So for freshness, we now look at the attached chain receipts to chained hashes to these receipts
and we make sure that they also are coming sequence properly. So remember each chained
hash of a receipt was a hash of the current receipt with the previous hash. So they are chaining.
And now the enterprise needs to check that the sequence of this chained hash is the same with
the sequence of the receipts from the previous sort. And this means that we have freshness. So
okay it's clear why this means it has freshness, because it means that each write was performed
the previous write. Let's see what happens if the cloud attempted to provide stale data. So in
this case let's assume that the read in the third receipt, when the client performs the read the
cloud attempts to give him the block with hash B as opposed to block with hash C. Well, in this
case what would have happened is, so in this case when the enterprise checks the sequence, it
must have been the case that the chained C H2. Chain is with C H3. That C H2 comes after C
H3. However, when client 2 performed write 2 he got the chained hash and he left. Then client
three comes and performs the read, but then the cloud cannot change the chained hash that he
gave to client two because he already left. Therefore, it's not feasible for the cloud to provide C
H3 to the read such that C H2 comes properly after it. Unless it finds some collisions in the hash.
Okay. So post auditing the enterprise and the cloud can throw away the receipts. They're not
needed anymore. They only keep the last receipt for each block, so that any subsequent writes
or reads can be made as a continuation of the current state of the system.
And since there can be many blocks, and you don't want the enterprise to hold a receipt for each
block, then the enterprise should just compute the numerical hash and hold the numerical hash of
the whole system.
And this auditing is highly paralyzable, because basically what enterprise, takes a chain and parts
of the audit of the sequence can be delegated to different threads.
Yes.
>>: You mentioned earlier that enterprise, it's apportioned randomly of the blocks.
>> Raluca Popa: Yes, so the enterprise just audits a part of the blocks each block is given a
probability if the enterprise wants to make sure that a certain block is always correct, it will always
audit it.
>>: Let's say I'm a client and I complain a week or two later, yet the process has already done
the audits that occurred in that time period and run through the data, what happens then?
>> Raluca Popa: So you mean you complained about the previous auditing period?
>>: Yes.
>> Raluca Popa: And you complained about the block that was not audited?
>>: Exactly.
>> Raluca Popa: Well, too bad for you.
>>: Hmm.
>>: You only have one monthly item, you only [indiscernible].
>> Raluca Popa: Yes, because basically you want to make sure that your update went through.
You have to send a receipt to the enterprise.
>>: Okay.
>>: You have to send the receipt to the enterprise. That doesn't mean that the enterprise
checks.
>> Raluca Popa: Well, sure, but you can -- if that block can still be audited ->>: How long is an audit period?
>> Raluca Popa: Make it one month, can make it one day. Just depends on how much
computation the enterprise is willing to dedicate, how much the enterprise cares about the data.
But basically for the blocks that are audited within the audit period, it guarantee we have full
security guaranteed for the clients that care about the request and send back the receipts.
I mean if the enterprise really cares about some data it can always audit the blocks.
>>: So can you tell us how expensive it is to audit receipts.
>> Raluca Popa: Yes, I will tell you. Okay. So now how do we do access control? And for this I
would like to present two crypto graphic primitives that we're going to use. First is key rolling
introduced by Kevin Fu in 2005. Basically what happens is you start with an initial key and from
that key you can do X sequence generations of the key.
So his tool ensures that only a party having the secret key can roll all these keys forward. In our
case it's the enterprise. Only the enterprise will be able to roll the keys forward.
Anyone can roll the key backward if they have a certain generation of the key. So, for example, if
someone has key of generation three it can generate key generation two and key generation one.
So the second one is broadcast encryption, which there's been various methods proposed. One
of them is Boneh in 2006. So the idea is that the enterprise can encrypt a message for a group of
clients.
And any person, any client in that group can encrypt the message but no one else outside of it.
And there's different schemes with various complexities but I will not get into that.
Okay. So for access control we introduced the notion of a data group, which is basically a group
of blocks with identical access control lists. Now, each data group has one file in which there's
key information. The file is stored on the cloud. So here's what the file contains. It contains a
broadcast encryption of the current generation of the key. We use it to encrypt the block. So, for
example, here the key is a generation I. And key I is the key that is used to encrypt all the blocks
in the data group.
It's a symmetric key. Now also it contains as I mentioned for integrity we use a sign in key that's
secret to the cloud, and in the public key used to verify that the cloud knows. So now we have a
broadcast encrypted version of the sign-in key. So now clients who have write permissions can
encrypt this broadcast decryption, and anyone can see the public key, including the cloud, and he
uses it to verify integrity.
Yes.
>>: Can you change that.
>> Raluca Popa: Can you change what?
>>: The group. The members of the group.
>> Raluca Popa: The enterprise can add new members to the group. So basically what
happened, when the enterprise adds new members of the group it changes this file. It picks a
new key or maybe keeps the same one and broadcast encrypts it for everyone now.
>>: Did the old clients need to get the new key now to be able to decrypt it?
>> Raluca Popa: They will only get the keys when they go to the block, as I will explain, when
they go. I'll explain it. Yes.
>>: Confused. Previously you said that KP involves the client and the client keys every single
target is KP. Now KP sits in plain text in the cloud.
>> Raluca Popa: So ->>: That seems to be contradicted.
>> Raluca Popa: So the cloud has KP. The cloud knows the public key because he uses it to
verify that clients are given correct form blocks because now the cloud is not later accused that
he changed the blocks, because if ever a client comes and says can you give me the block and
give me the signed attached to it and sees a bogus signature, it's going to accuse the cloud
because the cloud may try to change the blocking.
>>: KP is a public key.
>> Raluca Popa: KP is a public key. Yes. And KS and K are known only to the clients who have
access who should have access to them. Yeah, so basically the enterprise here will encrypt KI
used in broadcast encryption directing only to the clients who have read access. So only those
clients will be able to decrypt the broadcast encryption.
And the same for the sign-in key, the secret key, is only the clients who have write access will be
able to decrypt the broadcast, because the broadcast encryption was generated just for those.
And this file is protected, is read only to the clients, and it's a read/write to enterprise. So
basically it's checked using the mechanisms I described but it's [inaudible] all the time, for
example.
So how do we do revocation, when a member leaves a data group, the enterprise needs only to
change the data group file. The enterprise won't go and encrypt all the other blocks with the new
key. So basically it selects a new sign-in key and a new public key. And it encrypts the sign-in
key with the new membership that has the write access control.
Then it rolls forward a new generation of the confidentiality used to encrypts it only, broadcast
encrypts it only for those clients that still have permissions to it.
Now, we have a lazy revocation. We have a lazy revocation approach in which basically the
enterprise doesn't go and encrypt all the blocks to which the revoked client has access to.
But we instead just guarantee that any further changes won't be seen by the client. And basically
what happens is when new clients come -- when clients come up, come to check the file, clients
still have access permissions to the file they will reencrypt the file with the new key.
>>: Can we get -- erase old encryption, right, the encryption, the blocks encrypted with the old
key?
>> Raluca Popa: Yes.
>>: So if the member that you want to invoke the key code colludes with the cloud, you're
screwed?
>> Raluca Popa: So we say we adopt lazy revocation that we allow, we just prevent against
future changes for the files not to be seen to the client but to the revoked client and the rationale
for that is first efficiency, and second is that well if a client had access to the blocks he could have
[inaudible] them before.
>>: Right. But I'm not saying ->> Raluca Popa: Sorry. And I mean of course if you want to make sure, you can just spend
more computation side doesn't have the enterprise reencryption.
>>: You have to suppress the cloud if the cloud erases always the encrypted data.
>> Raluca Popa: You can't trust it.
>>: Okay. Fine.
>> Raluca Popa: Okay.
>>: Back to the impact is [indiscernible] you don't see the data even though you lay down or
something, but that doesn't mean doesn't have a huge amount of data. I mean if you down
beforehand before you lay off the [indiscernible] you still can't access all the data even though
one year later that sounds not so practical requirements.
>> Raluca Popa: I mean, I agree. And we can't trust the cloud to raise it. We can check that.
Later on if you somehow determine by some other means that the client still had a copy of it, then
you just -- I mean so the client ->>: It's a trade-off, right? It's a trade-off because you -- this is a roll key, right, because you want
to have this back and malleable so that anyone ever have access to those files they can decrypt,
right? That's the trade-off.
>> Raluca Popa: Well, I think the trade-off comes in place by the client storage on the cloud
because the client can always keep all versions of the data and we can't stop him from doing that.
>>: Just the problem between a trust model of maliciousness and a trust model of [inaudible], but
you're paying SLA. If you suddenly see maliciousness, then things like persistence can't be
guaranteed. One operator could take bribes to drop the latest version of your file and Amazon is
happy, $30,000, and you've lost your billion dollar project. Tacking on the maliciousness aspect
seems like there's these other guarantees that might not be able to provide ever.
>> Raluca Popa: Yes, and I agree with the fact that -- like we don't necessarily think of a cloud
that's intently malicious because the cloud would go out of business really soon.
>>: I can't argue with that.
>> Raluca Popa: But anyways, if the cloud is absolutely intently malicious, wants to be bad, it's
the company's goal, then, yeah, persistent data is we can prevent against that. The cloud can
just make a copy and a user who used to have access to it can still have access to it. And that's I
think inventing out -- storing outside of your clusters.
Okay. So the receipt as I mentioned the receipts serve to prove cloudness behavior or disprove
invalid client claims as I discussed. However, there's a problem because these receipts need to
be exchanged in all or nothing fashion. Here's why. So assume that a client was to make a write
and he gives the cloud a receipt. The cloud comes out and he doesn't send the cloud receipt
back to the client. Then the cloud has still he has the write receipt from the client and he can
choose to apply the change or not. Whatever he chooses he's backed up because he has the
proof that the client requested that change.
Also, if we go the other way around in which the cloud sends the write receipt first and then the
client needs to send it after and the client says, oh, I can turn out I didn't send it, then the client
has the cloud receipt and he cannot use the cloud.
For example, the cloud doesn't know what to do because he didn't get the client receipt. He can
either apply the data or not. If he doesn't apply the data and then the client can accuse him,
saying, hey, if you give me this receipt he said he agreed he will apply it. Or if the cloud does
apply the data, does apply the change, then the client can accuse him saying I never asked him
to make this change; he doesn't have a receipt for me so I never asked him. So these receipts
need to be exchanged in an all-or-nothing fashion and there are primitives for this like exchange
by Merkle in 2006.
The problem with this one is that it invokes a trusted party whenever a problem occurs, when we
know the party doesn't send the receipt. And that's not very efficient, because it can happen that
clients time out. So we adopt a change solution which is, in which the cloud does send the
receipt first. Then it waits for the client to answer. If the client doesn't answer, the cloud contacts
enterprise saying can you please allow his write request.
>>: Whose write request?
>> Raluca Popa: If a client sends a write request, then the cloud sends back the receipt, but he
doesn't get the receipt if the client. He waits for a while and if he doesn't get it he goes to the
enterprise and annuls it.
Okay. So I've presented our protocols. Now I will go on and present implementation, evaluation
and I will conclude.
So I implemented the system in about 5,000 lines of C#, just for our code. Of course, this runs on
top of some Azure storage client and also uses some other single code.
So the way Azure works, I don't know how many of you are familiar, is it has two kinds of rolls. It
has Web rolls which can contact, which can talk to outside parties over the Internet. And work
rolls which don't have access to the Internet.
The Web rolls don't scale. I think the limit right now is two, I don't know if they're going to scale it.
But the purpose of the worker roll is for scalability and they can be large number of work rolls can
be deployed. Currently it's still two because Azure is in early stages. There are some tokens that
allow you to have 25 but they don't fully work always.
But anyway soon they will be able to deploy much more work rolls. Then there's a storage, which
is in the form of blobs, cues and tables. We're only going to use blobs and cues here. And the
means of communication between the Web roll and the work roll is through storage.
So here is how a typical write request, let's say, would work in our system. So the client performs
an http request to the Web roll. The page loads and the Web roll places the request in a cue on
which the workers are waiting. Now a worker picks up the request from the cue, does some
processing. Maybe he gets some blobs from storage, and then once he's done and has the
result, he places it in a blob, in an answer blob, on which the Web rolls are waiting, basically the
Web rolls tells the client in which blob to put the result.
Once the Web roll gets the result back it sends it back to the client. And the storage and the Web
rolls are not necessarily in the same, stored in the same datacenter. Okay. So here's, for
example, the average read latency for the no security, for just the confidentiality and the full
security case.
We can see that for no security it's 0.6 seconds. It's kind of high. However, we'll see that through
put is good. And it's kind of high because storage and work rolls are not necessarily co-located
and there's all these run trip times between client, work rolls, storage and so forth. Maybe in
future releases it's going to be more efficient. For confidentiality, which is which is the light test
form of security that people usually have nowadays it's slightly higher.
And for full security, it's about 0.1 seconds above confidentiality. And this is not necessarily
because of the cryptography, but it's more because of the fact that the client receipts are each
stored in a blob so that the cloud accept the receipts it gets from the clients in case the enterprise
asks them for it. So he stores the blob.
I could improve performance by batching multiple receipts and storing them in the same backlog
because have access to the storage takes some time.
>>: The blob size affects the performance?
>> Raluca Popa: In read and write?
>>: No, I mean like if encryption/decryption, if you have to do something either on the client side,
server side -- probably not server side -- on the client side I have to encrypt a huge file, if your
blob is a huge -- it certainly will increase latency, if it's very small it will decrease latency.
>> Raluca Popa: I agree.
>>: But on the other hand if the blob is too small they have way too many receipts.
>> Raluca Popa: That's true. What we do is we just have a typical 4 K blob store and it's true
that for a larger blob the overhead of crypto, like one receipt, it's much smaller and it's actually I
think -- it's actually saving efficiency, because through put as we'll see is good. Just latency is
slightly too much because of all these round trips.
So for writes with no security we have 0.7 seconds and with full security we have 1.6 seconds.
This is because we store more receipts in that case and I will try to look into like batching them
and not accessing blob storage so often. Yes.
>>: Is this in contention?
>> Raluca Popa: This is write latency. Contention. It's just one client doing 100 writes and
checking the average.
>>: Okay.
>> Raluca Popa: But they're not batched. Like one after another. When one finishes starts
another one.
>>: And this is 4 K.
>> Raluca Popa: 4 K.
>>: Is this the time to encrypt the blob to the client?
>> Raluca Popa: Includes the confidentiality and full security, no such thing, no encryption.
So for through-put, this is a large file, 20 megabites is sent. And so we can see that for no
security it's about 4.4 megabites per second through-put.
Confidentiality is slightly less than full security is slightly less, about four megabites per second.
So the difference is not a type.
Write through-put is slower, and that's because of writing blobs is slower. So we can see that no
security is about 370 kilobytes per second and for full security about 340 kilobytes per second.
So basically the bottom line is adding the security to our system doesn't incur much costs
according to the baseline, I mean compared to the baseline.
>>: On the other hand, it's just like your network is typed to the cost, to the clouds storage is so
narrow, see what I'm saying? Without anything you only achieve for 300.
>> Raluca Popa: But average -- I'm sure they're going to improve it. It's like in very early stages
and it's not even billing right now.
>>: Do you realize if the pipe is so narrow you see your difference is very small, doesn't say
much.
>>: He wants to redo this experiment and only look at the server, the client.
>> Raluca Popa: I see.
>>: No, no.
>>: Basically I just want to say that the latency you have asked a lot of information but through
put -- and narrow part is very narrow. See all the differences is really small but doesn't say much.
>>: Produce security confidentiality your write could be -- you don't have to do these serially,
because you're just writing data. So you could send it all at once and get rid of all that latency
and have it through but with these are you waiting for the response before you do the next write.
>> Raluca Popa: This is just one large file writes. It's sent all at once.
>>: It's sent all at once. So it's going into ->> Raluca Popa: The tickets [phonetic].
>>: All the blocks get written in parallel, basically?
>> Raluca Popa: Ah, so what happens is the blob storage level, I mean what I do is I do -- no,
served sequentially.
>>: Is this a test bed you created or is this the actual?
>> Raluca Popa: I created. I used my storage system and I sent one big file and I put it into
storage, yeah.
>>: Storage [indiscernible] remote.
>> Raluca Popa: Remotely. On the cloud.
>>: On data centers.
>> Raluca Popa: Yes.
>>: Did you measure CPU utilization? Initially for performance we don't care, but modern
datacenter servers green energy air conditioning power consumption, we care.
>> Raluca Popa: So I didn't really measure it but later I have some results to have multiple
threads on the same worker. And since they are quite parallel, I would say that there isn't that
much high CPU utilization.
>>: That doesn't make any sense.
>> Raluca Popa: I will look into it.
>>: Just doing straight unencrypted reads and writes isn't going to touch the CPU function at all.
It's taking the data and shoving it to disk and encryption is going to impose a lot more CPU
overhead.
>> Raluca Popa: I did not look explicitly at that. But anyways, here is -- so basically what this
wants to say is that if the block size is larger, you can have better performance. Because I write
this file all at once in one blob. So I don't write it -- I don't split it in blocks and write them
separately.
Anyways, so this shows culling the number of workers, as I mentioned unfortunately I could only
get two workers, because Azure currently does a limit for user account. However, I tried to have
like two, four, three, four threads per each worker. And I measured the number of requests per
second, increasing number of workers, and we can see that even though I only got to about eight
threads, it looks like it scales linearly.
So auditing performance. So this graph shows that running time is depending on the number of
receipts. This is just one thread going through the chain of receipts trying to audit them. And I
put the access in logarithmic on both sides because the numbers were getting too large and you
would only see the one point.
>>: Interesting to see audit overhead as a fraction of the overhead to actually do the writing. So
if you're doing -- if you're consuming X resources a month, what's the fraction of X that your audit
is consuming, any intuition for that?
>> Raluca Popa: I don't think it's that high, because one blob for one blob auditing, so let's say
two subsequent writes for one blob is an order of microseconds.
So I think, for example, 100 million receipts are going to take four minutes to audit in one thread.
And I'm assuming that maybe one block will only have about 1,000 changes in a month. Or
maybe let's say 10,000, or 100,000 in a month. And so I don't think it's a significant amount. But,
yeah, it's an interesting experiment to run.
>>: Do you get a receipt on [indiscernible].
>> Raluca Popa: You get the receipt, yes.
Anyway, I also looked at paralyzing auditing, and I didn't produce a graph. But it looks linear and
we'll put it in a subsequent paper.
>>: [indiscernible] do you have any intuition?
>> Raluca Popa: Why wouldn't?
>>: Yeah.
>> Raluca Popa: There's still some setup code among the codes. Yes, it's linear. It's proof of
concept.
>>: Do you have the CPU check something, why it shouldn't be [indiscernible] what it should
more look like?
>> Raluca Popa: Yes. But it's a proof of concept. I guess there's still some part of just one
person that has separating chunks for different threads and then the threads go on and get
audited.
Okay. So in conclusion, we provide a security-enhanced SLA and we provide a novel secure
cluster system that provides confidentiality, integrity, rationalizability and freshness and it's
scaleable to the enterprise size.
We're also looking on search, but I did not include it here because it was too much material.
Thank you.
[applause].
>> Raluca Popa: Yes.
>>: I have a question. If you use [indiscernible] do you have any intuition like which one was
more faster in terms of performance that you to drop, do you pick one to drop, which one would
you drop to save performance.
>> Raluca Popa: Writes realizability and freshness kind of happen together because they need
the receipts. If you drop the two, then you don't have the receipts and you don't have the auditing
anymore either. So confidentiality and integrity are the easiest to achieve. But the problem then
is you don't have fresh writes, fresh reads and writes. The most expensive are the last two. I
think they're about the same because you need the receipts.
>>: So this tool applies to unstructured data stored in-house [indiscernible] so it's stored or not.
>> Raluca Popa: To extract the data from?
>>: Yes, structure the data in the CPU, in the database.
>> Raluca Popa: So you can protect individuals ->>: [indiscernible].
>> Raluca Popa: I mean, you can protect the files in the table stored, like some connection
between various files, like consistent with various files, we don't have that because we treat the
files independently. Just because we treat the files independently we allow concurrent updates
which gives us scalability. If you want them to be -- if you want them to be together, like if you
want them to be consistent with each other, then you should treat them basically like one file in
terms of receipts. Like all the receipts for the two blocks need to be serialized so that there's a
change you need to do, as opposed to having just one chain of receipts for one block, you should
have one chain of receipts for the two correlated blocks together. So yes?
>>: I need a good read model. If the cloud is [inaudible], and the client is Joe the Plumber, who
is the enterprise?
>> Raluca Popa: Okay. So what happens is so we look at enterprise like start-up company. So
the enterprise is the start-up company, like a bunch of servers on the enterprise.
>>: Who are the clients?
>> Raluca Popa: They're employees. One of the main goal is storability, huge companies who
want to store there data in there and they have a lot of employees and scaleable access control.
>>: [indiscernible].
>>: Is the employee.
>> Raluca Popa: Yes, it can be start-up customer, can be start-up employees.
>>: Sounds like two of them.
>> Raluca Popa: Huh?
>>: Start-up employees.
>> Raluca Popa: Then the customers as well. The customers as well. Anyway, if you would like
to apply this to the personal storage case you can and enterprise is the owner and the people
who with whom he shares the file are the employees, the clients here. Yes, or friends.
[applause]