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.
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.
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.
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.
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.
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.
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).
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.
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 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.
To enable Media Encryption, you need to apply specific settings in the Segmented Media Protection behavior.
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.
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.
With settings defined as desired, click Save to apply.
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.
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:
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.
Updated 8 months ago