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).
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 is denied for processing, because it is already encrypted. In addition, the pass-through of pre-encrypted content is not supported. Attempts to do so are met with an error when the content is recognized as encrypted.
Third Party Key Servers are not supported
With Media Encryption, Akamai acts as the Key Server.
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.