Many customers have a need to ensure that their mezzanine assets are encrypted at all stages of the processing life cycle. In order to facilitate this, the following must be met:

  • Ingest of asset must use encrypted transport
  • Storage must be encrypted on drop off location
  • Download of asset for transcode / DRM / etc must use encrypted transport

Customer engagements are strongly encouraged to use S3 for asset storage.


S3 offers highly available storage accessible only over an HTTPS API. S3 can be configured to enforce encrypted storage that is transparently decrypted when accessed, provided the client has the correct permissions.

There are 2 options for encryption of assets, one of which has 3 possible implementations.

  • Client-Side Encryption (CSE). This is, roughly speaking, DRM. We encrypt the asset and manage keys and so on ourselves. We will do this for most assets, but this is not appropriate for an asset ingest area.
  • Server-Side Encryption (SSE). Here the S3 storage service will transparently encrypt and decrypt assets uploaded and downloaded to the service. This has 3 further options for managing of keys:

    • SSE-S3. This is the default. A randomly generated key is created for assets in a bucket. Key management is dealt with by AWS. This should also be the default deployment option, unless a customer tells us they are unable to store their assets encrypted (e.g., they have some non-compliant 3rd party tool for S3 communication).
    • SSE-KMS. This uses the AWS KMS service, and comes with a slight cost implication. It gives us the ability to select different encryption keys for different assets in the same bucket. This would be interesting if we are mixing content from multiple providers or customers, but we typically aren’t doing that.
    • SSE-C. This is like SSE-KMS, except that we (or the customer) manages the keys. This might be an attractive option for a customer who wants to know that they have control over our ability to read their source assets.

Further Reading