With the increase of piracy, protecting media content is one of the key concerns of many publishers. In this article, we will outline the most popular method for content protection with the HTTP Live Streaming (HLS) protocol: AES-128 content encryption.
Content Protection
The need for content protection has been recognised by many different streaming protocols, which have added support for content protection in various forms and flavours. AES-128 encryption has been present in the HLS specification from the first draft of the protocol, putting content protection high on the priority list. In fact, there are two encryption schemes which are supported by HLS:
- AES-128 encryption: This means media segments are completely encrypted using the Advanced Encryption Standard with a 128-bit key. It also allows for the usage of initialisation vectors to optimise the protection.
- Sample-AES: In this case, the individual media samples are encrypted using the AES-standard. With this encryption level, the stream container is not fully encrypted. Also, how the encrypted samples are encapsulated, depends on the media format of the segment.
In practice, AES-128 is the most commonly used method for HLS encryption. This method is also often the easiest to achieve using standard streaming servers and tools.
How safe is this AES-128 protection?
The first question when dealing with content protection is often: "How safe is this protection?". In order to understand this, let's look at what AES-encryption really is. AES is a symmetric encryption algorithm. It was designed to be efficient in both hardware and software. The algorithm is used worldwide and was adopted as the standard encryption algorithm by the U.S. government for encrypting sensitive data. Furthermore, it is the basis of most of the DRM systems available, for example Microsoft Playready, Widevine and Verimatrix. The usage of AES encryption recently became part of the common encryption standard for MPEG-DASH as well. In general, it might be safe to say this level of AES encryption will not be broken soon.
The AES encryption itself can be declared safe. However, encryption is only as safe as its weakest point. It is also necessary to have a look at the security of the decryption key. This is the area on which many DRM technologies focus. They deem key protection essential and often employ very obscure or complex schemes to retrieve decryption keys. With AES-128 content protection, key retrieval has been kept simple, making it easy to implement. It also leaves plenty of freedom to make key protection as simple or advanced as possible.
How to protect the decryption key?
The HLS specification mentions only one aspect of key retrieval: the URL from which the key can be loaded should be a part of the manifest file. Protecting this resource is up to the publisher itself. Most often, we see a number of different approaches to protecting the decryption key:
- Protecting the manifest: This relies on hiding the URL to the decryption key. It does not provide a high level of security as the URL might leak or could be intercepted on the network.
- Using authentication cookies: Authentication cookies can be sent by the player with the key request. This allows the key server to check which user is requesting the key. If the user is not allowed to access the stream, the key will not be returned. As a result, only users which have proper authentication will receive the decryption key.
- Leveraging signed URLs: Signed URLs can be used by providing unique manifests to each user. A user-specific manifest will then contain a link to the decryption key, containing an authentication token. The server can then check the authentication token and determine if the key can be accessed, or not.
Using AES-128 encryption in practice
It is now of course the question how AES-128 encryption can be used in practice. Using AES-128 encryption can be done by encrypting your media files and signalling this using the EXT-X-KEY-tag within the manifest file. This tag signals the URL to the decryption key. It should be placed before the first segment, which is encrypted with the given key. There are two extremes in which this tag can occur:
-
One time on top of the manifest. This means all segments are encrypted with the same decryption key. In case the decryption key is intercepted, the entire stream can be decrypted.
-
Before each segment with a different URL. This approach allows you to encrypt each segment with a different key. A key allows you to decrypt a single segment, which contains only a few seconds of media information.
Between these two extremes, you are free to choose your own frequency of refreshing the encryption keys. Below you can find an example manifest which rotates the encryption key every two segments:
#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-KEY:METHOD=AES-128,URI="https://security.theoplayer.com/sequence-1.key"
#EXTINF:10.0,
http://media.theoplayer.com/video1/sequence-1-segment-1.ts
#EXTINF:10.0,
http://media.theoplayer.com/video1/sequence-1-segment-2.ts
#EXT-X-KEY:METHOD=AES-128,URI="https://security.theoplayer.com/sequence-2.key"
#EXTINF:10.0,
http://media.theoplayer.com/video1/sequence-2-segment-1.ts
#EXTINF:10.0,
http://media.theoplayer.com/video1/sequence-2-segment-2.ts
#EXT-X-ENDLIST
Do you still have questions about AES-128 encryption in HLS and how to better protect your content? Don't hesitate to let us know. Our team of experts will be glad to help you. Click the button to go to our dedicated AES-128 demo page.
