Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

I just started some work on computation over encrypted data in the cloud. We're still in the early planning stages, and to really understand the kind of security we can offer I need to determine what kind of attacks to expect from an untrusted cloud server. My basic question is whether the cloud represents a semi-honest, covert, or malicious adversary.

My cryptographer's instinct tells me to expect the worst and assume that all untrusted cloud servers are malicious adversaries. However, for many of the commercial cloud services it seems silly to expect them to actively attack their customers. This leads me to think of cloud providers as semi-honest. Am I way off-base here?

share|improve this question
    
It might be silly for Amazon to attack their customers, but that doesn't mean the semi-honest threat model is a good one for treating Amazon's cloud services. See my answer for explanations/details on why. –  D.W. May 9 '13 at 21:06
    
not it is not silly, you never know , how much google/amazon are making of use of customers data for monetizing etc, if not attack their own customers, even this would be threat for a customer –  sashank May 9 '13 at 23:20

3 Answers 3

up vote 8 down vote accepted

It depends upon what trust you have in the cloud. If you don't trust the cloud provider, a malicious model (treating the cloud as malicious) might make sense.

The so-called "semi-honest" threat model almost never makes sense in practice. It amounts to assuming that someone is malicious ... but not malicious enough that they'll deliberately, actively try to subvert your security. That's a very weird kind of assumption to make. The "semi-honest" threat model is basically a theoretical construct that has no good practical motivation in its own right. There may be a few special places where the "semi-honest" threat model might make sense in practice. However, my view is that the "semi-honest" threat model is inappropriate for most practical systems engineering purposes.

Please understand: if you're using (say) Amazon EC2 for your cloud provider services, usually the threat to worry about isn't that Amazon is deliberately out to get you. Rather, the more realistic threat is that Amazon gets penetrated by some malicious third party and the attacker is then out to get you. Or, that an Amazon insider (e.g., one of Amazon's sysadmins) tries to get you. Or, that Amazon has an inadvertent security breach that exposes your data. For conciseness, we often summarize those by saying "Amazon is untrusted" or "the cloud is untrusted", but that doesn't mean that our primary concern is about Amazon the company itself.

Conversely, just because I'm pretty sure that Amazon the company isn't out to get me doesn't mean that it's safe to treat the cloud as trusted. I still have to worry about whether there might be an inadvertent vulnerability or breach in Amazon's systems that lets the attacker take control of Amazon EC2 and thereby attack me. If I'm worried about that sort of thing, I need a protocol that essentially treats the cloud provider as untrusted.

share|improve this answer

It will depends a lot on what kind of customers you're expecting, and what kind of contract you'll have with them.

If you're planning to store information that can't be leaked, at any level, because you told your customers so, well... you can't trust any provider, be it "honest", "semi-honest" or any other category.

Think that someone can attack the provider (the cloud) and copy data from there. Be it a honest provider or not, your data is gone. Think that your customer expects to hide something from everybody, including government. You can't be sure that an Agency or a legal order from a judge won't enforce the cloud to reveal something.

So, if I were in your position, I would consider everybody to be a malicious adversary, not only those "untrusted cloud servers".

share|improve this answer

If you are using Cloud processing service subject to US jurisdiction, and your data is about a non-US person located outside US (i.e the rest-of-the-world), then FISA Amendment Act 2008 1881a authorizes coercion of Cloud provider in secret mass-surveillance from inside the datacentre. This was new - previous FISA was for interception of telcos/ISPs, but 1881a extended to Cloud.

Worse, this can be done for purely political surveillance (i.e. not "law enforcement" or national security per se)

details at http://www.reddit.com/r/1881a/

Indian IT Amendment Act 2008 69(1) has similar (but without the nationality-discrimination) http://cactusblog.files.wordpress.com/2010/01/it_act_2008.pdf

i.e. Amazon/Microsoft/Google can be ordered to install a fat pipe from the inside to the NSA (or RAW), after any SSL decrypted

share|improve this answer
    
Yeah but the documents will still be encrypted in the cloud server, so even if the NSA gets them they'll need to break whatever block cipher we use to encrypt them. –  pg1989 May 13 '13 at 17:23

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.