Securing OTT Content — DRM
Written by: Boris Asadanin, Streaming Media Consultant and Partner at Eyevinn Technology
Background
DRM — Digital Rights Management is what most people associate with securing digital video content. While DRM is mainly associated with encryption, DRM systems today actually allow for a lot more sophisticated functionality. This functionality is described below together with DRM workflows and how it all connects to streaming formats.
This article is one of three describing the technical principles of securing OTT content.
This publication is part of a series of articles describing the principles of the technology behind video streaming. It could be read without any prior knowledge on the subject.
Introduction — History
In the beginning of the new millennium IPTV emerged as the first commercial video distribution technology over the internet network platform (read more about IPTV in the Internet Video Streaming — IPTV article). Today, while the satellite, cable, and the IPTV distribution system popularity declines, the TV distribution over the open internet gains popularity and is quite quickly changing how people consume media content.
Distributing TV over the open internet requires a complete new set of tools to securing the content. But the DRM technologies also offer more functionalities than ever before fine tuning how content can be monetized.
What is DRM
DRM — Digital Rights Management, is a digital licensing system that allows content owners to control how and by whom their content is being consumed.
DRM is often mistaken for being equal to encryption. While encryption is the process of obfuscating digital data, DRM is the complete system for managing content access. DRM includes the distribution of encryption and decryption keys, backend licensing servers with various functionalities such as policy control and offline playback control. There are numerous commercial DRM systems today and at least the professional ones work with AES (Advanced Encryption Standard) as the encryption technique.
Principles of DRM
Despite DRM commonly mistaken for being equivalent to encryption, the encrypting part actually takes place in the packager (usually a part of the encoder, standalone, or in some cases the CDN). Encryption is described here anyway since it is a central part of the work flow.
The three main areas of the DRM workflow are described in each subsection below.
Key Distribution/Storage
The DRM workflow depicted in fig 1 can be viewed in two separate parts; where the DRM is applied for encrypting the content in the packager (steps 1–2 marked red), and where the client uses the DRM for decrypting the content (steps 1–3 marked green).
Encryption in the Packager (red):
- To encrypt a piece of content, the packager requests an encryption key from the DRM system. The DRM system provides an encryption key and links that key to the content ID. Note: in some cases the encryption keys are created in the packager and sent to the DRM system for storage and distribution to clients.
- The packager encrypts (and re-packages) the piece of content using the encryption key.
Decryption in the Client (green):
- The client requests the content using the content URL.
- As the content is received by the client, it has to be decrypted before playback. The client requests the decryption key for the associated content ID from the DRM system.
- As the client receives the decryption key, the content is decrypted and played. The DRM SDK within the player makes sure that content cannot be intercepted through the player content path (receiving network socket through decryption and to screen output)
The Just-In-Time Packaging section below describes how DRM is applied in the content flow.
Encryption
AES (Advanced Encryption Standard) is a standard for encrypting digital data would it be video or other data content. AES is a symmetric encryption technique meaning that the same keys are used for encryption and decryption.
AES is widely used by the commercial packagers and DRMs today. AES comes in different flavours and for video content encryption there are primarily two modes of AES being used; CTR and CBC. The two differ in the encryption process and how the keys are being used. The AES encryption principles are complicated and outside the scope of this article. But remember this; the complexity will be revisited later in this article.
The important aspects to consider when encrypting video is to achieve the best ratio between encryption time/effort and security. Live video is a real-time application consisting of increasing amounts of data as we are moving towards HD, 4K and HDR content qualities. Encrypting video content is resource demanding and time consuming which makes it hard to do in remote edge servers.
Licensing server
The licensing server implements fine granular policies and rules to control howthe content is being consumed rather than only whogets the decryption key.
The licensing server can support any policies. Example of common DRM policies include:
While most DRM systems include a licensing server, it is also possible to implement an own licensing server and integrate it with a commercial DRM system and its APIs. More about this in the Multi-DRM Section.
The DRM Landscape
While DRM as a concept is unrelated to streaming formats, the streaming industry has shaped quite close partnerships between them. In fact, in many cases the streaming format developers are also developing their own DRM system. This has led to DRM functionality becoming equivalent to the format, and sometimes even the client device type itself. Today’s main video streaming formats all have their respective DRM system integration:
Except for the streaming format relations, the technical differences between the DRM systems are more in the details than in the general principles. Details such as how keys are distributed or retrieved, specific license server functionalities, or how and what part of the video data is encrypted differ the DRM systems apart. Going further into these details is outside the scope of this article.
Multi-DRM
As each client device typically supports one streaming format, and by that also one DRM system, achieving maximum device reach requires integrating with multiple DRM systems. This can either be done by implementing own licensing servers and negotiate terms directly with the above DRM players, or by using a multi-DRM solution.
There are quite a few DRM system providers who offer multi-DRM solutions which is often the simplest way to integrate with several DRMs. Some common multi DRM providers are:
The multi-DRM solution providers offer well-built licensing servers and have already made the negotiations and integrations with Microsoft (PlayReady), Apple (FairPlay), and Google (Widevine). Thereby they cover support for the most used streaming formats and associated client devices. A multi-DRM provided solution is usually a more straightforward way to build a premium video service.
ClearKey DRM
The Clearkey DRM concept is just like any other DRM but with lower level of security. This method could be an excellent choice for content owners/broadcasters who are not bound to content owner DRM requirements and want a cheap way to encrypt their own content. They usually do not need all the bells and whistles that commercial DRM systems have to offer or maybe want to build their own licensing server.
A Clearkey DRM system differs from ordinary commercial DRM systems on a few important points.
- Its keys are sent in clear text. As the name points out, the encryption/decryption keys are sent in plain text and does not offer more secure key distribution algorithms.
- Minimal client integration. Clearkey DRMs sometimes require less integration to client players which lowers the security and may increase efficiency.
- Minimal additional security features. Commercial DRM systems offer advanced security features that controls how and by whom content is being consumed. This is absent in the Clearkey DRM solutions, but may of course be built on the side.
Just-In-Time Packaging
As described in the OTT Video Formats, and briefly in ABR part 3 articles, many available solutions today packages content “just in time” or “on the fly”, meaning that a piece of content is being packaged to the requested format upon request. This process also includes a “just in time”, or “on the fly” encryption of content. As each video streaming format is associated with a certain DRM system, the encryption may be included in the just in time repackaging steps. Fig 4 a and b below, reused from the ABR part 3 article, is completed with the encryption parts as well.
When a video request comes in the video streaming system inspects the requesting client and what streaming format and encryption DRM is required, repackages and encrypts the existing video content appropriately for the requesting client, and streams the content.
Naturally just-in-time packaging and encryption must be handled in a very short time, less than a second to maintain short live latency. And for each requesting client.
Looking back at the Encryption section, encryption is not effortless even with the hardware support in some cases. Considering that all DRM systems use the same AES encryption, why not encrypt earlier on in the OTT platform chain instead of just-in-time last minute?
MPEG Common Encryption
Let us elaborate the thought raised in the previous section. Why can we not separate the encryption from the DRMs? The benefit would be that we can encrypt earlier on in the process and keep one asset copy on storage already pre-encrypted ready for simple just-in-time repackaging. We would also remove the effort consuming encryption step earlier on in the process, and keeping files encrypted and safe in storage.
Note that this applies for on demand/VOD content only, less for live content. Live content must be repackaged and encrypted on the fly still fast enough to minimize the latency that was explained in the ABR part 3 article.
The MPEG Common Encryption Standard, MPEG-CENC, specifies a set of rules and preferences (key mappings, AES encryption modes) that can be utilized by multiple DRM systems. The idea is that any DRM following the CENC rule set can use the same encryption keys and decrypt the same asset file. Our new just-in-time workflow would become as depicted below.
As depicted in fig 5, content is being encrypted at ingest and kept encrypted and safe on storage. Just-in-time packaging is kept a fast and light weight operation.
Great, so this is how it works today! Unfortunately, not. This is where some of the complexities come to play, remember?
Status of today
Still today many video streaming service providers package, encrypt, and store at least two copies of each content, despite having on the fly re-packaging services. Of course, they could do the encryption step in the re-packager as depicted in fig 4b. But as it is resource demanding in many cases the less equipped edge re-packager cannot maintain low latency and quality doing the just-in-time encryption.
MPEG-CENC was initially specified to support CTR. Microsoft Smooth Streaming format supports CTR and so also the MPEG-DASH format. However, the third major streaming format, Apple HLS, supports CBC instead.
Years of work to consolidate the video format support has finally resulted in MPEG-CENC standard having opened for supporting both AES modes, CTR and CBC. And after this has been implemented in all technical components it will be possible to use one encrypted file as base for any DRM system and re-package pre-encrypted files.
Final Note
Despite the very fragmented space of DRM vendors and technologies, selecting DRM providers does not have to be a very hard process. With quite a few multi DRM providers covering the support for all major client platforms the process is usually rather straightforward. Also, the important recent steps that have been taken to align the DRM related techniques will further commoditize the content security space going forward.
But do not rule out ClearKey DRM solutions which could be a very dynamic and cheaper way to apply content security to content that does not follow the strict requirements that premium grade content does.
