Skip to content

B. Types of encryption

Jump to bottom
Ashish Pandey edited this page May 4, 2017 · 1 revision

3 types of server side encryption:

1. SSE

  • s3 http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html
  • Server-side encryption is about protecting data at rest. Server-side encryption with Amazon S3-managed encryption keys (SSE-S3) employs strong multi-factor encryption. 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. Amazon S3 server-side encryption uses one of the strongest block ciphers available, 256-bit Advanced Encryption Standard (AES-256), to encrypt your data.
  • Amazon S3 supports bucket policies that you can use if you require server-side encryption for all objects that are stored in your bucket.

2. SSE-C

  • http://docs.aws.amazon.com/AmazonS3/latest/dev/ServerSideEncryptionCustomerKeys.html:
  • Using server-side encryption with customer-provided encryption keys (SSE-C) allows you to set your own encryption keys. With the encryption key you provide as part of your request, Amazon S3 manages both the encryption, as it writes to disks, and decryption, when you access your objects. Therefore, you don't need to maintain any code to perform data encryption and decryption. The only thing you do is manage the encryption keys you provide.
  • When you upload an object, Amazon S3 uses the encryption key you provide to apply AES-256 encryption to your data and removes the encryption key from memory.
  • Important
  • Amazon S3 does not store the encryption key you provide. Instead, we store a randomly salted HMAC value of the encryption key in order to validate future requests. The salted HMAC value cannot be used to derive the value of the encryption key or to decrypt the contents of the encrypted object. That means, if you lose the encryption key, you lose the object.
  • When you retrieve an object, you must provide the same encryption key as part of your request. Amazon S3 first verifies that the encryption key you provided matches, and then decrypts the object before returning the object data to you.
  • The highlights of SSE-C are:
  • You must use https.
  • The ETag in the response is not the MD5 of the object data.
  • You manage a mapping of which encryption key was used to encrypt which object. Amazon S3 does not store encryption keys. You are responsible for tracking which encryption key you provided for which object. ○ If your bucket is versioning-enabled, each object version you upload using this feature can have its own encryption key. You are responsible for tracking which encryption key was used for which object version. ○ Because you manage encryption keys on the client side, you manage any additional safeguards, such as key rotation, on the client side. Caution If you lose the encryption key any GET request for an object without its encryption key will fail, and you lose the object.

  • Amazon S3 will reject any requests made over http when using SSE-C. For security considerations, we recommend you consider any key you send erroneously using http to be compromised. You should discard the key, and rotate as appropriate

    for more visit link

3. SSE KMS

AWS KMS lets you create master keys that can never be exported from the service and which can be used to encrypt and decrypt data based on policies you define. You can perform the following management actions on master

  • Create, describe, and list master keys
  • Enable and disable master keys
  • Set and retrieve master key usage policies (access control)
  • Create, delete, list, and update aliases, which are friendly names that point to your master keys
  • Delete master keys to complete the key lifecycle
Clone this wiki locally