When it comes to over-the-top (OTT) video distribution, we are seeing many of our customers opt for a multi-DRM approach. This means utilizing the DRM client that is pre-integrated into the viewing platform instead of installing a DRM. These natively available DRMs – the native DRMs – are developed and deployed by Microsoft, Google and Apple to enable their device and software ecosystems to playback rights-protected content. Android devices and the Chrome browser come pre-integrated with the Widevine DRM; iOS devices and Safari come pre-integrated with Fairplay; Windows devices, IE/Edge browsers and also numerous OEM devices such as smart TVs come pre-integrated with PlayReady, thanks to Microsoft’s licensable DRM SDK.
The native DRM clients provide essential technology to process a DRM license, and decrypt content, but where does the other system functionality come from? A working content protection system needs to support content preparation, license generation and client device playback, and do this across multiple native DRM technologies. The native DRMs generally provide sufficient functionality out-of-the-box for client device playback, but fall short on functionality for license generation and content preparation.
For license generation, a typical content protection system needs to handle device identification and activation (i.e. associate a uniquely identified device to a specific household/account), validate license requests, authenticate the requesting device and subscriber, authorize license requests, determine applicable business rules and subscriber-entitlements, translate entitlements and business rules to the terminology and functionality supported by each native DRM scheme, supply the appropriate encryptions key(s) and generate the license in compliance with the relevant native DRM spec. System monitoring, logging, reporting and management interfaces are also required to be implemented.
When deploying more advanced content protection features like key rotation on live channels, event-based entitlements or concurrency controls, then authorizations, license request and license issuance requires further development to make work on top of the native DRM client.
The content protection system also needs to be integrated with the content preparation workflows to generate, store and supply content encryption keys, encrypt each streaming format to spec (HLS, HSS, DASH, etc.) and append the correct DRM meta-data to the content.
So what exactly do the native DRMs provide beyond client playback support? For the most part, they provide you with a spec, SDK, or sometimes a rudimentary cloud service to generate the license, but you are mostly on your own when it comes to implementing the system functionality described above. FairPlay provides a DRM client and a specification for how to generate licenses. PlayReady provides an SDK and specifications for how to incorporate business rules into the license. Recently Microsoft has added an Azure hosted DRM license service option, but it too needs to be integrated with an authorization service and the content preparation workflows. Widevine provides a cloud-based license service that receives a token that tells it which business rules to incorporate into the license.
In summary, multi-DRM does not mean that you get your content protection system for free – it simply means that you will not deploy a DRM client to the playback device. Building out the rest of the system requires an experienced team to architect, build, integrate and maintain over time.
P.S. Securing the content protection system itself against attack is a serious and non-trivial consideration that was not discuss in this blog post. How do you protect, detect and respond to service breaches and incidents of piracy? You can read more about that in our Multi-DRM Strategies for Video Service Providers Whitepaper.
1
1
1
1
1′
1
1
1
1
1
1
1
1
1