Skip to content

Instantly share code, notes, and snippets.

@aead

aead/S3-SSE.md

Last active March 16, 2018 20:16
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save aead/9b2dc9068406e72fe8bcddfba695fa0e to your computer and use it in GitHub Desktop.
Save aead/9b2dc9068406e72fe8bcddfba695fa0e to your computer and use it in GitHub Desktop.
Download ZIP
AWS S3 server side encryption
Raw
S3-SSE.md

Server-Side-Encryption

AWS S3 offers three different types of server-side encryption (SSE):

  • Server-Side-Encryption (at rest) a.k.a SSE-S3
  • Server-Side-Encryption using a KMS a.k.a SSE-KMS
  • Server-Side-Encryption with customer keys a.k.a SSE-C

1. Server-Side-Encryption (SSE-S3)

  • The server encrypts objects automatically. (Very similar to disk-encryption)
  • The client specifies SSE-S3 by setting the header X-Amz-Server-Side-Encryption: "AES256.
  • The client has no control about how objects are encrypted.

1.1 Implementation:

  • Can inlcude a custom KMS (maybe enterprise users want that). Than SSE-S3 keys are managed by KMS.
  • Can be implemented using master-key approach. Than SSE-S3 keys are derived/encrypted from/by master key. Simpler to setup in small deployments.

2. Server-Side-Encryption with customer provided keys (SSE-C)

  • The client is responsable for managing keys.
  • The client provides the encryption key for every GET/PUT/HEAD/COPY reuqest. Requests without an (correct) encryption key are rejected.
  • The server must not store the key.

2.1 Implementation

Already implemented.

3. Server-Side-Encryption using a KMS (SSE-KMS)

  • All objects are encrypted by the S3 server using an unique object encryption key OEK
  • The OEK is generated by a KMS and handed out to S3 server(s). The S3 server(s) are responsible to store the OEK in encrypted form. The KMS does not store OEKs.
  • The KMS returns two "versions" of the same OEK:
      1. The plaintext OEK
      1. The sealed/encrypted OEK. The sealed OEK is encrypted by the KMS using a customer master key CMK.
  • The CMK never leaves the KMS and is specified by the KMS/S3 operator(s).
  • Each CMK is referenced by (at least one) unique key ID.
  • The key ID is the mapping from object to CMK. The user tells the server which CMK to use so that the server can:
    • request a new OEK (and its sealed form) from the KMS for PUT
    • ask the KMS to decrypt the sealed OEK for GET

3.1 Purpose

A KMS provides no/very small extra security. The main argument for using a KMS is management/compliance. Usually a KMS provides:

  • Logging: Who has used which key at which point in time? Which data was accessed?
  • Access control: Who can access which key (and also which data) at which point in time?

3.2 Implementation

The KMS can be seen as an external service with its own API. The API contains some basic operations:

  • NewDataKey / NewObjectKey / NewKey: Returns a new OEK and its sealed form using a CMK specified by a key ID.
  • DecryptDataKey / DecryptObjectKey / DecryptKey Returns the OEK if a valid sealed OEK and key-ID are provided

The two basic operations are sufficient to use the KMS on the S3 server.

Also the API can contain advanced features like key-rotation / key-versioning and whatever feature people believe is advantageous. (Esp. required by enterprise users because of compliance / legal requirements).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment