Review these sections to add media encryption to your AMD property to encrypt HLS-format segments.
The player you use needs to meet some prerequisites.
This reduces the possibility of a man-in-the-middle attack that could compromise an encrypted media stream.
Make sure your player is connecting to the Akamai edge network using HTTPS. This helps protect all applicable media keys, manifests, and playlists during delivery. HTTP connections are not supported. Individual media segments can be delivered through a standard HTTP connection from your origin to edge servers, but we recommend that you set up your AMD property to use HTTPS, exclusively.
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
Media encryption only supports AES-128 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. By adding Media Encryption to your AMD property, you automatically set Akamai as your key server. There's nothing more you need to do.
To enable media encryption, you need to apply specific settings:
About the initialization vector
With previous versions of media encryption for HLS, you could manually define an Initialization Vector. It served as added protection when AES-128 encrypting the key files. If you used the previous version of media encryption, you'll be asked to update to the new version. If you upgrade and go live with your AMD property, any inflight streams that use the initialization vector will result in disablement of service (DOS) in a the player.
The new version of media encryption dynamically creates this value for each session. A manual instance of an initialization vector is no longer needed.
- In the Segmented Media Protection behavior, set the HLS Encryption to "On".
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 for content in those paths, you also need to include the proper path to the media encryption "key file" as a path match:
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, 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 things that can limit the use of media encryption in some scenarios. Before you go live with it, review these key points and take the appropriate measures.
Byte-range playlists aren't supported
When media encryption is enabled for a stream with byte-range 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. Symptoms of this include playback failure and audio and video sync issues. We're looking to add support for byte-range requests with a future release.
Existing stream-level encryption is passed through
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 origin server), it won't be encrypted further. The encrypted content will just be passed through.
Updated 4 months ago