DRM for All Screen Types? Not So Straight Forward
The very nature of any type of security implementation is considered complicated. Implementing a multi-DRM solution takes this complication to another level, as it requires implementation with multiple sets of components in an OTT ecosystem. Complication gets elevated as these components might be either developed in-house or a 3’RD party solution necessary for OTT service (Read Buy vs Build Dilemma in OTT).
Below is a snapshot of a basic implementation of a multi-DRM solution integration with an OTT service.
Integration Objectives for Multi-DRM solution can be broadly listed as below:
- To be able to integrate with players (of all screen types) i.e.
- To be able to integrate with OTT service provider’s Encoder
- To be able to integrate with OTT service provider’s back-end system.
DRM to implement for a given screen/player type:
| HTML5 | Widevine Modular | Playready | Fairplay |
|---|---|---|---|
| Chrome (on WINDOWS, MACOS, ANDROID, CHROME OS, LINUX) |  |
 |
|
| FireFox (only on computer, and not on android/iOS) | |
|
|
| Safari (on Mac and iOS) | |
|
|
| Edge (PlayReady supported on Windows computers only) | |
|
|
| Internet Explorer 11 (on Windows 10 and 8.1) | |
|
|
| Mobile/Tabs | |||
| Android 5+ | |
|
|
| iOS 10+ | |
|
|
| Set top Box and casting | |||
| Chromecast | |
|
|
| Apple TV | |
|
|
| Amazon Fire TV | |
|
|
| Roku | |
|
|
| Smart TVs | |||
| Samsung Tizen (2018+ models) | |
|
|
| LG WebOS 3.3+ | |
|
|
| Android TVs (TCL, Hisense, MI…) | |
|
|
| Gaming Console | |||
| Xbox One | |
|
|
App/Video Player on each of the above devices needs to be integrated with the respective multi DRM solution (as mentioned in the above table). Integration can be carried out either by implementing the relevant DRM SDKs (as provided by DRM provider) or by using DRM APIs. Below are the pros and cons to consider for each implementation type.
SDK Vs API based integration:
SDK integration is good for quicker operational turnaround time, since these SDKs can simply be bundled with the OTT app. And may offer some additional security features which might not be possible for API based implementation on older android devices. E.g. Secure Clock feature (to resist time based tampering attack) is implemented by Google from android 8 onwards. i.e. with API based implementations, one has to expect the weaker DRM capability implementation if the android version is below 8. With SDK based implementation, such limitations can be resolved by adding fixes for such issues in SDK itself even for the olde android version.
However, SDK based implementations become bulky and significantly increase the app size (e.g. some widevine SDKs can add ~15-20 MBs of size to the APP). Due to this reason alone, many service provider prefer to go with API based implementation (even when such implementations take little more time comparatively) by writing off some risk on lower android version device (by delivering lower resolution content there); where as all the DRM related capabilities are same in SDK or API based implementations as long as the higher android versions are considered.
Challenges with some secondary DRM functions:
Apart from secure encryption and decryption of the content, below are two of the important features of DRM implementation which explains exactly where the DRM implementations are not so straight forward.
- Protection against screen capturing/recording/grabbing
- Output protection (HDCP and CGMS-A)
Protection against Screen capturing:
This functionality is available by default for hardware level DRM implementation from all three DRMs (e.g. Widevine Modular Level1, Playready SL3000 and Fairplay DRMs (with OS 12+)). However this protection is mainly available on native app implementation types on mobile devices but not necessarily on browser based playback on android devices.
E.g. if an android device is capable to support widevine Level 1 implementation, then it provides protection against screen capturing during content playback using android APP.
But the same device can’t provide the same protection when the user is playing the content on browsers (like chrome). Firefox etc. are out of the question as they don’t provide support for widevine DRM while being consumed on android devices. However, if the service provider has a strong use case to provide the chrome browser based playback on android mobile and they also would like to ensure protection against screen capturing, then they need to invest into chrome specific screen capture protection solutions like this anti screen capture.
Output protection(HDCP/CGMS):
Once enabled with right configurations, DRM solutions can provide capability to protect against recording through digital output (e.g. HDCP) or analog output (e.g. VGA etc.) signals.
Once engaged, this ensures that the delivery of HD quality content will not be copied out by using HDMI or VGA type of digital or analog output. This capability is only available with devices capable of supporting the hardware level of DRM implementation (e.g. Widevine Level 1 for android). For devices with software only implementation (e.g. widevine level 3 on android) are not able to provide this capability.
However, even for the devices with hardware level DRM support, it is not as easy to achieve as it sounds, due to the complex nature of HDCP implementation at device end. Following scenarios may create complications:
- No differentiation between internal and external output: Device may not differentiate between external HDMI output and internal screen where the content needs to be rendered. In this case, even the rendering to the device’s own screen might be blocked. Due to this, if the HDCP is engaged on such devices, then the screen of such devices may go blank. This will for sure ensure the content protection, but also will ensure to ruin consumer’s experience.
- HDCP disconnected or unprotected: Even if the device can support the hardware DRM (e.g. widevine modular level 1) it does not guarantee that the implementation to engage with the HDCP will be accurate. This results in multiple devices mistakenly providing unconnected/unprotected HDCP. I.e. HDCP policy of DRM can’t be engaged with such devices (even if they are widevine level 1 compliant)
Summary:
Though it is possible to distribute the content on all device/screen types. But not all clients offer all types of protection (e.g. protection against screen capture or output recording etc.).
The choice of all non-native distribution types (e.g. browser based delivery of full HD content on android mobile and not app), should be made if the content licensor doesn’t bother about such requirements. But if they do, one must stick to classical distribution methods (e.g. Full HD content payback only on mobile apps and not on browsers on devices like android).
Side note:
For an OTT service, implementation of a MultiDRM solution (i.e. from Google’s Widevine, Apple’s Fairplay and Microsoft’s playready) is necessary, since content providers (like (Disney/Fox, Sony, WB etc.) allow distribution of Full HD content (i.e. up to 1080p resolution) via an OTT platform only when the hardware level of DRM implementation can be achieve (Otherwise only the resolution below 720p or 576p is allowed).
And the hardware level DRM implementation on Google’s android Devices is only possible with google’s own Widevine DRM. Similar is the case with Apple’s fairplay on apple’s devices and Microsoft playready with some SmartTV’s and gaming consoles (like microsoft Xbox one).
Praveen is a technology evangelist with vast experience in OTT domain. He has deep understanding of end to end OTT ecosystem (i.e. approximately everything between content ingestion to delivery including CMS/MAM, RMS, Video Encoder & player content/App security, DRM etc.).
Praveen understands the product management functions and agile software development methodologies very well. His over 15 years of experience includes work in organizations of various sizes; e.g. from a start-up to one of the top 50 companies in fortune 500 list etc. He has helped shaping content distribution technology and content protection part of many of the well known OTT players in India, MEA and SEA regions during his stint with one of the fortune 50 companies.