83

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"?

Hank
  • 933
  • 1
  • 6
  • 4
  • 4
    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 08 '11 at 19:54
  • 2
    @Aaronaught Stolen backups, for example. – Gilles 'SO- stop being evil' Nov 08 '11 at 20:09
  • 1
    @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. – Hank Nov 09 '11 at 01:39
  • 1
    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 09 '11 at 02:12
  • 3
    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 http://aws.typepad.com/aws/2011/10/new-amazon-s3-server-side-encryption.html. Of course you also have the option to perform client-side encryption, which I would personally recommend. – jarmod Feb 05 '14 at 02:13
  • What @jarmod mentioned is also what I've heard from an Amazon representative; it's a tick on an assessment form: "Yes, our data is encrypted at rest" – Jack Apr 29 '14 at 03:03
  • What happens to S3 hard drives after they are end-of-lifed? Do they get melted down or just thrown out in a dumpster? – Simon Woodside Oct 07 '16 at 21:01

7 Answers7

51

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.

David Schwartz
  • 4,203
  • 24
  • 21
  • 4
    **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. – Asherah Nov 29 '13 at 01:31
  • 2
    The assertion, and your assertion in response, are both speculation. There is actually no way to know, and _this_ is the problem. If you need security, but can't verify that it is secure, you essentially have to work on the assumption it is not secure. – Jay Dec 09 '16 at 08:35
  • 1
    @Ashe As you just said, the keys are distributed "to the machines that house the data". That puts the keys and the encrypted data in precisely the same place at the same time. Unless you think those machines all have HSMs, compromising any of those machines would get you both keys and data. – David Schwartz Nov 10 '17 at 12:08
  • 1
    @DavidSchwartz wow, this is an amazingly long-running thread. It does put them in the same place at the same time — but only in RAM, not on the disk. Your post asserted "it seems very unlikely that they store the keys anywhere other than approximately the same places they store the data". It would take a lot more effort to extract them from RAM successfully. – Asherah Nov 10 '17 at 23:14
  • @Ashe I can't agree with that last part. It would just require either physical access to the machine or remotely compromising the machine. (Either of which a employee might be able to do.) The only thing that wouldn't work is finding the hard drives in the trash. (I suppose there might a large set of keys and each machine only having some of the machines some of the time. But then you could just compromise a machine and wait for it to get more and more keys.) So what does the encryption buy you? Still, not much. It doesn't make two things you have to compromise. – David Schwartz Nov 10 '17 at 23:39
  • 1
    Obviously AWS now documents how they store the data and keys (http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html). "Amazon S3 encrypts each object with a unique key. As an additional safeguard, it encrypts the key itself with a master key that it regularly rotates. " – wanghq Nov 14 '17 at 22:28
  • This is to prevent others getting data from publicly accessible buckets, as the key has to be provided when requesting an object. Others can still list the bucket contents, but they can't get the unencrypted object content unless they provide the key in the request. – igracia Mar 22 '18 at 08:04
  • @igracia See wanghq's comment above. You're talking about something completely different. – David Schwartz Mar 23 '18 at 09:00
  • I thought that SSE-S3 worked in a very similar way to SSE-KMS when it comes to retrieving objects from public buckets: you can list the metadata, but you won't be able to get the object unencrypted. Is that only for SSE-C and SSE-S3? – igracia Mar 27 '18 at 13:20
11

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.

  • 2
    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. – Hank Nov 09 '11 at 01: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. –  Nov 09 '11 at 01: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 09 '11 at 23:44
7

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.

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
  • 4
    Since this question is about server side encryption when Amazon has all the keys, this does nothing to prevent deliberate leaks by Amazon themselves... – Chris Dec 04 '18 at 23:38
5

Like many of you mentioned, this does indeed give you an extra level of security (remember layers?) if the disks lost or accessed somehow. But I find it incredible that no one has mentioned security compliance certifications yet.

I know. Some of you reading this might already be thinking "Certifications are bullshit". Well... they can be. But when done properly, they can assure some important features and they are a really big deal in the enterprise world. Especially to providers of IaaS where their employees need to have a low level of access to all your data and code to provide the service.

So the threat here is not AWS having access to the data (they have) but a particular AWS employee having access to the data.

I don't know all of the programs listed here for sure. But I'm pretty sure some of them require separation of duties. This would mean that AWS had to convince an external auditor that they implement separation of duties properly when security features require it. In this particular case this would mean that the AWS guys that have access to the encrypted data don't ever have access to the encryption keys, and the guys that can have access to the encryption keys, don't ever have access to the data.

So yes, you already have to trust AWS with both the keys and the data but these certifications are supposed to assure you that they control who (inside the company) have access to what. An extra level of trust which is also a big part of security.

On the other hand, AWS customers that want to be certified too will need this too for compliance with encryption of data at rest. This can only be valid if they also provide assurance that the keys are properly stored and managed. With this feature and AWS certifications, they can delegate that to AWS.

rui
  • 151
  • 1
  • 1
  • This is definitely a good theory, but to be a complete answer, it would be nice if you could back this up with a source. – Tom K. Oct 05 '17 at 08:44
5

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.

Theo
  • 151
  • 1
  • 2
2

As other answers largely imply the feature is nearly useless, you need to look at the bigger picture of information security best-practices and regulations to understand why it exists.

Current interpretations of U.S. privacy laws (e.g. HIPAA, PCI) require all customer data to be encrypted at rest. If you think data stored at Amazon should be exempt from this requirement, try explaining your reasoning to your corporate Legal Counsel. Good luck with that. The rules are one-size-fits-all and apply equally to a hard-drive in a laptop as to a disk array in a "secure" data center.

While Amazon employee theft might be a concern to some, the feature's main selling point is protecting companies from non-compliance with applicable best-practices and regulations that may require data at rest to be encrypted.

Alex R
  • 123
  • 5
1

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.

Tom Andersen
  • 121
  • 2