Apps, websites and services presenting high value video content use DRM technologies to prevent the viewer from making copies of the content. It can be surprising to learn that the website operator is not the one who ultimately benefits from DRM.

The past twelve years of my work on media streaming projects and products have kept me in close contact with DRM. This is the first in a series of articles that will briefly explain how the DRM ecosystem functions, in the hope that this will help lift a needless veil of secrecy that surrounds the topic. There is no need to work in the shadows when it comes to DRM - the techniques and mechanisms used should be well understood by all stakeholders to ensure that they are put to the best use.

Content licensing

A typical company that intends to publish a media streaming solution will first encounter DRM when they try to license some content to offer their viewers. Early in the negotiations, the content provider presents the solution operator with a security questionnaire to fill out. This will include questions both open-ended and highly specific, such as:

• What is your security model?
• Do you enforce removal of content from viewers whose subscription has lapsed?
• Does your solution detect jailbroken devices? If yes, how?
• What is the maximum video resolution you support for each platform you target?
• Which certificates are used for authenticity verification and who signs them? Does it depend on type of device? If so, how?
• Does yous solution offer protection against malicious system operators making unauthorized copies? If so, how?
• Which DRM technologies are used?

There can be as many as 20 pages of questions to answer and forms to fill, the purpose of which is to provide the content provider’s security experts the information they need to evaluate the solution’s content security capabilities. The security questionnaire is not a requirements list. A solution does not need to answer “yes” to every question and to deploy every mechanism listed.

The level of security provided by the solution is evaluated against the policy defined by the content provider to determine what content can be licensed for use in the solution. A solution that provides better security guarantees will unlock the possibility to license more valuable content.

Different titles have different security requirements:

• 4K resolution superhero movies tend to be the most valuable content - very few solution operators can offer security strong enough to license such content. This requires hardened devices and a supply chain where every link is secure and traceable.
• Early-window content (still playing in cinemas) has fairly high requirements but these can be met by most serious solution operators that have control over the full chain of systems involved in the solution.
• Anything already available of DVD has quite low requirements, as DVDs can be trivially copied.
• Library content (e.g. movies 10 or more years old) has minimal requirements, often being available even without the use of DRM technologies.

While the main basis for the decision is the earning potential of the title for the content owner, technical factors can still have an impact. For example, high-value content can be authorized for playback in less than ideal solutions if presented only at low quality levels (SD resolution).

The questions and answers are not the security model

Ten years ago it was common to see the security questionnaires treated as “write-only” information in large part - as long as you answered the questions with what sounded like reasonable answers, you got the content. Nowadays, the depth of evaluation has increased and there are actual security experts reviewing the questionnaires in detail. If the text tries to be vague and lacks sufficient depth then additional rounds of inquiry are scheduled and pointed questions are raised to uncover the reasons for the vagueness.

This means that it is no longer easy to get away with just filling in convincing-sounding individual answers - the solution architect needs to present a complete set of responses that will convince the security expert reading the text that content security is a core part of the solution. The big picture presented by the answers is a significant component in the security expert’s evaluation. Treating the questionnaire as a list of checkboxes to tick will result in less access to content than one would obtain by presenting a thought-out security model that has meaning also outside the security questionnaire.

There can be a vast difference between the architecture and functioning of a solution designed to handle high-value content and of a solution designed without security principles in mind. It can be quite expensive to retrofit security into a solution if the need is only discovered at a late stage when a content provider security review raises painful questions. Content security should be built into a solution from the start. Consult an expert to design a security model that meets your needs.

What is the role of DRM?

The content licensing process is where a typical solution architect will first encounter DRM, with the first question being “which DRM technology is used”. A typical solution operator publishing content made by other parties will not care about DRM for their own benefit - viewers tend to be rule-abiding customers and even if a few individuals make unauthorized copies the business will not be impacted much. However, content owners care deeply about each and every time their content is accessed because a single unauthorized copy is enough to have a large impact across the entire viewership!

Therefore, the usual thinking with regard to DRM is “what will satisfy the content owner” and not “what do I gain from DRM”. Most solution operators see DRM integration as a tax they have to pay in order to obtain content. One of the main goals for this series of articles attempts to reduce the budren of implementing DRM by helping solution architects new to DRM to understand the processes involved.

Each content owner has a list of DRM technologies they have approved for use with thier content. The most common in use today are:

• Google Widevine - available on Android, Chrome, Firefox, Edge and various consumer electronic devices
• Microsoft PlayReady - available on Windows, Edge and many consumer electronic devices
• Apple FairPlay - available on Apple devices

These three are the core technologies of the DRM ecosystem and are approved for use by all content owners.

Nearly all modern consumer electronic devices include at least one native DRM technology implementation. Devices designed specifically for content playback, such as a smart TV or video-dongle, will typically support both Widevine and PlayReady, plus a few lesser known DRM technologies.

Beyond the big three, there are several other DRM technologies that are also approved by many content owners but typically they are used less often as they are not natively supported by most devices and software platforms, requiring the use of plugins and specialized player apps.

Technical components of DRM technologies

Obviously, there is some DRM code that must run on a viewer’s device in order to perform the functions expected of a DRM technology - that is, to stop the content from being copied. How this DRM client is delivered and how it integrates with the device’s capabilities can be quite different for each technology and each device.

Three models are common for deploying DRM clients to viewer devices:

1. The DRM client is part of the operating system and/or hardware.
2. The DRM client is part of the web browser.
3. The DRM client is part of the app.

A single DRM technology can exist in multiple forms depending on the target platform. For example, Google Widevine is part of the Android operating system, part of the Chrome, Firefox and Edge browsers, and can be deployed as part of an app on certain other platforms.

The capabilities available to each type of DRM client implementation are different. A DRM client integrated into the operating system and/or hardware can take advantage of access control mechanisms that are simply not exposed to browsers or apps, while at the same time protecting itself against attack using more powerful means. The measure of how well a DRM client resists attack is termed robustness - using a more robust implementation will convince a content provider to license you more valuable content.

In addition to the DRM client on the viewer’s device, another DRM component runs as a backend service accessed over the network. To authorize usage of content, a document called a license is generated by the DRM server. This delivers the keys to unlock content, informs the device-side component how it must protect the content and defines under which conditions the viewer is authorized to access it (e.g. time limit, max display resolution). Each DRM technology produces the license using its own proprietary data format and uses a custom communication protocol to provide it to the device-side component.

Beyond the interactions relevant to playback, DRM technologies are often also involved in the processing and preparation of the content. The data inside media streams is encrypted to ensure that it cannot be accessed without the cooperation of the DRM client, which is the only element permitted to obtain the key (as part of the license). Furthermore, DRM technology specific activation data is often embedded into the media stream headers to instruct the player on which DRM client to activate and how.

The management of encryption keys is often also a proprietary solution tied to the DRM server, although its exact forms vary greatly and no single approach has a strong foothold in the DRM ecosystem. Future articles in this series will explore the backend workflows in depth.

Multi-DRM is mandatory

There is no single DRM technology that covers all platforms. For reasons described in a future article, a solution operator will often want to use the native DRM technology offered by a platform even if other options exist.

As a result, a typical solution will need to use multiple DRM technologies, each targeting a specific set of platforms. This is a multi-DRM scenario.

Different DRM technologies are completely independent from each other and only in recent years did the use of the same content files with different DRM technologies become feasible, due to all major DRM technologies starting to support the same encryption scheme. There are significant differences in the workflows, APIs and architectural patterns used with different DRM technologies. There are even significant and hidden differences in how different devices implement the same DRM technology! And of course, there are different versions of DRM technologies and different implementations of those technologies. It can be a major challenge to understand how exactly multiple DRM technologies can be effectively tied together in a single solution.

Later articles in this series will examine in detail the interactions between different DRM technologies to explain how multi-DRM integration in a solution can be accomplished with minimal hassle.

Multi-DRM is unnecessary

The primary function of a DRM technology is to restrict what the viewer can do with the content. Typically, the viewer is authorized to play back the content (often within a time limit) but not to make copies of the content.

And that’s it. That’s what every DRM technology aims to do. The core function is to restrict the viewer’s actions while resisting tampering by a viewer who does not like the imposed restrictions.

Different DRM technologies largely accomplish this goal in very similar ways, with the differences between the DRM technologies coming down to proprietary protocols, data formats, SDKs and platform integration. From a solution operator’s perspective, there is zero need for multiple DRM technologies to exist. The fact that many different DRM technologies exist and continue to be relevant is largely explained by it being a matter of cost on two fronts:

1. Someone once made an investment that first rooted a particular DRM technology on some platform and there was never enough justification to change it, as it worked well enough and switching to alternatives would have caused extra cost.
2. It can be cheaper for a platform developer to integrate their own DRM technology than to license and adapt a 3rd party DRM technology. Sure, it might make life more expensive for solution operators by requiring multi-DRM but that is not a cost the platform developer has to pay.

Reducing the needless diversity and complexity of competing DRM technologies is in the interest of every solution operator. A platform developer only has to pay the price of DRM integration once but every solution operator has to pay the price of multi-DRM integration for every solution they deploy and every platform they target.

Unfortunately, solution operators do not have much of a voice in the industry bodies that have leverage over platforms by defining industry standards - typically the companies defining the standards are the same ones that are implementing them, not the ones who have to actually use the result. As such, industry standards are often reduced to standardizing the status quo.

Coming up next

The next article will explore the technical structure of content used with modern DRM technologies and walk you through the steps and DRM interactions required to bring content into this form.

View all articles in the series.