The S3 client can specify two headers for SSE-KMS:
X-Amz-Server-Side-Encryption-Aws-Kms-Key-Id: arn:aws:kms:region:111122223333:key/<32-char keyId>X-Amz-Server-Side-Encryption-Context:
| AWS doc | Confirmed |
|---|---|
| key ID is 32 byte string | [x] |
| The encryption context is not stored on S3 | [ ] |
| The encryption context is logged (CloudTrail) and must not contain sensitive information | [ ] |
| The same context must be provided for a GET using SSE-KMS - otherwise decryption fails | [x] |
| The encryption context can be used as part of access policies (GrantConstraints) | [ ] |
| AWS may add values to the encryption context (like the bucket/object name) | [ ] |
| It's the client's resposnability to store the encryption context | [x] |
The S3 server needs an active connection to a KMS. A KMS may be a single point of failure The S3 server requires only two KMS functions:
GenerateKey: Generates a new key-pair (K1, K2) whereK2 = KMS_Encrypt(K1).DecryptKey: Returns a plaintext key (K1) given an encrypted key (K2) and the correct key-ID.
All other features provided by the KMS are not required to support basic KMS functionallity. Features like key-rotation, logging, ... can be / are implemented directly by the KMS - the S3 server need not take care. However e.g. logging can be implemented by the S3 server (too).
How should the S3 server configuration (process) look like:
- The KMS may be a local or remote service.
- Different KMS may require different login/authentication mechanisms. (password, certificates, token-based, ...)
- It's not obviuos whether the S3 server should support multiple KMS at the same time.
- How should the CLI / config-file configuration look like.
- How should the S3 server route different client requests. Based on key-ID region?!
- How should the KMS be configured/managed? One approach can be Admin-API. For example for setting a customer-master-key (CMK) or doing a key-rotation. However (advanced) KMS configuration may be KMS-implementation depended.