Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Amazon's S3 storage service offers server-side encryption of objects, automatically managed for the user (Amazon's Documentation). It's easy to enable so I'm thinking "why not?", but what kind of security does this really provide?

I guess it prevents someone from wandering into the AWS datacenter and grabbing a hard drive, but that seems very unlikely, and presumably anyone with access like that could also get the AES keys, wherever they're stored.

It doesn't seem to protect the data once it's off the drives, since at that point it's decrypted, and anyone who has your credentials or can intercept the traffic will see the data in the clear. So what's the point, really? Just to say the data is "encrypted"?

share|improve this question
1  
Why not store all passwords in plain text, since nobody's supposed to have access to them anyway? The point of any security measure is to (a) minimize the risk of a successful attack and also (b) minimize the damage if one does occur. –  Aaronaught Nov 8 '11 at 19:54
1  
@Aaronaught Stolen backups, for example. –  Gilles Nov 8 '11 at 20:09
    
@Aaronaught: My question was about what specific attacks this procedure will protect against. I guess stolen backups count, but my point was that it seems like a very narrow range of possible attacks -- someone would have to have physical access to the drives, but not access to the internal system that handles the AES keys. –  Henry Jackson Nov 9 '11 at 1:39
    
Who says that anybody would need physical access to the drives in order to steal unencrypted files? And furthermore why would you expect the private encryption keys to be stored on the same filesystem as the encrypted files? Neither one of those assumptions seem very likely. –  Aaronaught Nov 9 '11 at 2:12
1  
Some enterprises require data at rest to be encrypted but at the same time they don't want to encrypt the data themselves and they specifically do not want to take the risk of losing their keys. I believe that AWS uses a unique key for every object and it further encrypts those unique keys with its own master key. The keys are stored separately from the data. More at aws.typepad.com/aws/2011/10/…. Of course you also have the option to perform client-side encryption, which I would personally recommend. –  jarmod Feb 5 at 2:13
add comment

migrated from stackoverflow.com Nov 8 '11 at 22:19

This question came from our site for professional and enthusiast programmers.

5 Answers

up vote 7 down vote accepted

The short answer is this: We have no idea, probably none.

It might protect against stolen backups. But that assumes Amazon even makes backups. That seems very unlikely. If they did, why couldn't they recover data from their last S3 data loss? It's much cheaper and more efficient just to use multiple live copies.

Also, Amazon would need the keys on every access. So it seems very unlikely that they store the keys anywhere other than approximately the same places they store the data. So if you're imagining a theft of live data devices, it's just as likely that they get the keys as well.

But we don't know how Amazon stores, replicates, and/or backs up data. Nor do we know where they store the keys or how they distribute them. However, I've yet to hear a plausible argument that there exists a realistic threat they protect against. The "stolen backups" theory seems to be based on the false premise that Amazon uses backups when all the evidence suggests they use multiple, live copies with the keys quite nearby.

Dropbox's encryption, however, does protect against one real threat model, albeit a very unlikely one. Dropbox stores their own keys and sends them to you, so it does protect you from a rogue Amazon employee. In exchange, you're vulnerable to a rogue Dropbox employee or Dropbox security bug.

My own opinion is that Amazon added this feature just so they could say that data could be stored encrypted. Some people will mindlessly compare check boxes on feature lists and Amazon wanted a check box on the "secure/encrypted" line. Either way, the weakest link is most likely Amazon's internal network and human security and the validity of the implementation of the code that decides whether to permit accesses or not.

share|improve this answer
    
There's no requirement that the keys be stored on the same disk as the encrypted data. It's perfectly plausible—and indeed, known to be in practice at other organisations—to distribute keys from an internal key server to the machines that house the data. (They mention they regularly rotate the master key, which would further lend support to the idea of a single key source.) Thus the key and data are never stored on the same physical medium, and you'd need to commit quite a heist to walk away with enough to recover the data. –  Yuki Nov 29 '13 at 1:31
add comment

I guess it prevents someone from wandering into the AWS datacenter and grabbing a hard drive, but that seems very unlikely, and presumably anyone with access like that could also get the AES keys, wherever they're stored.

Gilles' comment effectively answers your question, really, but I'll go with a longer answer myself because I'm nice. Disk encryption protects you against data loss when a disk is stolen and the key is not stolen with it. Such examples might be, as Gilles says, stolen backups, but could also be in laptops on the move, or disposed of hard disks to prevent meaningful attempts at salvaging data from your decommissioned disks.

Disk encryption doesn't do much to help you when you put the key and the disk together, because the security relies on the key and if the key can be intercepted, the data can be decrypted. The key and the disk are always in close proximity by necessity when the OS is on and using the disk (every read requires that key) so anyone near it who can reasonably intercept the key should be able to read the data. Of course, you do need to be able to recover the key to effect any kind of attack, so it is slightly harder than just copying a hard disk (but not by much). So basically, yes, you're right.

However, it is still a good idea to protect your disks to minimise the potential loss of data through things like theft and disk disposal. You don't know what or how Amazon do to destroy those disks, so if you have valuable information on there of any kind, having them encrypted is a great idea.

So what's the point, really? Just to say the data is "encrypted"?

That is actually a possible factor. As I say there are tangible benefits from encrypting data are not quite those you might expect, but still exist. That said, I have had customer requirements that data be encrypted on the server end in a similar scenario as a marketing point (we encrypt your data). I think there's an educational challenge there for security people.

share|improve this answer
1  
I understand the value of disk encryption -- I have my laptop encrypted to protect my data in case of theft / loss. But in this case, I feel like the encryption only protects against data theft by Amazon employees, and they are likely to have access to the AES keys anyway. By the time the data gets to the REST API it's already decrypted. It's like Dropbox's encryption, where data is "encrypted" but they own the keys and can unlock the files if they want to. I guess theft of backups or old drives is a valid concern, but I feel like the range of attacks this protects against is vary narrow. –  Henry Jackson Nov 9 '11 at 1:32
    
@Henry basically it is - you're right about dropbox's encryption too. If a malicious employee so wishes, they have the keys and the data in the same place. The only way to work around that is to encrypt locally before upload. –  user2213 Nov 9 '11 at 1:42
    
Is dropbox's encryption the same? All users share files through a master 'map' so they can't use encryption with different keys for each account. I don't know if Amazon uses different keys for each account, though. –  Tom Andersen Nov 9 '11 at 23:44
add comment

When you use S3 SSE anyone with the right IAM credentials can read and/or write your S3 objects, just like if you weren't using SSE. At first glance it looks like the only added benefit is that the data is protected from situations where someone gets access to S3 in an offline manner, like disk drives or backups (which I doubt that AWS makes, it's much more likely that they rely on replication only). However, I think you need to compare it to the alternative to get the real benefits:

There are two components to needed for client side encryption with S3: an encryption key and IAM credentials for authentication and authorization. When using server side encryption you only need IAM credentials.

When using client side encryption you need to distribute the encryption key to all machines that have read and/or write access to the encrypted data on S3. In both cases you also need to distribute the IAM credentials.

If your machines are compromised your encryption key is compromised. You can invalidate the IAM credentials as soon as you know of the break in, and if you use IAM roles or temporary IAM credentials the attacker only has access to your data as long as they have control of the machine (which is bad enough, but might not be the end of the world, you also need to think of what happens next). With client side encryption the attacker will have your encryption key, and all of the data encrypted with the compromised encryption key needs to be reencrypted. With server side encryption you will not have to reencrypt your data, because neither you nor the attacker will have the encryption key.

Even if you don't have a break in there are situations where your encryption key can become compromised, if a laptop is lost or stolen, if someone who doesn't know better e-mails it to someone, or if someone quits and you can't be entirely sure that they didn't take things with them. At this point your encryption key is compromised and you should probably reencrypt all of your data. That can be a lot of work. With server side encryption all you have to do is invalidate the IAM credentials and issue new ones.

There are probably ways to mitigate the issues with client side encryption that I've mentioned above, but to me it feels like using SSE with S3 has fewer downsides than managing it yourself.

Finally, there's the issue of how secure it is to let AWS manage your encryption keys:

According to AWS the system managing the encryption keys is separate from S3, with the intention that if someone breaks in to S3 from the outside they will not get your data because they will not have the encryption keys. If they break into the key management system only (which probably isn't directly accessible from the outside anyway), they will not have your data because they don't have access to it on S3. They need to break into both S3 and the key management system to get to your data.

If they instead break into the physical data center they might get access to both the key management system and S3 at the same time, but the question is if this makes things easier or not. I think that first of all we need to trust AWS to have appropriate security measures in place to stop people from entering their data centers, and secondly that to actually get hold of keys from the key management system you'd need to do something more than simply yank some disk drives. As far as I've seen AWS does not publish exactly how the key management system is protected, more than saying that it is protected with multiple layers of security. It is speculation, but disk encryption is probably one of these.

share|improve this answer
add comment

You can also be protected against someone breaking into the disks at S3 - say (humorously) that the disk that the S3 data was stored on is also a boot drive for a working windows XP box, and someone breaks into the XP machine (not physically - through a hack). They then have all the files on the machine, but yours are encrypted with keys stored on some other box, so all the thieves get is digital rubbish.

Perhaps the likelihood of someone breaking into an S3 array is small, but I side with other posters and bet that the keys are behind another wall. Also they likely use different keys for each account.

So while its not a ton of security, it is there. Dropbox has one giant de-duplicated map for its store, so I don't see how they could encrypt with different keys for each account.

share|improve this answer
add comment

Some things to remember:

  • Amazon is used by a vast number of companies
  • Lots of valuable data in there: financial data, intellectual property etc
  • Criminals like targets like this, that can return high cash value
  • Crime groups are not averse to placing individuals within datacentres, or forcing employees to carry out nefarious tasks

Don't overlook the problem of your data being leaked, deliberately or otherwise, by third parties, even ones as big as Amazon.

share|improve this answer
add comment

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.