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 supported 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 into the content protection spectrum

There are multiple levels of access and protection.

  • 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.

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 secureAMD configuration

  • You can use the ​Akamai​ "Shared Certificate."This is a secure certificate that requires you to 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 "" or "" domains (and you use this specific hostname in the path to your content.) You set this up via a Property Hostname in the Property Manager Editor, when creating 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 ​Akamai 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 a manifest deviates from this specification, Media Encryption will not work.

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

Third-party key servers aren't supported with Media Encryption.

Review the known issues

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

We recommend Token Authentication

​Akamai​ recommends that you also include Token Authentication that's also available in the Segmented Media Protection behavior. It also protects client access to the key file by 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 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 Media Encryption behavior isn't found. So, the key isn't generated and the stream fails.


This scenario only works if you've removed the Segmented Media Protection behavior from the Default Rule, or left Media Encryption disabled in the Default Rule and enabled it in another rule. 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.

Enable Media Encryption (HLS-format media, only)

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 Segment Encryption slider to On and define applicable options:

    • Encryption Mode. Defaults to AES 128, and must remain at this setting.

    • Initialization Vector (Optional). Use this field to define a unique initialization vector when generating the Encryption Key file. Click the cycle button (   ) to automatically generate a value. You can manually input a value of up to 32 alphanumeric characters. More on this field below.

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

Should you use an Initialization Vector (IV)?

Use of an IV is purely optional, and we recommend that you leave the Initialization Vector field blank to have the system automatically calculate this value using the target content's player manifest.

  • If you choose to include one. The explicit value you set is included in the "key" tag, as the "IV" value. When you incorporate this, the IV is fixed and used for each request.

    aka_me_session_id=<unique session_id>",IV=<IV>
  • If you leave this field blank. The media-sequence-number is pulled from the Player Manifest. No IV is listed in the key tag, and the media-sequence-number is used as the IV. Since the media-sequence-number is unique based on what's been requested, this offers some randomness and added security.

    aka_me_session_id=<unique session_id>"

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 cannot 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.

Some symptoms of this issue include the following:

  • 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 in your Media Origin), it's denied for processing, because it's already encrypted. Also, the pass-through of pre-encrypted content isn't supported. Attempts to do so are met with an error when the content is recognized as encrypted.

Did this page help you?