Best Practices for Deploying DRM in a Large-Scale OTT Stack

Digital rights management (DRM) is an industry standard that gives content owners options for protecting premium content. An effective DRM solution must work with most playback devices, integrate easily into the workflow, and appear transparent to users. If it can support advanced features like offline playback, it is much better. While DRM may not be a top priority for many streaming service operators, its impact on the viewer’s playback experience can’t be an afterthought.

The goal of any DRM system is to ensure that video content is stored and transmitted in an encrypted form so that only authorized users and devices can play content back. DRM is often misunderstood as little more than AES (Advanced Encryption Standard) 128-bit encryption layered on a streaming platform. In reality, DRM is a complete system for managing content access. DRM provides the secure distribution of encryption and decryption keys coupled with backend licensing servers that add functions such as policy control to prevent playback on unauthorized hardware and offline playback control.

DRM can be deployed in one of three ways. The first is to take on all development and integration yourself. While this is time-intensive, it does allow for maximum control and flexibility. Second is a hybrid approach where you integrate a provider’s pre-packaged DRM solution into your workflow. The third option utilizes a DRM solution as part of a managed streaming service. The Verizon Media Platform offers this type of DRM solution. It is integrated into our video workflow and enabled by a simple service order. We take on the development and integration burden. Remember that with the first two options, DRM is more than a one-off project – it requires an ongoing program to keep up with evolving standards and technologies.

‍Proprietary DRMs

‍Today’s major video streaming formats have their own DRM system integration. Since DRM technologies are proprietary, they are typically only supported on OEM-specific products, albeit with a growing number of exceptions. For example, Apple FairPlay is primarily compatible with the Apple Safari web browser and other Apple hardware and software products. From the standpoint of a streaming service, the lack of cross-platform compatibility means that you will need to adopt a multi-DRM strategy and provide content packaged and encrypted in multiple formats if you want to cover a comprehensive range of devices.

Although there are many DRM systems on the market, from a practical standpoint, streaming services only need to concern themselves with the big three to gain support for virtually all web browsers, devices, and TVs:

• Apple FairPlay Streaming (FPS) – FairPlay content can be played primarily on Apple devices, including Safari, iOS, and Apple TV platforms.
• Google Widevine – This DRM solution spans all Chrome and Firefox web browsers and Android and Chromecast devices.
• Microsoft PlayReady – Content protected by this DRM solution can be played on Roku, Xbox,
• Microsoft Edge browsers and a range of other platforms and smart TVs via SDKs.

The situation improves somewhat when you look at the underlying encryption, where standardization efforts are underway to help simplify the fragmentation of the DRM market. Both Widevine and PlayReady support Common Encryption (CENC) and MPEG-DASH, which means you can encrypt and package your content once and decrypt those assets using either DRM system. FairPlay uses 128-AES CBCS (or cipher block chaining sample mode) encryption and HLS packaging. CBCS is supported in some newer DASH playback devices as well. The market seems to converge on CBCS for common encryption, but other encryptions will need to be supported for a long time.

‍Multi-DRM challenges

‍In the case of our platform, we encrypt content immediately on ingesting in multiple formats. Our default DASH packaging and encryption use the AES-CTR full encryption because it is the most compatible across devices (even though newer devices may support CBCS). Additionally, we use transport stream packaging and CBCS encryption by default for Fairplay because it is the most compatible across the entire range of devices. While these cover most devices and players worldwide, they also add complexity and increase storage costs. Bear in mind that with adaptive bitrate (ABR), we have far more than two or three different files on hand – it can be 15 or more different segments for each block of 4- or 2-second playback time when you factor in all the bit rates.

This situation is slowly improving. The industry is moving toward the broad adoption of a specification called the Common Media Application Format (CMAF) that could allow you to reach most consumers’ screens with a single DRM-enabled file set. Currently, CMAF already works across many DASH and HLS devices and players. Where it makes sense, we can use dynamic manifest generation logic to create HLS manifests with CMAF-compliant encryption and CBCS to support additional devices.

Encoding all these file sets becomes a much larger problem at scale. We solved this by taking advantage of the scalability of the cloud. When our Slicer uploads a file at the highest bit rate, it sends each slice to a broker that farms out the work to a huge encoding cluster. By performing encoding operations in parallel, all the necessary files for each bit rate, container format, and encryption algorithm combination can be created quickly with minimal latency.

Understanding the nuances of encryption encoding, packaging, and overcoming storage and processing requirements are just the tip of the iceberg regarding the complexities involved with a multi-DRM implementation. Additional challenges include:

• Ensuring consistency in user experiences across all devices with the delay-free acquisition of keys from DRM servers
• Staying on top of ever-changing client devices and associated SDKs, along with operating system variations
• Complying with Enhanced Content Protection (ECP) parameters defined by MovieLabs, and others, for premium and UHD content
• Monitoring and adhering to complex licensing and protection agreements, such as time shifting, catch-up viewing, cloud-based DVR usage, and offline playback

To meet this full set of requirements and ensure that content is protected throughout the workflow, you’ll need to develop a key management solution, set up license servers, and define and manage security policies that determine the conditions under which the content may be played. Our platform, for instance, has a default set of policies that are appropriate for most circumstances. The Studio DRM policy configuration tool can easily configure these policies for each user. Policies are implemented on licensing servers and can cover various variables such as security level enforcement or output restrictions, key duration, playback duration, and whether offline rental is allowed. Policy options can vary considerably across DRMs as well.

‍Key management is key

As with policy management, the platform must handle all aspects of key management and licensing to ensure that your keys are guarded across the entire workflow. Security is easily accomplished with Verizon Media’s fully-integrated platform, but if you’re going to be using separate services, you’ll need a way to transmit keys securely from encoders to your third-party DRM solution. This involves considerable work to implement a standard such as Secure Packager and Encoder Key Exchange (SPEKE), so keys can encode content externally and then be handed over to the license servers. Keeping everything on the same network avoids this step and simplifies implementation.

Once you have the DRM infrastructure incorporated into your workflow, the next big challenge is player integration. This is where we spent significant time going through each player’s SDK to ensure there were no hiccups. A challenge turned out to be server-side ad insertion (SSAI). Since we keep a large library of separately encoded ads to stitch into live events and live channels, these ads cannot all share the same key encryption key(s) as every live event and channel on the platform. To solve this issue, ads must be encrypted with individual keys different from the stream into which they are inserted, repackaged on the fly for each unique stream, or inserted into the stream without encryption.

These variations complicate live stream playout. For example, some players lack support for switching DRM keys midstream. Even with that support, switching can introduce a noticeable effect on the playback experience. A frame buffer may need to be completely drained, and a new key initialization performed before frames with the new key can be queued. Doing so can result in a visible glitch on some platforms.

These challenges led us to leave ads unencrypted to ensure better player performance and avoid the need to perform a key change every time there’s a new ad. Unencrypted ads also lead to better server performance than re-encrypting ads on the fly since we don’t have to repackage each ad with every combination of stream keys we might need. Using unencrypted ads complicates things for players slightly more than just using the same key. Still, many player projects have ensured this is a supported playback scenario over the last few years.

We also worked to simplify the way license URLs work to make them more convenient for specific players. We accomplished this by first putting license server URLs in the manifest, so if a player has support for reading the URL, we don’t need to provide it separately. Then we encode all session-specific data into the Protection Scheme Specific Header (PSSH) box in the manifest. This enables players to use a very simple license server URL for license requests without extra header data or URL parameters. Using the same license URL for players and streams means DASH playback integration becomes extremely simple on our platform.

‍Toward easier DRM integration

One of the overarching goals for our platform is to make streaming simpler and easier for service providers. We’re continuing to expand our use of open-source players such as Shaka Player, an open-source JavaScript library for ABR playback. We have also partnered with THEOplayer, a popular universal video player solution. We continually evolve our platform to keep pace with changing encryption standards and DRM technologies. We understand that many firms don’t enjoy working with DRM, so the more we can make this critical security task like any other item on a checklist, the better.