HLS Streaming, HLS Encryption & Setting High Secure DRM

What is HLS Streaming?

HLS Streaming ( HTTP Live Streaming) is a video streaming protocol used for video content across desktop and mobile devices. HLS is developed by Apple, which forms the biggest use case for the streaming protocol. Beyond Apple, there is wide support for HLS streaming across Android devices and browsers. Indeed, HLS can be used as a streaming protocol for all major browsers, including Chrome and Firefox.

In HLS Encryption the video files are encrypted using a secure AES-128 algorithm. The AES 128 encryption is the only publicly available security algorithm that is used by the NSA for encrypting its top-secret classified information.

HLS streaming and HLS Encryption can be used for both the cases of live streaming and for Video on Demand streaming (VOD). Because video streaming is over HTTPS, there is no need for a streaming server, unlike RTMP, which requires its own streaming server.

How & Why Apple Developed HLS Streaming ?

Until about 2010, Flash was the most popular video streaming application. It was supported by all desktop browsers. Because Flash utilized the same runtime across all browsers, it meant that video streamers did not have to create separate workflows for different devices. DRM and encryption were also supported by Flash.

Flash was however plagued by security issues. Video playback on Flash was processor-intensive, which caused phone overheating & mobile batteries to drain very fast. For these reasons Apple did not support Flash in the iPhone and in iPad, instead including support for native HTML5 video playback.

Apple created its own specifications for video streaming, which could be used for both live streaming and for pre-recorded video streaming. Android OS followed suit by blocking flash playback from browsers on Android. From the introduction of the smartphone to the emergence of MPEG-DASH around 2015, Apple’s HLS streaming has been the most widely used protocol.

Because of Apple’s continued support for the protocol, encoding for HLS player is an integral element of any video streaming provider’s workflow.

How does HLS streaming work?

In plain vanilla HTML5 video streaming, only a single video file is available for streaming. The download of the complete video file is initiated every time the stream is played. Even if a viewer watches only 2 minutes of a 30-minute video, the full video would be downloaded, causing data wastage at both the server and the user end.

Streaming protocols remove this inefficiency in video streaming. Streaming protocols such as HLS effectively break down a video file into multiple chunks when streaming, and these video files are downloaded over HTTP in succession. HLS streaming uses the same workflow for both live and for on-demand content. The core idea in multi-bitrate streaming is that multiple renditions of each video, of varying resolution, are encoded. High-resolution videos are delivered to large screen devices having high network bandwidth, whereas lower resolution videos are encoded for mobile phones. Encoding for low resolutions also ensures continuous video streaming when the network connection speed drops.

When the user decides to change video resolution, or when the network bandwidth changes, video streams can be manually (or automatically) switched. HLS video streams are encoded using the H.264 standard, which can be played across all devices. Each of the video copies is broken into multiple chunks having the .ts (transport stream) extension.

There is a main index file, called the manifest file (.m3u8 file format), associated with the video stream. The main manifest file contains links to the specific manifest files associated with each unique video stream. Each of these specific manifest files in its place directs the video stream to the correct URL for video playback when streams are switched. This ensures that stream switching is seamless. This process of a manifest file referring to the video stream is the same for both live video streaming and for on-demand video streaming. The only difference for live video is simply that the video files are being encoded in real-time.

Streaming over HTTP has many advantages over using a separate server. For example, firewalls that may be used to block ports used for RTMP are unlikely to affect video streaming over HTTP. No additional cost are required for streaming over an HTTP server.

What is HLS Encryption? Is HLS Encryption effectively secure against piracy?

HLS AES-128 encryption refers to video streams using HLS streaming protocol wherein the video files are encrypted using the AES-128 algorithms. The key exchange happens through the secure HTTPS protocol. If done in a rudimentary way the key for decryption can be seen from the network console by accessing the manifest file. A poor implementation of HLS encryption would result in plugins automatically finding the key and decrypting the HLS encrypted stream, rendering video security ineffective.

There are however methods to strengthen the HLS Encrypted stream. The challenge is to make sure that the key is not exposed directly. These are the options for additional security in HLS Encryption:

• Not including URL to decryption key in Manifest File

Implementations for this vary widely, and are quite difficult by themselves. This method for protecting HLS content may also cause compatibility issues on devices. If done properly however it is definitely a major improvement in video security.

• Using authenticated cookies for HLS Encryption streaming

In this method, the browser of authorized users stores authentication cookies. These cookies are stored with a digital signature, to ensure that they are not tampered with. This ensures that only the authorised user (and not some external plugin) is seeking to fetch content. The following workflow is used for configuring authentication cookies for HLS encryption:

2. 2. 1. Trusted signers are configured, who have permission to create authentication cookies. This configuration is done at the edge location (content delivery network)
      2. Application is developed to send set-cookie headers to authorized viewers
      3. Authorized users store name-value pairs in the cookie
      4. When user requests protected content, the browser adds the name-value pair in the cookie header to the request
      5. The video CDN uses the public key to verify the digital signature in the name-value pair
      6. If the authentication cookie is verified, the CDN looks at the authentication cookie’s policy statement. The policy statement determines if the access request is valid. For example, the policy statement could include the beginning and end time for cookie validity.

For further information on authentication cookies for content protection, you can have a look at Amazon Cloudfront’s documentation.

• Signed URLs can be generated for authorized users

The following workflow is used for configuring signed URLs for HLS encryption:

3. 3. 1. In the CDN trusted signers are created, who have permission to create signed URLs
      2. Develop an application to create signed URLs for protected content
      3. When user requests protected content by signed URLs, the application verifies if they have the authorization to access it
      4. If verified, the application creates a signed URL and sends it to the requesting user
      5. On accessing content through a signed URL, the CDN verifies that the URL has not been tampered with. This is done by using the Public Key to verify the digital signature of the URL
      6. If the signed URL is valid,
      7. The CDN uses the public key to verify the digital signature in the name-value pair
      8. If the signed URL is verified, the CDN looks at the signed URL’s policy statement. The policy statement determines if the access request is valid. For example, the policy statement could include the beginning and end times for the signed URL. For protecting content, this period of validity of URLs should be short – as little as a few minutes is optimal. For this you can create dynamic URLs, that change every few minutes.

For further information on signed URLs for content protection, you can have a look at Amazon Cloudfront’s documentation.

All these 3 steps make the video stream considerably immune to direct download through plugins. However, these methods are still breakable by already available codes and tech hacks.

How is DRM level security for HLS Encryption possible?

DRM requires that the key exchange and licensing mechanism is highly secure and is always out of reach of external tools and hackers. A DRM technology also has additional elements. It delivers a license file, which also specifies the usage rights of the viewer. Usage rights specify the conditions in which the video playback is allowed.
Implementation of these usage rights ensures that the signed key used for decryption can only be used for playback on the viewer’s device. The key would simply fail to decrypt the video stream if the video file is copied to any other device.

DRM adds complex layers of workflow for license management. This workflow includes:

1. Specifying highly detailed usage rights such as-
   1. Limiting video playback on a device to only a fixed number of times
   2. Video access can expire after a period of days if the subscription is not renewed
   3. Limiting the device or screen on which the video can be played. For example usage rights can be used to restrict users to cast their video playback on an external device such as a Smart TV.
2. The license database is also bound to the user’s device, which means that if shared the license and decryption key becomes redundant.
3. Licenses are also signed with the digital signature, which means that they cannot tamper with either during transit over HTTP or when stored locally on the device.

Implementing DRM along with HLS streaming entails considerable modification of the HLS Encryption infrastructure.  At VdoCipher, we have been able to do that and provide a full-fledged proprietary + HLS DRM. We cannot technically say that we are streaming an HLS encrypted stream as it is highly modified. We use a combination of other technologies based on different platforms and are able to roll out a cross-device, cross-browser compatible DRM.

VdoCipher HLS Encrypted DRM Infrastructure Details

1. Upload of Videos (All common formats are supported )
   The content can be uploaded through Dashboard or APIs. Upload from desktop, FTP, DropBox, Box, URL, Server all is supported.
2. Encryption & Transcoding for DRM streaming
   Videos are converted into encrypted files, and multiple qualities & versions for ensuring delivery of quality content at all devices, browsers, and all connection speeds. The encrypted content is stored at our AWS S3 servers and raw videos are never exposed. We have set up our custom EC2 instances for the encoding pipeline, and the resultant files are hosted securely on AWS S3 servers.
3. Encrypted Video Streaming (Modified HLS Encryption & Streaming)
   As discussed above the high-security key and license exchange mechanism supports the transfer of encrypted video data, ensuring HLS DRM level security. Dynamic URLs ensure that each playback is authenticated and the URL cannot be extracted outside the website or app for pirated playback. We use multiple top tier CDNs – Cloudfront, Akamai, Google CDN, Verizon to ensure smooth delivery of content all across the globe
4. Decryption in Video Player & Watermarking
   There is a private communication between our API & the client website. This ensures that its not possible for hackers to decrypt our streams. The One Time encryption that we use is theoretically and practically hack-proof. The website embedding the video content requests a One-time password from the VdoCipher web server using the API. This OTP request is made only after the user is authenticated. The VdoCipher API returns the OTP, which is used to render the embed code. This embed code is valid for a single playback session only. Along with the key a usage policy is specified, ensuring that only a logged-in and authenticated user is allowed to playback the encrypted video. The video would simply fail to play if an external plugin or downloader is used to try to access the video file.We have timely modifications to our licensing and authentication mechanism to keep security updated.
5. Watermarking -Video licensing and playback are combined to generate customisable viewer specific watermarks. The watermark can be IP address, Email ID  and User ID shown in customisable colour & transparency to identify a playback session by the viewer.
6. Result – Progressive High Secure Streaming
   Through this 6-step Video Hosting, Encryption and Streaming process, VdoCipher, as a video hosting software,  is able to provide a progressive high security video streaming with future buffer possible. This is also different from RTMP which does not maintain any buffer and can be quite erratic as a result.

You can find out more about DRM Solution here.

Demo Free Trial for HLS DRM Streaming

You can signup for a free full version trial at VdoCipher.

Online businesses also often require features over and beyond video security. VdoCipher fulfills all major requirements for enterprise video hosting. The complete set of features that VdoCipher offers for enterprise video hosting may be found here.

Also, do read our blog on react native video playback.

Signup for Free 30 Day Trial