Security of DRM relies on keeping secret the cryptographic keys that protect content. The DRM client is the only component on the viewer’s device authorized to handle these keys. In the DRM security model the viewer is the attacker which means that a DRM client operates under very difficult conditions, running on an adversary’s device.

While each DRM technology and each implementation of a DRM client is unique, every DRM technology aims to achieve the same goals and many DRM client implementations do it in similar ways. This article describes the general patterns that apply to all.

Robustness

The major differentiating factor between DRM client implementations is the robustness level. This is a description of how resistant an implementation is to attacks and tampering.

There is no perfect DRM client implementation. A sufficiently skilled attacher can eventually extract the secrets from any of them. The core principle of DRM client security is to make this unreasonably expensive for the attacker. Every DRM client uses a defense in depth strategy to layer multiple defense mechanisms between the attacker and the keys or decrypted media samples.

A high robustness level is provided by DRM client implementations that are built into the operating system and can make use of OS-level and hardware-level security mechanisms. In such implementations, cryptographic operations might be performed on a separate CPU. Valuable data such as keys and decrypted media samples might be stored only in a memory region inaccessible to the primary operating system. This level of robustness is typically mandatory if you wish to play back UHD or sometimes even HD content (depending on content owner policies).

A low robustness level is provided by DRM client implementations that are self-contained and do not integrate deeply with the operating system or hardware. This is typical for DRM clients built into browsers and apps. They rely on obfuscation to make it difficult for an attacker to observe what the DRM client does and to extract the keys and decrypted data. Despite not being part of the operating system, such implementations will still use operating system provided APIs to restrict unauthorized use where possible (e.g. by preventing output over HDMI to recording devices, only allowing output to display devices). This type of implementation typically does not permit for high-value content to be presented but is sufficient for playback of less security-critical content (e.g. movies that have completed their initial run in cinemas, presented in 720p resolution or lower).

Widely deployed high-robustness DRM client implementations are:

• Microsoft PlayReady on Windows
• Google Widevine on Android
• Apple FairPlay on Apple devices
• Microsoft PlayReady and/or Google Widevine on other consumer electronic devices (e.g. smart TV, set-top box, TV dongles)

For modular devices such as PCs, the exact device capabilities (e.g. type of installed CPU and active UEFI firmware configuration) may constrain the maximum available robustness level. For example, certain versions of PlayReady on Windows PCs only offer high robustness if the Intel Management Engine is present and enabled.

Robustness brings content

The type of DRM client implementation you need to use in your solution depends on the requirements of the content provider. The higher the level of security you can provide, the more access to valuable content you will get. However, content providers typically do not provide clear and obvious guidelines on what security mechanisms are needed to license content. They might publish best practices and refer to industry guidelines¹ but these publications should not be taken as requirements - you gain access to content if the content provider finds the risk/reward ratio of your security model and business case to be favorable. First and foremost, you need a well thought-out security model that covers all the relevant angles and is actually used as a basis for creating the solution, not merely written up after the fact during the content licensing discussion.

A common mistake is to treat the referenced best practices or industry guidelines as a set of requirements. While published industry guidelines tend to point you in the right direction, a security model is more than merely a set of checkboxes to tick. Indeed, not everything in the set of industry best practices is necessarily relevant or important in all solutions - every security decision must be considered in context.

In the end you need to make some choices, describe your security model to a content provider and observe their response. The discussion can include several rounds of alignment and adjustment depending on the content you desire to gain access to.

Mitigating factors can apply in some circumstances - for example, if, instead of targeting viewer owned devices, your playback devices are owned by the solution operator (e.g. they are screens mounted onto walls or into vehicles) you might be given more access to content because it will be difficult for an arbitrary viewer to gain operator-level access to such devices.

The goal in a content licensing security review is always to convince the content provider that you can provide content security, not to merely tick some checkboxes. To succeed at this, you must understand how DRM client robustness affects your solution and be able to explain this in detail. The rest of this article explores aspects of DRM client behavior at different levels of robustness.

Obtaining keys

A DRM client needs one or more keys to unlock a movie. Different keys are typically used for different components (e.g. a key for audio, a key for SD video tracks and another key for HD video tracks). During live streams, the keys may also be changed periodically² in order to force re-authorization checks.

During DRM client activation³ by a player, initialization data is provided. Initialization data informs the DRM client what keys it will need to play back content.

If the required keys are not already in the DRM client key store, it will inform the app that it needs to acquire them via a license request (aka key request).

The reason the DRM client does not simply go and request the keys on its own is that the app needs to attach data to the license request, providing proof of authorization⁴ for the DRM server, proving that the viewer really does have the right to use the requested keys.

If the viewer is authorized to use the requested keys, the authorized subset of keys⁵ (which may be smaller than the requested set of keys) is embedded into a license that is returned by the DRM server as a response to the license request. Processing the license makes the keys usable by the DRM client.

Even if an authorization token is present, only genuine DRM clients that can prove their authenticity are granted keys. A separate article will cover DRM client and server authentication in detail.

Protecting keys

The keys in the license are themselves encrypted using a public key, the private key complement of which is held by the DRM client. Protecting this private key is critical to DRM client security as it allows the keys within a license to be decrypted.

In high-robustness DRM clients, the client private key is only usable within a secure enclave (aka trusted execution environment). The exact security mechanisms used to create the secure enclave depend on the operating system and device hardware capabilities.

The effect of using a secure enclave is that the DRM client is able to use its private key for decryption without exposing the private key outside the enclave. Furthermore, the decrypted data itself (the key used to decrypt movie data) is not exposed outside the enclave, being directly plugged into the movie decryption process that exists out of reach of the attacker.

DRM clients lacking the capability to use a secure enclave must rely only on obfuscation and anti-tampering countermeasures to protect the private key of the DRM client, the movie keys and the decrypted media samples.

The typical technique for low robustness clients is to use white-box cryptography⁶ to obscure parts of the cryptographic processes within the DRM client. The core principle of white-box cryptography is the following:

1. The DRM client private key is merged into the decryption algorithm (possibly also merging multiple sequential decryption keys/algorithms).
2. The combined algorithm is obfuscated to make it very difficult to identify what part of it is the key.

The result is that the DRM client has an algorithm that takes encrypted movie keys and the encrypted movie as input and, without requiring any DRM client private key as input nor exposing the decrypted movie key, decrypts the movie data.

Note that the interface between the decryption algorithm and the media decoder still needs protecting (using operating system specific means) to prevent the decrypted samples from being intercepted and recorded.

A sufficiently skilled cryptanalyst may still be able to extract the keys from a DRM client that uses white-box cryptography but a good implementation will make it significantly more expensive in terms of time and effort. Ideally, so expensive as to make key extraction attacks impractical.

Enforcing policy decisions

In addition to protecting keys and decrypted samples, the DRM client is also in charge of enforcing the policy constraints attached to the licenses that deliver keys.

This policy can include elements derived from both solution-specific needs and from content provider requirements. Common examples of license policy are:

• License expires on specific date/time.
• Playback is only permitted on output devices that support HDCP⁷ 2.2.

In general, different DRM technologies offer equivalent capabilities in terms of policy configuration. However, the exact technical language used to describe policy decisions will be different for each DRM technology.

The policy starts as human-readable (e.g. English) text in a contract. This text has numerous effects on the implementation but the policy that specifically controls DRM client behavior is typically handled as follows:

1. The human-readable contract language is translated to a machine-readable rules language, managed using a CMS.
2. These rules control the policy configuration in authorization tokens emitted by the authorization service.
3. The DRM server translates these generic rules to a DRM technology specific configuration when granting a license.

Not every DRM client will be able to enforce every policy:

• To enforce time-based policy, the DRM client needs a tamper-resistant clock.
• To enforce HDCP, the DRM client needs access to an opeating system API that enables HDCP usage to be controlled.

The license request typically contains information about the DRM client’s capabilities. This set of capabilities can be evaluated by the DRM server to determine what policies are enforceable by the DRM client. Insufficient capabilities may limit the set of keys that can be made available or result in a denial of license.

What’s the difference?

High-robustness DRM client implementations require deep integration with the operating system and hardware. DRM clients delivered as browser or app plugins are low robustness implementations. Native DRM clients provided by the operating system have a significant advantage in terms of security and should be preferred.

The content of this article applies to all modern DRM technologies in widespread use. Given that all DRM technologies aim to achieve the same thing one may wonder why there are non-native DRM client implementations available for many devices/browsers, especially if the native DRM client often provides far better robustness than its competition.

This largely comes down to history. There used to be multiple competing DRM technologies offering equivalent (low) robustness levels at equivalent (high) prices. Eventually, platform authors (Microsoft, Google, Apple) and their licensees started offering high-robustness DRM built right into the platform. In parallel, the DRM technology authors lowered the technology licensing prices to very reasonable levels making competition on price largely irrelevant.

The policy-enforcement capabilities of all modern DRM clients are effectively equivalent. While small technical differences exist, DRM clients do not compete based on what types of protection policies they can enforce.

There is almost no reason today to use anything other than the native DRM implementation. On Apple platforms, FairPlay DRM is easy to use and offers high robustness. On Google platforms, Widevine DRM is king. On Microsoft platforms, PlayReady offers the best features. On playback-specialized consumer electronic devices (e.g. Smart TVs, set-top boxes and TV dongles) you often find multiple high-robustness DRM implementations (typically both PlayReady and Widevine are available).

Two practical obstacles remain to use of high-robustness native DRM clients:

1. The Windows-native PlayReady DRM is only available to Microsoft browsers, with all other web browsers forced to use low-robustness plugin-based DRM clients. Obviously, this gives Microsoft browsers a competitive advantage - low robustness DRM in other browsers is limited to showing low quality content⁸.
2. Legacy solutions deployed many years ago may already be heavily invested in a single DRM technology, having locked themselves into certain technical or business decisions, and lack the architectural agility to start using the best modern DRM clients which would permit them to present even higher value content.

As long as an implementation of the required robustness level is available on a given platform, there are no significant technical differences between DRM technologies. If you are creating a new solution, use the native DRM technology on each device and build your solution based on open industry specifications^9,10. This gives the best capability and flexibility while avoiding lock-in to unusual DRM clients for a given platforms.

Using a DRM service provider to buy in the bulk of DRM infrastructure or consulting a seasoned DRM expert to design your own infrastructure can both greatly simplify DRM technology integration, reducing the cost in terms of time and money. A future article will provide an in-depth look at what the integration of a specific DRM technology means for a solution and what role DRM service providers play.

Coming up next

Where do the keys even come from? How are they created and transported across a solution? You will find out soon, as the next article is all about key management.

View all articles in the series.