Prerequisites for Media Encryption

There are various prerequisites that must be met, as well as caveats that apply to the use of Media Encryption.

Some components must be delivered via HTTPS

This requirement reduces the possibility of a man-in-the-middle attack that could compromise an encrypted media stream.

If you are incorporating Media Encryption, all applicable media keys, manifests, and playlists must be delivered via a secure HTTP connection (https://). However, individual media segments can be delivered via a standard HTTP connection (http://). So, except for delivery of your segments, Media Encryption can only be enabled in a secure AMD configuration

  • You can use the Akamai “Shared Certificate.” This is a secure certificate that requires you use a fixed Edge hostname to deliver content to a requesting client. The hostname is comprised of a prefix you define combined with either the “akamaized.net” or “akamaihd.net” domains (and you use this specifici hostname in the path to your content.) You set this up via a Property Hostname in the Property Manager Editor, when creting your AMD property.
  • Using a Standard TLS Certificate via your Unique Hostname. This requires that you create a Standard TLS (L1) certificate and associate it with your AMD property, via a Property hostname to Edge hostname association. You can create this certificate using our Certificate Provisioning System (CPS) in Control Center. Contact your Account Representative for details on this component and its use.

Manifests must comply with the HLS specification

Manifest files associated with your target HLS-format content must comply with the formatting described in the HTTP Live Streaming Protocol Specification.

If they deviate from this specification, Media Encryption will not work. At the time of this publication, this specification can be found at: https://tools.ietf.org/html/draft-pantos-http-live-streaming-20

Only AES-128 encryption is supported

Although the HLS standard allows for both AES-128 (complete media segment encryption) and SAMPLE-AES (only encrypts the audio and partial video data), only AES-128 is supported for use with Media Encryption in an AMD configuration (as it is the most commonly used).

Akamai must serve as your Key Server

With Media Encryption, third-party key servers are not supported.

Review the known issues

Outside of the requirements discussed here, we maintain a list of Known issues with Media Encryption. Review these before adding this functionality. These issues specifically apply to things that are currently not supported for use, and we may fix them with a future release.

We recommend Token Authentication

We also recommend that you implement Token Authentication via the SMP behavior. Once in place, it also protects client access to the key file using secure, long tokens.

Are you defining specific path matches in a custom rule?

If you incorporate a custom rule with specific path matches and apply Media Encryption to encrypt content in those paths, you also need to include the proper path to the Media Encryption "key file" as a path match: "/serve.key*."



This is necessary because the manifest that is associated with your target content always looks to /serve.key to find this key. So, if you don't add this path match, when this AMD property is run for a request, the Media Encryption behavior isn't found, so the key isn't generated and the stream fails.

Note: This scenario will only work if you've removed the Segmented Media Protection behavior from the Default Rule, or left Media Encryption disabled in it. Remember that the Default Rule applies to all of your content. So, if you've enabled Media Encryption there, it would override Media Encryption for any specific path matches you set up in a custom rule.