Recently we had the pleasure of working with Jan Ozer again on another extremely informative piece on "How To Protect Your Content With DRM." Jan has an innate ability to capture the essence of deeply-technical issues like Digital Rights Management. In the past we have supported his efforts to that effect by providing some secondary editorial and content suggestions and access to our platform and marketing communications. This article is another must-read for seekers of DRM knowledge. It's a universal article that describes all the components of a successful DRM deployment in an easy to read and engaging format. So take a minute and walk through this piece from Jan. It's going to increase your DRM knowledge and enable you to advance your OTT business.
This article originally appeared in the March 2019 issue of Streaming Media Magazine and was written by Jan Ozer. To view the original article, click here.
You’ve been distributing unsecured video from your website, and you’ve decided that you need content protection in the form of digital rights management (DRM). Perhaps it’s to protect premium content that you’re selling, or perhaps to control access to training, marketing, sales, on-boarding, or other proprietary or confidential videos. In this tutorial, we’ll describe what DRM is, how it works, which DRM technologies you’ll need to implement, how to choose a technology partner, how to encrypt, and how to license acquisition to your video player.
DRM involves encrypting your content so it can’t be read without a decryption key supplied by a third-party DRM platform that includes license servers. This concept of third-party DRM platforms is one of the key features that separates true DRM from simple encryption like what’s available for HLS via AES 128-bit encryption. Since simple encryption is both cheaper and easier than true DRM, it’s a useful distinction to understand, so let’s start there.
To deploy AES 128-bit encryption, you encrypt your content during packaging. During playback, the player clicks the link with the content and starts the download, often from an HTTP server (see Figure 1). Simultaneously, the browser seeks to retrieve a decryption key from the location specified in the manifest file, typically from an HTTPS server so you can require authorization before the key is downloaded. In this schema, access to the keys would only be available to members or employees who have access to protected content in the HTTPS site.
Figure 1. Simple encryption protects the key via HTTPS.
There are two major problems with this approach. First, at some point during the retrieval of the decryption key, it’s available in the browser cache, where it can be easily be grabbed. Second, whoever has the decryption key can decrypt the video; there’s no additional authorization between player and server to verify that the viewer should be able to watch the video.
Now let’s look at true DRM. By way of background, all the DRM tools we’ll discuss will be implemented within either the HTTP Live Streaming (HLS) or Dynamic Adaptive Streaming over HTTP (DASH) architectures, though many producers will need to support both.
That’s because you’ll need HLS to reach Apple devices in the browser, and you’ll need DASH for most other devices. Currently, this requires two sets of files, one for HLS and one for DASH, though this will change over the next few years (more on this below). Currently, the only DRM supported with HLS is Apple’s FairPlay. In contrast, DASH supports a range of third-party DRM solutions like Widevine and PlayReady via the Media Source Extensions (MSE) and Encrypted Media Extensions (EME). Note that if you’re running on iOS devices via an app, you have much more flexibility and likely can use DASH with one of the supported third-party DRMs.
True DRMs have multiple advantages over simple encryption. First, as you can see in Figure 2, communications are handled via the Content Decryption Module (CDM) that’s a component of every compatible EME device. Using a challenge/response system, these communications are encrypted so the decryption key is never out in the open where it can be hacked. In addition, the communications between the licensing server and browser can confirm that the viewer has a valid, unrevoked player to watch the video. So, true DRM is simply more secure. As we’ll discuss below, true DRM also enables a number of business rules that are not supported with simple encryption.
Figure 2. True DRM involves a licensing server.
As shown in Figure 2, most true DRM integrations involve both a DRM licensing server and a subscription server maintained by the video service. Sometimes license requests are routed through the licensing server, sometimes through the subscription server. Either way, among other functions, the subscription server verifies the viewer’s rights to play the content while the DRM licensing server verifies player identity and issues the license. This enables and simplifies more advanced features like offline playback and preventing playback via unauthorized hardware like HDMI via the rights objects contained in the DRM license key.
Using True DRM
Within consumer web browsers and using EME, DASH supports DRM technologies via what’s called Common Encryption, a specification that enables multiple DRMs to be built into a single DASH package. This is necessary because of fragmented support by EME-compatible browsers and devices. EZDRM hosts a detailed chart you can view at go2sm.com/ comparedrm, but DRM support falls out just as you would expect it do.
That is, Google supports its own Widevine DRM in Chrome, Android, Android TV, and all Android OTT devices and smart TVs, while Microsoft supports PlayReady in Edge, Internet Explorer, Xbox, and other Microsoft platforms. Apple supports its own FairPlay DRM in Safari, iOS, and Apple TV platforms. Again, if you’re distributing to mobile viewers via an app, you have much more flexibility and can likely use PlayReady and/or Widevine via DASH on iOS devices. For playback in Safari, HLS with FairPlay is your only option, as it is for AppleTV.
The bottom line is that many producers will have to create two sets of assets; one encrypted with FairPlay and cipher block chaining (CBC) for Apple, and the other encrypted with Widevine and PlayReady and counter mode encryption. As you can see if you check the aforementioned chart, between the three DRM technologies, you can deliver protected content to the vast majority of relevant platforms in computer, mobile, OTT, game consoles, and smart TVs.
Via a specification called the Common Media Application Format (CMAF), the DRM market is moving toward a single set of CBC-encrypted files that can support all three DRMs. In the short term, however, this approach wouldn’t work for a significant number of legacy DASH and HLS devices and players, which is why most producers either support two sets of files or use dynamic packaging to create the appropriate DASH or HLS content for each player.
Third-Party DRM Providers
Fortunately, as EME was formulated and the need for multiple DRM support became clear, many DRM providers diversified and started offering PlayReady, Widevine, and FairPlay DRM, plus several other DRMs important in other markets. Such vendors include Microsoft Azure, BuyDRM, DRMtoday, EZDRM, ExpressPlay, Nagra, Synamedia, Verimatrix, and Vualto. This is just a partial list; if you’re from a DRM provider that’s not mentioned, please add your name on the Streaming Media website via a comment.
To create this tutorial, I worked with BuyDRM and EZDRM. Both could provide all required licensing to offer my test content with FairPlay, PlayReady, and Widevine protection.
At a high level, there are three touch points with DRM providers. You need to obtain keys to encrypt your content, and obtain a license, or the decryption key, to play the content. Both of these basic tasks can be accomplished pretty simply as demonstrated below. You’ll probably also have to establish communication between the license server and subscription server, which may be more complex and is beyond the scope of this tutorial.
STEP 1: LIST YOUR REQUIREMENTS
That’s the background; let’s get started on how to choose and implement DRM tools. Your first step is to define your requirements.
One benefit of true DRM solutions is the range of supported business rules, like offline playback. Some business rules you’ll want to support as features for your customers, while others will be imposed by content owners if you’re distributing third-party content. Start by creating a list of business rules that your DRM solution will need to support.
Which target platforms do you plan to serve, and how do you plan to serve them? For browser-based support for computers and mobile devices, almost any DRM provider should suffice. If you’ll be using an app for iOS and Android, look for a provider that supplies a secure-player software development kit (SDK) or other implementation assistance for these platforms. If you’ll be supporting OTT devices and/or smart TVs, you’ll want to learn how a provider can help you access these platforms.
In-House or SaaS Deployment
Most companies will want to work with their service providers on an SaaS basis, a model almost all DRM providers support. If you want to install a license server yourself, you’ll likely have fewer options since not every DRM provider licenses its technology for this business model.
Your encoding platform will need to acquire encryption keys to protect your content. While there are generic ways for an encoder to acquire keys from any service, it’s simpler if your DRM provider has already partnered with the encoding vendor to provide a custom integration that requires little or no programming. You’ll see some examples of that below. If you’re just starting out, you may also want to choose a DRM provider that can supply encoding or packaging tools for you, which will already contain the required integration and will be even simpler. Most vendors list their integrations on their websites, like BuyDRM does and EZDRM does.
There are generic ways to acquire licenses programmatically from any DRM provider, but you’ll be up and running faster and cheaper if there’s an existing integration that you can implement. Again, most DRM vendors list their existing integrations on their websites.
Integration Between Licensing Server and Subscription Server
All DRM shops provide APIs for this; check the APIs for all candidate services to gauge ease of integration and ongoing maintenance.
STEP 2: CHOOSE YOUR DRM PROVIDER
For simple SaaS implementations for browser-based playback of Widevine-, PlayReady-, and FairPlay-encrypted content, you’ll have many candidates that can meet your needs. The keys here will be license and support pricing and ease of integration.
If your needs are more complicated and involve mobile app SDKs, the licensing of other applications like an encoder or player, or the ability to run the multi-DRM server in-house, then fewer DRM providers will be able to check all of your required boxes. Identify those that can meet your needs and then, again, focus on overall cost and ease of integration.
STEP 3: ENCRYPT YOUR VIDEOS
We’ll show three examples of encrypting your videos, one using EZDRM and open source packager Bento4, another using BuyDRM as accessed via AWS Elemental MediaConvert, and a third using Wowza Streaming Engine via EZDRM.
Encrypting With EZDRM and Bento4
This process is outlined in a document titled EZDRM Bento4 Configuration Open Source. By way of background, Bento4 is an open-source packager used in many encoding and packaging pipelines. To acquire the DRM key, you log in to the EZDRM web service manually or via cURL or a different web service call. This returns the XML file shown in Figure 3, which provides keys for PlayReady and Widevine.
Figure 3. XML file received from EZDRM with DRM Key
After fragmenting your MP4 file using Bento4’s mp4fragment application, you integrate the data supplied in the XML file into the mp4-dash.py command shown in Figure 4. The entries are color coded to match the color codes in Figure 3, which is how EZDRM presents this in its documentation. Copy the data according to the colors, run the application, and you produce your encrypted data plus the Media Presentation Description (MPD) manifest with the necessary Widevine and PlayReady metadata.
Figure 4. Integrating the XML data into the Bento4 packaging application
To produce FairPlay-encrypted packaging, you run a similar process using the Bento4 mp4hls application.
Encrypting With BuyDRM and AWS Elemental MediaConvert
BuyDRM has integrated its KeyOS Multi-DRM platform with AWS Elemental’s MediaConvert using the SPEKE API (Secure Packager and Encoder Key Exchange). In this example, we implemented the integration from BuyDRM to encrypt and package our content. BuyDRM does a nice job of documenting what’s required in a video and blog post. Note that some technical details are omitted in the pubic tutorial, but are available once you sign on as a BuyDRM customer and access the tutorial on BuyDRM’s Wiki.
Basically, the tutorial walks you through a bunch of AWS “stuff” like creating roles and permissions and setting up API gateways. Nothing technically onerous, but a meticulous process you should be able to finish in 30 minutes or so. Once complete, encryption becomes available within the MediaConvert interface as shown in Figure 5, which is set up to encode a group of files to HLS encrypted with FairPlay. Obviously, you can access the same method via MediaConvert’s API, which is how most larger shops will produce their content.
Figure 5. Accessing BuyDRM encryption from within AWS Elemental MediaConvert
Encrypting With EZDRM and Wowza Streaming Engine
Figure 6 shows how you would access EZDRM encryption from within the Wowza Streaming Engine after performing an integration (note that Wowza has similar integrations with BuyDRM and Verimatrix, and also supports custom integrations). The obvious point is that while custom DRM integrations aren’t rocket science, adding encryption to your encoding workflow is simpler when integrations exist, a factor you should strongly consider when choosing DRM providers.
Figure 6: The EZDRM Wowza Streaming Engine integration
STEP 4: INTEGRATE DRM LICENSING SERVER WITH SUBSCRIPTION SERVER
Most DRM providers supply a dummy authorization URL you can use for decoder testing, but for live production you’ll need to integrate your licensing server with the subscription server (see Figure 2).
STEP 5: PLAYER INTEGRATION
Player integration will vary by DRM provider. One level of integration is shown in Figure 7, where the Bitmovin Player is playing a video encrypted with Widevine and PlayReady by EZDRM. In the test player, you choose the ABR technology (DASH), insert the URL of the DASH MPD (the S3 address), and then the authentication URL provided by EZDRM (the EZDRM address). In the actual Bitmovin (or other) player, you would insert the address of the DASH MPD and HLS M3U8 manifests and authentication URLs for Widevine, PlayReady, and FairPlay. The browser client chooses the appropriate manifest and DRM automatically.
Figure 7. Playing EZDRM encrypted content in the Bitmovin player
Each DRM provider defines its own license acquisition processes. Rather than using an authentication URL, BuyDRM uses XML to authenticate and authorize license requests from video operators and to set the license policies. You see this in Figure 8, which shows the BuyDRM KeyOS WebPlayer playing Netflix Meridian protected by FairPlay. On Safari Mac, in addition to the Stream URL and authentication XML, you need a link to the FairPlay Certificate. You can read an explanation of this process and how to generate the XML in a blog post entitled “Advanced Techniques Authentication XML.”
Figure 8. BuyDRM’s KeyOS WebPlayer uses XML to authorize playback.
By design, off-the-shelf players are sufficiently flexible to accommodate the different authorization schemes used by the different vendors. Before choosing a DRM provider, however, you should understand how they authenticate license requests and how this technique will integrate with your player.
What Will It Cost?
Pricing will vary by service provider and (of course) by the products and services that you actually license. BuyDRM offers licensing, packaging, and an HTML5 player with separate charges for each, along with player SDKs for iOS and Android and licensing packages. BuyDRM doesn’t publish its prices but offers KeyOS MultiPass at $99/month (with 10,000 licenses) and KeyOS MultiKey with higher-volume packages and unlimited enterprise plans. BuyDRM also licenses its MultiKey Server for on-premise support. EZDRM does publish its prices; they start at $199.99 per month for 10,000 licenses.
When comparing license charges, be sure to ask about these:
- Pricing for all necessary DRMs, with minimums and overage charges
- Pricing for any set-up charges
- What level of support is included with the available license package
Over the last few years, DRM has become cheaper and more technically accessible. If you’ve been considering adding DRM to protect your content, there’s never been a better time than now.
The author wishes to thank Roman Kozenov and Christopher Levy from BuyDRM, and David C. Eisenbacher and Olga Kornienko from EZDRM for their guidance and assistance while creating this article.
[This article appears in the March 2019 issue of Streaming Media Magazine as "How To Protect Your Content With DRM."]