FAQ: Digital rights management
We’ve gathered answers to common questions relating to digital rights management (DRM).
Not finding what you’re looking for? View our other FAQs, or simply contact us.
Why is DRM required to digitally distribute studio content?
The movie and TV industry is highly protective of their assets and impose strict rules on distribution to prevent piracy. For example, the Motion Picture Association of America (MPAA) has campaigned for DRM to be implemented in online video delivery scenarios. If you wish to digitally distribute studio content through your service, you will be required to have a DRM solution in place.
While it is always up to individual studios, security dependent quality limitations are usually imposed on service providers licensing content. In general, a licensee is typically restricted to delivering SD (480p) quality streams across devices utilizing software-based DRM, while HD (720p+) and especially 4K/UHD delivery requires a hardware-secured DRM system to be in place. Providing 4K/UHD quality content can also require hardware-secured DRM along with additional security requirements such as forensic watermarking.
What does encryption do to a video?
During the encryption process, an algorithm scrambles the video file to prevent playback. This is achieved with a content key which is a piece of unique data used in conjunction with the algorithm to both encrypt and decrypt the video content. To maximize security, a different key is usually used for every individual video and it is also recommended to use different keys for each asset component (for example: audio, SD video, HD video).
A user’s player application is only able to decrypt content for viewing if it possesses the same key the video was encrypted with. These content keys are typically stored on a secure licensing server such as our DRMtoday service for delivery to a user’s video player.
Without the correct content key, an encrypted video appears blank or scrambled. This makes it completely unwatchable by unauthorized viewers.
Video encryption/decryption is a symmetric crypto operation (i.e. uses the same key for encryption/decryption) as opposed to asymmetric operation (public/private key) used in HTTPS for example.
What is delivered during a DRM license request?
When a user wishes to watch a DRM-encrypted video, their player must receive licensing information to decrypt the content for playback. The licensing information required is specific to the DRM system the user’s playback application supports (which can differ from one device/platform to another). This means when our DRMtoday service delivers a license to a user, the information that gets sent is based on which DRM system is supported by the user’s player application.
For example, the licensing information delivered to a player using Microsoft PlayReady is different from the information sent to a player using Google Widevine. Both systems are compatible with Common Encryption, however, it is the license delivery process that creates the main differences between competing DRM systems.
Regardless of which DRM system a player uses, the licensing information delivered is always made up of a number of general elements:
- The content key: a piece of unique data used as part of an algorithm to encrypt and decrypt video content. A different key is typically used for every individual video asset to maximize security.
- Play duration (for example: purchased content or timed rental)
- If a license should be persistent (i.e. no further license requests after the first license delivery)
- Additional restrictions (for example: hardware-secured DRM only)
See how our DRMtoday licensing works Compare device/platform DRM support
What’s the difference between hardware and software secured DRM?
Software-based DRM protection can be built either into a device’s OS, a playback platform, or enabled via an application based SDK. DRM licensing, decryption, and decoding typically occur in the “user-space” of an OS which is part of a device’s memory where applications are executed. For example, browsers typically use this method to handle DRM encrypted content.
For a greater level of security, processes can be run in a software-based Trusted Execution Environment (TEE), also referred to as a Software Secure Element (SSE) or White-Box Cryptography (WBC). A TEE is a secure environment for executing sensitive processes, protecting secret keys in DRM licenses, and protecting data buffers such as decrypted frames. Think of it as a safe for securely storing data and running processes. This method provides the highest security level for software DRM environments. Using this approach, content decoding can either occur in the TEE utilizing a software decoder, or it can also run through a hardware-supported codec (outside of the TEE).
However, in all software DRM implementations, the player application itself takes the decrypted/decoded content and pushes it to the device’s screen. This requires that video data leaves a protected environment at some stage and can potentially be handled by vulnerable software outside of the control of the DRM implementation.
To improve security further, some devices have a TEE pre-built inside its hardware as a closed-system where all licensing, decryption, and decoding operations occur within a chipset. This provides maximum content security from outside access as it’s much more difficult to compromise data and code loaded inside of a hardware chip compared to software-based processing. It’s also possible to directly integrate secure display hardware with hardware TEEs.
Using this hardware approach, the player application receives the DRM license and encrypted content and passes both into the TEE on the device’s chipset. All media decryption/decoding is processed within the chip. Content is then pushed directly from the chipset to the device’s screen where no API exists to access the data in transit (with the display connection encrypted as well, e.g. via HDCP). Content licenses along with both the decrypted compressed/uncompressed video frames are highly unlikely to be available for interception outside of the device’s TEE.
This difference in security is the reason studios typically mandate content quality restrictions based on the level of DRM protection used.
To utilize a device’s hardware-based DRM feature, player applications as well as the licensing service used will need to specifically:
- Support the hardware-security level of a given DRM system
- Enable its detection
- Limit content playback selectively to such a security level
Our PRESTOplay video player SDKs facilitate both software and hardware DRM deployments. Hardware-secured TEEs are used whenever present in a playback device, and we also provide a software-based TEE for improved security on mobile devices that don’t offer native hardware-protection.
Our cloud-based DRMtoday multi-DRM licensing service enables the detection and enforcement of both hardware and software based DRM security levels. This also includes PlayReady SL3000 and Widevine security level 1 hardware-protection.
Which browsers support DRM for video?
For a browser to support built-in video playback with DRM protection it must support HTML5 as well as Encrypted Media Extensions (EME). Popular browsers that are able to use DRM as part of their native platform include:
- Chrome
- Firefox
- Microsoft Edge
- Safari
- Opera
- Internet Explorer 11 (for Windows 8.1+)
What are Encrypted Media Extensions (EME)?
Encrypted Media Extensions (EME) is a JavaScript API specification that provides a method for browsers to interact with CDMs for utilizing DRM in browsers. JavaScript can access EME to communicate information between a CDM and a server that provides decryption keys such as our DRMtoday service. It enables encrypted video playback directly in HTML5 (using the <video> tag) without the need for additional third party plugins such as Silverlight or Flash.
What is a Content Decryption Module?
A Content Decryption Module (CDM) refers to the client-side DRM component of an application which performs the decryption, decoding, or enables playback of encrypted video content. Different platforms use different CDM technology. For example, Google Chrome uses the Google Widevine CDM to decrypt DRM protected content for playback within the browser.
What is Common Encryption (CENC)?
To help simplify the fragmentation of the DRM market, a standardized method for enabling video content protection has been adopted by leading DRM systems called Common Encryption (CENC). CENC is an ISO 23001-7 standard that defines a common format for encryption, decryption, and key mapping methods.
A primary goal of CENC is to allow a single content file-set to be encrypted only once for distribution across numerous playback devices/platforms which use different DRM systems. The benefit is a reduction in cost and complexity of digital video delivery. As one example, the same encrypted video can be decrypted for playback by both Microsoft’s Edge browser (via its Microsoft PlayReady CDM) and Android apps (which use Google Widevine).
You can take advantage of CENC when using the MPEG-DASH or HLS (when using an fMP4 container) streaming formats.
| Stream format | Container format | Compatible with CENC? |
|---|---|---|
| MPEG-DASH | fMP4 |  |
| HLS | fMP4 | |
| HLS | MPEG-2 TS |  |
The CENC encryption process is not proprietary to individual DRM systems and video content essentially becomes DRM-neutral: the same file-set works across MPEG-DASH and HLS players meeting the standard’s spec when a compatible DRM system is used.
It’s worth noting that CENC does not govern other DRM activities. Individual DRM systems retain control of elements such as license distribution, rights mapping, and compliance which means these processes vary from one DRM system to another. This is because CENC only standardizes the encryption and decryption phases. Thus, you will always need a DRM service to provide licensing for the specific DRM system that a given player supports.
Popular CENC-compatible DRM systems include:
The CENC specification supports both CTR and CBC encryption modes. However, there are limitations to be aware of when using protected HLS and MPEG-DASH content across devices. For example, not every DRM system or playback platform supports the same encryption modes, and Apple generally doesn’t support DRM-secured MPEG-DASH.
What’s the difference between CTR and CBC encryption modes?
There are two prevailing methods used for encrypting video content, both of which are part of the Common Encryption (CENC) standard.
- AES-CTR (Counter)
- AES-CBC (Cipher Block Chaining)
Both modes serve the same end-use: to encrypt streams so they can be securely delivered and decrypted with DRM licensing by a player. However, these modes handle encryption differently and aren’t compatible with one another. Support for each is also not uniform across technologies.
| DRM System | AES-CTR | AES-CBC |
|---|---|---|
| Widevine | |
|
| FairPlay Streaming | |
|
| PlayReady (version 4.0+) | |
|
| PlayReady (version 1.0 – 3.3) | |
|
| WisePlay | |
|
| Streaming Format | AES-CTR | AES-CBC |
|---|---|---|
| MPEG-DASH (using CMAF) | |
|
| MPEG-DASH | |
|
| HLS (with or without using CMAF) | |
|
Older versions of Widevine-enabled platforms as well as MPEG-DASH players may not support AES-CBC.
This fragmented support creates a barrier for single file-set streaming which is a goal for streaming services to reduce their delivery chain’s cost and complexity.
Using the Common Media Application Format (CMAF), you could potentially reach many consumer screens with a single DRM-enabled file-set, however, limitations currently exist:
- HLS & Apple devices only support AES-CBC, so this encryption mode would need to be used.
- Support for AES-CBC isn’t available across all non-Apple platforms.
- Manifests must be provided to the player as either .MPD (for MPEG-DASH) or .M3U8 (for HLS) based on what the playback environment supports. A player may support MPEG-DASH but not HLS, and vice versa. For example, Apple platforms don’t natively support MPEG-DASH manifests. Player applications would need to take into account either manifest translation, or both .MPD and .M3U8 manifests would need to be created along with player logic for selecting the required manifest.
In practice, this means that unless all of your target playback platforms support the same AES mode, two file-sets are still needed today (one using AES-CTR and one using AES-CBC).
Looking to extend your existing AES-CTR/MPEG-DASH content to iOS, iPadOS, or native macOS apps? Using our PRESTOplay for iOS and PRESTOplay for Web Apps SDKs, you can deploy iOS/iPadOS and macOS player apps using AES-CTR encrypted MPEG-DASH content with the Widevine DRM system. This lets you bypass the need for HLS/AES-CBC formatted content and Apple’s FairPlay Streaming DRM system.
How do I deliver protected content with HbbTV?
HbbTV® (Hybrid broadcast broadband TV) is an international open standard specification for video delivery via internet-capable TVs, set-top boxes, and multiscreen devices.
As of HbbTV’s version 1.5 spec, DRM was introduced through Common Encryption (CENC) when using the MPEG-DASH adaptive streaming format. This means that you can achieve secured playback through HbbTV compliant technology using MPEG-DASH and a CENC-compatible DRM system such as Google Widevine or Microsoft PlayReady.
If you’re looking to deliver content to HbbTV devices, we can help.
Preparing content for HbbTV
You will first need to convert your content into the MPEG-DASH streaming format. These video assets will also need to be encrypted to provide DRM protection. Our robust cloud-based Video Toolkit encryption and packaging service can both create and secure MPEG-DASH file-sets for you, ready to deliver or to place on a CDN.
DRM licensing for HbbTV
To deliver protected MPEG-DASH content to end-users for playback, DRM licensing will also need to be in place for decryption. Our streamlined DRMtoday license service provides access to multiple DRM systems that are compatible with the CENC standard detailed in the HbbTV specification.
If you have questions about delivering video with HbbTV, please contact us for more information.
What’s the difference between AES-128 and DRM?
Read our blog article to learn about the differences between using only AES-128 encryption and a full-fledged DRM system.
Have another question?
If you haven’t found the answer you were looking for, please contact us. We’ll be happy to discuss any questions you may have.