Skip to content

S3 Encryption Support

AWS S3 offers multiple encryption options for stored data.

First, server-side encryption (SSE) can used to secure data-at-rest, which encypts the incoming object data as it is persisted into the storage layer. It protects user data from prying eyes that have access to the physical media. For example, assume a storage disk is replaced in an S3 data center and the replaced media is not immediately destroyed. In that case, someone could get hold of the disk and access the data that is stored. With SSE enabled, the incoming data is encrypted before it is stored and the encryption keys used are maintained separately.

There are three ways to maintain the encryption keys for SSE:

  1. Amazon S3-managed Encryption Keys (SSE-S3)

    In this scenario the keys are managed by S3 itself and are only usable for S3 services.

  2. KMS-managed Encryption Keys (SSE-KMS)

    Here the keys are managed by a key management system (KMS), which is a separate AWS service (part of the AWS IAM service). These keys can be used for multiple AWS services, including S3. Note that each object is encrypted using a dedicated key, and the KMS key is used to secure the per-object keys.

  3. Customer-provided Encryption Keys (SSE-C)

    The last option is for users to provide a key when writing and reading S3 objects. These keys have no relation to anything else in S3.

Of note is that SSE is only protecting the data at rest, that is, how the data is delivered is a separate concern.

This leads to the second encryption option for S3, which is client-side encryption (CSE). Here the client is tasked to encrypt the data before it is sent to S3 and handles the security of data-in-transit. In other words, when employing CSE, the client is sending secure data to S3 which stores it as-is as the object data. Any possible eavesdropping on the network during the data transfer will not yield any readable data. This also applies to data-at-rest, since only encrypted data is stored by S3 transparently, covering both aspects of security.

There are two ways of maintaining encryption keys for CSE:

  1. KMS-managed Encryption Keys (CSE-KMS)

    This is the same as for SSE, that is, the KMS in the IAM service is used to manage shared keys. The client can use the key ID (the ARN) to refer to a key, which is then accessed by the client for encryption and decryption purposes. Note that each object is encrypted using a dedicated key, and the KMS key is used to secure the per-object keys.

  2. Client-side Master Keys (CSE-C)

    Another option is to provide a local, client-side only key that is used to encrypt and decrypt locally. These keys are have no relation to anything else in AWS.

Both methods can be combined too, in case where clients only sometimes encrypt data. For S3 and SSE, the CSE is completely transparent.

Supported Encryption

The Okera Platform does not support any of the client-side encryption options, since S3 has no knowledge of the data being secured or not, and Okera does not currently have a way to store this metadata. In other words, there is no metadata with the S3 object that could be used to determine the encryption type and key management option.

For server-side encryption, Okera supports only SSE-S3 and SSE-KMS. The former is handled completely transparent and requires no changes to the Okera setup.

In case of KMS-managed keys, the Okera servers need extra IAM permissions to access the KMS service and get the encryption keys, as referenced in the object metadata. For that, the odas-iam-role role (see the AWS Prerequisites documentation) needs to be given the following extra KMS related permissions:

    "Version": "2012-10-17",
    "Statement": [
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
            "Resource": "*"

With these permissions the Okera Enforcement Fleet workers are allowed to access the SSE secured objects, with S3 doing the actual work of accessing the keys and decrypting the data before the transferring the readable object content.

For cross-account permissions you need to add the account under which the Okera workers are running as an external account to the AWS account's IAM service that hosts the KMS-managed keys.

Adding an external account to the AWS KMS

Support Matrix

The following table summarizes the supported S3 encryption types.

Type Keys Supported
Server S3-managed Yes
Server KMS-managed Yes1
Server Customer-provided No
Client KMS-managed No
Client Client-provided No

Notes: 1 Requires KMS permissions