Media Encryption & AMD

This functionality encrypts individual media segments, before delivering them to a requesting client.

Information regarding the key used to decrypt content is included in the manifest file associated with the target media, and when the client processes the manifest, it requests this key. A Key Server or License Server provides the decryption key if the user is authenticated and authorized to play the content. Finally, the client uses the decryption key to decrypt and play the media segments.

In Segmented Media Protection (SMP), this is implemented via Session Level Encryption. The stream is encrypted per each user playback session, based on the stream, user, and time or date. An individual session is every new request for a stream and is usually categorized by a request for the stream manifest. In this case, the decryption key is created per session. It's allocated dynamically when a new session is initiated. Each new session is independently encrypted with unique keys, and each separate user needs to access a separate key to decrypt the content.

Supported media formats

Media Encryption is generally available for Apple HTTP Live Streaming (HLS) streams, for Segmented Media Delivery Modes of On Demand, or Live, using ‚ÄčAkamai‚Äč Media Services Live.

Where Media Encryption fits

There are multiple levels of access and protection. Here's where Media Encryption fits into the ‚ÄčAkamai‚Äč content protection spectrum:

  • No protection: Open Access. Anyone can access your content

  • Level 1: Token Auth. An encrypted token in the request is compared against a token you've associated with your content. For added protection, we recommend that you combine Token Authentication along with Media Encryption, via the Segmented Media Protection behavior.

  • Level 2: Geo Protection. This allows access to requesting clients in geographic regions or IP addresses/CIDR blocks you mark as good, or blocks access to clients in regions or IP addresses/CIDR blocks you mark as bad. You can add it to your property via the Content - Targeting Protection behavior.

  • Level 3: HTTPS Protection. Configure your AMD property to access and send content via secure delivery.

  • Level 4: Media Encryption.

  • Most protection: DRM Encryption. This prevents access to only those clients that have been authorized to have a DRM license for the playback environment or content, including additional rights management rules.

‚ÄčAkamai‚Äč attempts to improve the default Media Encryption use case, which is typically one key for each piece of content, by making the content decryption keys session-specific. For example, "User1" and "User2" accessing the same content have different decryption keys.

The Media Encryption workflow

This is the basic outline of the Media Encryption process, once you've enabled it in your AMD property, and associated content is requested by a client.

  1. The client requests the Master Playlist. When the player first targets media, a request is made for the "Master Playlist" and the session key is created. Information about the session key is then appended as a variable value in the query string of all Media Playlist URIs, and this information is sent in a response to the client.

  2. The client requests the Media Playlist. The Media Playlist URI(s) are contacted and the session key is checked and verified. The following are then appended as variable values in the query string for each Segment URI in the Media Playlist:

    • Information about the session key.

    • The media sequence number. This is extracted and calculated for each media segment and could be used as an initialization vector during encryption.

    • The HLS playlist version.

The AMD Media Encryption service appends the EXT-X-KEY tag to the top of the media playlist, and populates it with all of the required attributes. This includes the URI, Encryption Mode, and Initialization Vector (IV). The session key is included as a query string in the Key URL, which is then sent in a response to the client.

  1. The client requests the Key File. The Key URL is contacted and the session key checked and verified again. If verified, the key is sent to the client. If it is not verified or the key is missing, the request is denied (in a response to the client).

  2. The client requests the Segment File. The session key is extracted from the Segment URL and verified. The Media Segment is encrypted during delivery and then delivered to the client where it is decrypted using the same session key that was retrieved earlier.

Before you begin with Media Encryption

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



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

If you're using Media Encryption, deliver all applicable media keys, manifests, and playlists via a secure HTTP connection (https://). Individual media segments can be delivered via a standard HTTP connection (http://) from your origin, but we recommend that your AMD property be set up to use HTTPS, exclusively.

See Define property hostnames for more details.

Manifest specification

Manifest files associated with your target HLS-format content must comply with the formatting described in the HTTP Live Streaming Protocol Specification. If a manifest deviates from this specification, Media Encryption will not work.

AES-128 encryption is used

Only AES-128 is supported for use with Media Encryption in an AMD configuration. This is because it's the most commonly used. Any player you're using must support AES-128.

‚ÄčAkamai‚Äč needs to be your key server

You can't use a third-party key server with Media Encryption. Simply setting up Media Encryption in your AMD property sets ‚ÄčAkamai‚Äč as your key server. There's nothing more you need to do.

Review the known issues

Outside of the requirements discussed here, we keep a list of known issues with Media Encryption. Review these before adding this functionality. This is a living list, and some of these issues may be addressed with a future release.

Enable Media Encryption

To enable Media Encryption, you need to apply specific settings in the Segmented Media Protection behavior.

  1. In the Segmented Media Protection behavior, set the appropriate encryption sliders to "On".

    • HLS Encryption. To protect your HLS streams with Media Encryption.
    • DASH Encryption. To protect your DASH streams with Media Encryption.


DASH Encryption is Tech Preview, only

Unless instructed by ‚ÄčAkamai‚Äč internal staff, leave this option set to Off. We expect its general availability in the near future.

  1. You should enable Token Authentication, too. It's also available in the Segmented Media Protection behavior. It protects client access to the key file by using secure, long tokens.

  2. With settings defined as desired, click Save to apply.

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.

You need to do this because the manifest associated with your target content always looks to /serve.key to find this key. If you don't add this path match, when this AMD property is run for a request, the ‚ÄčAkamai‚Äč edge servers won't be able to find the Media Encryption behavior. So, the key isn't generated and the stream fails.

Known issues with Media Encryption

There are some known issues that currently limit the use of Media Encryption (ME) in some scenarios.


HLS byte-range playlists can't be used with Media Encryption

When Media Encryption is enabled for an HLS stream with byte-range MPEG-TS segments, incorrect byte ranges can be reported in the playlist file. So, when a player transitions from one bit rate to another, it can fail to append the new segment to the previous one in its playback buffer.

Here are some symptoms of this issue:

  • Playback on an hls.js-based player fails. This occurs when the master playlist file is used for the playback of Media Encryption-protected content.
  • Playback fails on ExoPlayer. Similar to the above, playback will fail if the player requesting content was built using ExoPlayer.
  • Audio and video are out of sync. The audio can be ahead of the video after a certain amount of playback, and can progressively get worse.

Existing stream-level encryption not supported

If content served by your AMD property is already encrypted using stream-level encryption (such as data encrypted via a DRM system implemented on your Media Origin), it's denied for processing because it's already encrypted. Also, the pass-through of pre-encrypted content isn't supported. An edge server will recognize it as encrypted and throw an error.