Digital Rights Management (DRM) is a crucial component of many video streaming setups. If you run a commercial video streaming service, the technology to restrict access to your content and protect it against unauthorized usage is of vital importance, because it enables you to monetize your content.
DRM is not a static technology. As part of the continuous fight against piracy, stricter requirements on content security are developed and implemented. Five years ago, at IBC 2013, Unified Streaming was one of the first to demonstrate a working implementation of multi-DRM, which since has become a widely used technology. Now, we introduce support for a next step in content protection: DRM with multiple keys, which is recommended by Google’s Widevine and Microsoft’s PlayReady, and provides the only viable way to offer the highest level of DRM protection.
Protecting premium features
Whereas multi-DRM makes the simultaneous integration of DRM solutions from different vendors as efficient as possible, DRM with multiple keys is about making content protection more granular, flexible and secure. Using DRM with multiple keys, it is no longer necessary to encrypt all of the audio and video tracks of an asset with the same key.
To understand why such an approach is useful, consider the premium features that can be part of an asset: 4K or UHD resolution, High Dynamic Range (HDR) color as well as tracks with the director’s commentary or additional camera perspectives. Let’s assume that you want to increase the level of security for features like this. Doing so might be necessary because copyright holders, such as movie studios, often require that premium features are protected by the highest level of DRM protection. This level of protection is often referred to as hardware DRM.1
In short, the benefit of hardware DRM is that content is decrypted (and decoded) using a hardware implementation that is specifically certified by a DRM vendor. Such a hardware implementation often relies on a ‘trusted execution environment’ that is separated from ‘ordinary’ CPU operations. This is a logical next step in content security because it is hard to tamper with such a pipeline. This means that it becomes near impossible for a user to extract the encryption key or the decoded content.
A possible setup that uses multiple encryption keys to enforce hardware DRM for premium features looks like this, where different qualities of the content are encrypted with different keys:
Figure 1: Diagram showing the difference between using one key to encrypt a stream, or multiple
Using separate keys for the ‘standard’ and premium features as shown above, it is possible to require hardware DRM support for playback of the latter, while still allowing standard quality playback if only normal ‘software’ DRM is available on an end-user device.
DRM’s secret sauce
To make the need for DRM with multiple keys clearer, some background on how DRM works is necessary. Let’s have a look at what happens on the client-side when a player on one of your customer’s devices receives an encrypted media stream and starts play-out:
Figure 2: Workflow of end-user device handling a protected stream (with or without hardware DRM)
Without going into the nitty gritty details, the player starts of by selecting tracks for play-out (based on things like the capabilities of the device, user preferences and current network speed) and passes the data packets of these tracks to a Content Decryption Module (CDM).2
This is where things get complicated, because each DRM vendor requires its own CDM. They are the DRM’s ‘secret sauce’, black boxes in which encrypted content is decrypted. The most important ones are:
- Google Widevine
- Microsoft PlayReady
- Apple FairPlay
- Adobe Access
- Intertrust Marlin
Hardware DRM
When a CDM receives content to decrypt, it needs a key to do so. This encryption key is retrieved from the license server, which, if the request is valid, returns an opaque blob of data that includes the encryption key with a license that defines play-out restrictions (such as how many times the stream can be watched, or within what timeframe). A request for a license with key is usually made by the player, which passes the blob to the CDM.3
Then after decryption, the content will need to be decoded and the output displayed. With this in mind, let’s rewind to hardware DRM. Because: both the decryption and decoding process can be taken care off by either software or hardware. If both are done in hardware, and the connection from the video output to the display is properly protected as well, the entire delivery pipeline is as secure as can be and you get what is called ‘hardware’ DRM (or: the highest level of protection offered by DRM vendors).
This is easier said than done. For one, both hardware decryption and decoding process need to be compliant with and certified for the specific kind of DRM. If an implementation supports hardware DRM for Google’s Widevine (i.e., ‘Level 1′ protection), this does not mean that it will also support it for Microsoft’s PlayReady (i.e., ‘SL3000’ protection).
In this regard, set-top boxes and smart devices like TV’s, tablets and smartphones are miles ahead of laptop and desktop computers, as the latter only support hardware DRM in very specific configurations.4
Different track, different keys
So, with all of that background info on DRM out of the way: why are multiple encryption keys per asset necessary to implement hardware DRM for premium features? The most important reason is that you should not use the same encryption key for tracks that are protected by a different license, as recommended in the official Extended Media Extensions specification:
Authors should encrypt each set of stream(s) that requires enforcement of a meaningfully different policy with a distinct key (and key ID). For example, if policies may differ between two video resolutions, stream(s) containing one resolution should not be encrypted with the key used to encrypt stream(s) containing the other resolution.
The problem is that if you would use the same encryption key for one track that is associated with a license that requires hardware DRM as well as on another track which license does not include this requirement, the encryption key that protects both track would be handled in a less secure manner when playing back the second track, thus compromising the level of protection on the first track.
Advantage of DRM with multiple keys
On the face of it, this still leaves you with three options:
- Add requirement for hardware DRM to all audio and video tracks of the asset
- Set up two streams for the asset, one of which includes premium features and hardware DRM requirement
- Implement DRM with multiple keys and use one stream that only require hardware DRM for premium features
Let’s start with the first option. Sounds good? Extra protection for all tracks, who wouldn’t want that. The problem is that, as explained above, hardware DRM puts very specific demands on the device that is used to watch the content. If you enforce hardware DRM on all of a stream’s tracks, it makes the stream incompatible with many devices. Play-out on most laptops, desktops and midrange smart devices would simply be impossible.
The second option isn’t any good either, because it is a costly scenario for no real reason. Both streams would be encrypted with different keys although a large part of their contents are the same. This would lead to an unnecessary increase in CDN traffic, and, in setups that make use of statically packaged content, a significant need for additional storage as well.
Of course, what remains is the third option, which allows you to keep your stream compatible with as many devices as possible while also offering the highest level of security for the stream’s premium features.
Conclusion
Although DRM with multiple keys is probably most interesting because of its use for streams that combine regular DRM with hardware DRM for premium features, it can be useful for other reasons as well. For one, it can be used for complete future flexibility regarding the granularity of and asset’s content protection, by using individual keys for each of the asset’s tracks (which Widevine has explicitly recommended since 2016). Another use is to offer a work-around for edge cases when the content of some tracks of an asset does not work well on target devices when encrypted. In such cases, DRM with multiple keys allows you to leave a particular track unencrypted, while keeping encryption in place for all of asset’s other tracks.5
All in all, DRM with multiple keys provides the future of content protection and we think that it will soon be used by many of our customers. If you have any more questions about it or if you are interested in using Unified Streaming to implement a DRM workflow with multiple keys, please contact us.
Footnotes
1. Netflix and Amazon Prime require support for ‘hardware’ DRM to play back 4K content.
2. When playing a protected stream in a browser, the player uses HTML5’s Encrypted Media Extensions (EME) to interact with the CDM.
3. A ‘blob’ can also include several keys and licenses.
4. On PCs, PlayReady’s SL3000 ‘hardware’ DRM protection level is only supported by Intel’s Kaby Lake platform and the latest GPU’s from Nvidia and AMD.
5. One example that we have come across is a rare case where a certain end-user device is unable to play back the DTS track of a stream if that track is encrypted.
