What is Digital Rights Management (DRM) 

How DRM Works at a Technical Level

Digital rights management (DRM) is often thought of in simplistic terms as a way to encrypt media to prevent unlimited copying and distribution of the content. While this is a common thread, the base technology and its applications are considerably more subtle and sophisticated in the way they are used.

While DRM implementations were often originally applied to downloaded media files, today's most common application is the protection of streaming video. The changing industry context has necessitated the development of a range of standards that enable efficient stream delivery while maintaining the video itself in a protected format. Along with standardization has come a profound transition in the implementation of DRM support, especially on the consumption side. A previous generation of clunky 3rd party apps or plug-ins that users had to explicitly download and installed has almost entirely vanished from the market. A modern, standards-centric DRM solution does not rely on plug-ins or apps, leverages security support built into consumer devices, and offers seamless access to content for legitimate users. The transition has been partly driven by technical innovation, but also compelled by the increasing commercial significance of streaming video services. With tens of billons of dollars at stake and a worldwide audience, the seamless delivery of video streams became vitally important - while at the same time making sure that that content can delivered in a controlled way established and supported the successful business models of the service providers.

Because of the prominence of the video streaming business, and the specific market focus of EZDRM, the technical issues addressed by this page will have a streaming focus rather than attempting to address all possible models, options, and formats.

There are always two major aspects of a DRM implementation:

• The content encryption process/workflow (FAQ Workflow)
• The content playback process (FAQ Browsers Apps)

It's convenient to think of the DRM support required in both of these processes as coming from a 'black box' service that is independent from the actual video workflow, and is secure/trusted.

[image/graphic??]

In video streaming services, the protection of the content typically takes place in a workflow stage termed 'packaging.' The packaging term applies to a process where individual video segments within a stream are transformed from clear (as in unprotected) to a protected/encrypted form. The high-bandwidth process of video encryption is typically part of the video processing hardware or software, but the supporting DRM service provides the encryption key or keys that are used in this transformation. In fact there are two pieces of information provided by the DRM - the key value itself, and an identifier for the key value that is used in subsequent steps of the process.

The encryption process itself needs to follow some 'rules of the road' that have largely been thrashed out in standards bodies, including:

• The use of a specific cypher algorithm. For most purposes nowadays, the cypher used is known as AES-128 CBC (FAQ).
• How that cypher is applied to each video segment - essentially what information is encrypted and what is left in the clear.
• Where the key identifier is stored in the stream.
• What DRM technology or technologies can be used to 'unlock' the stream (FAQ).
• Where a consumer device should look to request the DRM unlocking details.

Once the stream has been protected, it is ready for distribution across the CDN/Internet. The key and key identifier pair used are maintained exclusively inside the DRM black box.

Before a stream can be consumed on any device, the playback process must access enough information to enable the video content to be deciphered. The information embedded in the stream is used to determine what kind of request can be used to fetch this information. The vital contact point is the DRM black box, and the basic steps required are:

• Matching the DRM technology available on the device to information embedded in the stream at packaging time.
• Resolving the key identifier for this stream.
• Using the devices DRM client software to format a request to the DRM black box to obtain a stream specific, device specific, and time specific license object.
• When the rules of the license object are satisfied, the hardware decryption logic of the device is primed with the decryption keys.
• The content can be played in the screen of the device via the hardware decryption logic.

Note that the requests to the DRM black box never resolve to the decryption keys themselves, but to a license that encapsulates those keys in a set of rules regarding how and when the stream can be viewed. One consequence of this is that the same rules can be applied whether the content is streamed in real-time to the device or whether it has been downloaded in advance.

Technical Challenges in DRM

Key Management

A fundamental challenge to any encryption system architecture is the protection of the key value used on a specific piece of content. If this key is made public, any control over content distribution and copying is lost. While there is a general cyber security challenge with protecting the database of key id/value date in teh DRM black box, the historically bigger issue is secretly delivering the key value to the consumer device in a way that make it impossible to capture. For a long period in the history of DRM this challenge was at the center of the fundamental arms race between those who protect legitimate services and those attempting to use content outside of the rules.

The current state of that arms race is the use of a specialist hardware Trusted Execution Environment (TEE) on consumer devices. This is a complex topic but, essentially, an immutable device number burnt into a device chip is used to uniquely obscure the value of a decryption key delivered to that device, and the unprotected value of that key is never accessible to any software running in the device. Actual decrypted video is also derived by hardware in such a way that it cannot be captured by device software, and output control mechanisms (such as screen capture protection) are supported by hardware options in the same video pipeline. This makes the low level DRM logic extremely rubust against software hacks and reverse analysis/emulation attacks.

Access to the TEE details is essentially limited to the specialist DRM client code that is now built into the operating system of each device type. The complexity of maintaining this support is such that the DRM client technology available is now more or less limited to one option on any given device, and those DRM stack options almost 100% aligned with the key ecosystems that manufacture and support different device types - Google, Apple and Huawei ecosystems in particular.

Device Proliferation

In the days when video services were delivered exclusively to a dedicated, (locked down and leased) Set-Top Box (STB) device, all consumers could be more or less guaranteed the same range of services and quality of experience. Where the consumer brings their own device - or maybe many devices - the challenges of supporting a seamless experience across all possible endpoints is vastly more complex. Glitch-free DRM support across the very broadest range of device types is one dimension of that challenge.

Two critical DRM implementation approaches help to reduce the complexity here:

• No client side code deployments used as part of a DRM solution: No downloads or plug-ins should be required or used as components of teh solution. This places an exclusive reliance on the native code base in any device, but eliminates a vast amount of potential device testing for overall service deployment.
• Explicit constraints on DRM clients supported and the "hardening" of that support: Effectively, close to 100% of the end-user devices and browsers that could be supported on any given delivery service will have a native implementation of one of the major commercial DRM technologies - PlayReady, Widevine, FairPlay, and WisePlay [See Multi-DRM below]. The key exception to this uniform support - and one that has to be evaluated carefully for the balance of security and service penetration - is the use of standalone ClearKey encryption.

Multi-DRM Streaming

No service provider wants to be forced to create and deliver a multiplicity of different content stream versions targeted at different devices. The whole premise of Adaptive Bit Rate (ABR) stream implementation is that a single manifest file can be used to address all device types. Where DRM protected content is concerned, Multi-DRM support during the packaging process enables a single stream to be playable on devices that implement a range of different DRM client technologies.

Using newer, but standardized, protocols (CPIX, etc.) between the DRM black box and the content packaging process, it is possible to combine one single encryption process with a variety of key identifiers for different DRM technologies. The protected content stream contains multiple (1:n) references to DRM types that can be used on the client side to obtain a license and can therefore be delivered to any device type regardless of its native DRM support implementation.

On the client side - for any player the receives the stream - the player technology identifies DRM references in the stream which its own native client can resolve. References to unsupported DRM systems are ignored. The chosen DRM performs the license request to the DRM black box and ultimately resolves this license to the required key(s) for playback.

Additional DRM tricks are possible with this Multi-DRM solution such as offering different business models for different resolutions of content within the stream. This adds to the overall usefulness of the technique.

Capture after Render

No discussion of security would be complete with a mention of the limitations of DRM when considering the end-to-end security envelope. For example, DRM technology can effectively guarantee protection of the video delivery envelope until the video is displayed on the screen of the consumer device. There are a number of potential piracy attack points that might compromise security after that point, which may require additional complementary technology deployments to combat theft. One of these attacks, for example, is the use of an 'HDMI stripper' device on external outputs from an STB or other player. A stripper device can remove the inherent protections of the HDMI link and permit video recapture. In the same way, high quality video recording of the consumer screen can permit video recapture and redistribution via sociall media or other video sharing services. For protection against these types of attack, video watermarking is a potentially useful additional layer. (FAQ)

Business Challenges

As outlined above, DRM is more than just a mechanism to deliver encrypted content. It also provides tools and techniques to create and enforce a business model related to the consumption of that content. The DRM license is the object that delivers the appropriate keys, but also the rules around consumption. For example:

• Permit playback on the device that requested the license within a given time window.
• Permit playback on the device that requested the license, but switch off screen capture or 'casting'
• Eliminate the option to share the content stream and DRM license successfully with another device
• Permit stream download and playback of that downloaded content
• Permit stream download and offline (aircraft mode for example) playback within a given time window
• Permit any number of views of the content within a given time window after first viewing (say 3 days after first viewing)
• Using an entitlement mechanism that filters certain characteristics of the DRM license request, it is possible to lock access only to certain IP addresses, locations, or devices. This means that if media is only licensed to US residents, for example, then it will not be accessible to people in other countries.

Detailed audit logs of requests and licenses issues are always maintained inside the DRM and are available in case of dispute.

Digital Rights Management Technology Stakeholders

Apple (FAQ)

Apple’s FairPlay® Streaming (FPS) DRM provides secure video playback through the full wide range of Apple devices and operating environments. The client software is not openly licensed, but is the default security environment across

Microsoft (FAQ)

PlayReady, by Microsoft, is probably the most influential and broadly supported DRM solution in today’s marketplace. It was introduced in 2008 as a more device portable and standards-centric evolution of the prior Windows Media DRM system. PlayReady has been adapted and extended in various ways since, that point to support streaming vs file download, live vs on-demand, and domain vs personal licenses.

Google (FAQ)

Widevine DRM was originally developed and marketed by Widevine Technologies. The company was acquired by Google in 2010 and Widevine DRM has been vertically integrated across the major Google offerings since that point. With typically Google aggressive enforcement, its becoming an increasingly used default.

Huawei (FAQ)

WisePlay DRM is a relatively new branch on the tree of DRM technologies available to audio and video services and is developed and marketed by Huawei Technologies on their own devices (the largest selling mobile device family globally) as a response to the current political climate surrounding Huawei products and services.

There is also a simplistic mode of encryption-only operation known as ClearKey (or Clear Key) - not strictly a DRM solution, but included here for completeness.

Commercial DRM Offerings

The base DRM technologies referenced above can - in different ways - be adopted and integrated by service operators as a part of their overall workflows.  But few of operators today relish the though of integrating, deploying, and maintaining an in-house DRM technology stack.  The overall industry emphasis has shifted to the use of Digital Rights Management as a Service (DRMaaS) where a specialist vendor offers a complete micro-service solution - usually cloud based - that can be leveraged via web APIs. The beauty of such a black box service is that you may not need to understand many of the details offered above! When a provider chooses such a commercial service they are often evaluating vendors based one a number of criteria:

• The extent to which the service interface successfully abstracts away the complexity of DRM technologies without unnaturally restricting native functionality.
• The effectiveness with which the vendor takes care of issues around maintenance, tecnical updates, and standards evolution.
• The range of different protocols that the vendor can offer for packaging support, compatible with the service operators workflow and feature requirements.
• The completeness of the range of DRM technologies offered to address the widest range of client devices.
• Especially for live services, the extent to which the vendor addresses the need for low latency protocol support and efficient license genration.
• The robustness and integrity of the DRM key database in use.
• The architecture of the service that more or less guarantees 100% availability for DRM license requests.
• Proof of many of these desirable characteristics through showing close working relationships with other vendors in the video processing and player ecosystem.