Dealing with DRM - Understanding DRM and How to Produce Protected Content

DRM: an acronym that strikes fear into the hearts of CTOs and developers alike. Digital Rights Management (DRM) is a method of securing digital content to prevent unauthorized use and piracy, and it has become a requirement for many streaming video platforms as more premium content is delivered via the public Internet. 

In a nutshell, DRM ensures that video content is stored and transmitted in an encrypted form, so that only authorized users and devices can play it back. Before it is streamed,  video content must be encrypted and packaged, often using multiple DRM schemes for greater device compatibility. When a user attempts to play back a video, the video player requests a key from a license server. The server determines whether the user and device are authorized, before issuing a license response with a decryption key. The player can then decrypt and play back the content for the user.

The figure below illustrates this process. In this series of posts, we’ll dive into the details of setting up a DRM-protected streaming system like the one pictured, starting with an overview of some of the available protection schemes and how to encrypt and package content for each with static delivery. Then we'll cover how DRM packaging is applied with Dynamic Delivery. 

If you’re using a full-featured online video platform, like Video Cloud, supporting DRM may be as simple as upgrading your account and configuration to enable it. If you’ve customized your player or built out a custom streaming workflow, you’ll need to update and add some components to support DRM.

Enabling DRM requires changes to at least three components of your streaming workflow:

1. Content - your assets must be transcoded, encrypted, and packaged in formats compatible with the DRM systems you need to  support.
2. Player - your video player must be able to request a key from a license server and decrypt the video; this may require different players on different platforms.
3. License Server - your video player will request decryption keys from a license server every time a piece of content is requested; the license server authenticates and responds to these requests.

Though there are many DRM systems available to protect video content, we only need to worry about The Big Three for supporting the most popular web browsers, devices, and set-top boxes:

• Google’s Widevine - Widevine-protected content can be played in Chrome and Firefox web browsers, as well as Android and Chromecast devices.
• Apple’s FairPlay - FairPlay-protected content can be played in Safari on OS X, as well as iPhones, iPads, and AppleTVs.
• Microsoft's PlayReady - PlayReady-protected content can be played in IE11 and Edge browsers, Windows Phone, Xbox, and other platforms via SDKs.

This compatibility chart shows a sampling of popular platforms and their compatibility with these DRM systems. See here for more details.

Platform	Widevine Modular	FairPlay	PlayReady
Chrome
FireFox
Internet Explorer 11
Microsoft Edge
Safari
Android
iOS
Chromecast / AndroidTV
Roku
AppleTV
Fire TV
PlayStation
Xbox One
Samsung Smart TV

Packaging Content
To prevent content from being copied or played back by unauthorized players or devices, DRM requires content to be encrypted. It must also be packaged in a compatible format, generally MPEG-DASH or HLS. This can be done as part of the transcoding process, or assets can be encrypted and packaged after the fact. Some platforms and CDNs also support just-in-time encryption and packaging of assets as they are requested by players.

Widevine and PlayReady both 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 SAMPLE-AES encryption and HLS packaging, which means you will need to encrypt and package your content twice if you need to support all three systems. Zencoder allows you to transcode your content once, and transmux that content to both MPEG-DASH with CENC encryption and HLS with SAMPLE-AES encryption, all in one operation.

For each asset that you want to serve with DRM, you’ll need to generate an encryption key, an asset ID, and a key ID. Both CENC and FairPlay use an AES 128-bit key to encrypt content. For FairPlay, you’ll also generate and provide an Initialization Vector (IV). You can generate these keys and IDs yourself, or use the tools provided by your license server to generate them automatically. 

You’ll ingest these keys and IDs into your license server so that it can be sent to the player, which will use the key to decrypt the content. It’s important to also store this key securely within your platform as a backup; you’ll need access to these keys if you move to a different license server in the future.

The keys and IDs, along with a few other parameters, are also used to encrypt and package the content. The following Zencoder example job illustrates how to encode, encrypt and package content for all three DRM systems, with further description below:

This job has three mp4 encodes (mp4-1500k, mp4-1000k, and mp4-500k), which are then used as the source for both the HLS and DASH outputs. The HLS outputs specify the FairPlay DRM method, the encryption_key, the encryption_iv, and the encryption_key_url. For FairPlay, the encryption_key_url is actually a reference to the asset ID, and the format of this URL will vary depending on your license server’s implementation.

The DASH outputs specify the CENC encryption method and the Widevine and PlayReady DRM systems, as well as a few more fields:

Once your content is encrypted and packaged, it needs to be transferred to your origin server or CDN for streaming to your users. This can also be done as part of a Zencoder job. Stay tuned for the next part of this series, when we’ll dive into how DRM packaging is applied with Dynamic Delivery. 

*Post updated on July 17, 2018 by JD Russell.