Keeping OTT Content Secure: Tokens and DRM
April 29th, 2020 | By Jscrambler | 3 min read
Generally speaking, tokens provide a way to protect content from being shared or embedded in third-party players. So, how can OTT providers ensure that only legitimate, rightful users can access their content?
There are different approaches to achieving this. One is to generate a random token on the server for the authenticated client, save it as a hidden same-site cookie, and use this cookie to validate every content request. This prevents the user from illegitimately sharing the content, as it will lack the corresponding valid token.
Another approach is to attach a token ID (usually a hash) to the URL of the content. This allows the server to detect if a request is coming from a legitimate client.
While these approaches generally work well for web services, they are not a good fit for the high stakes of OTT media delivery. As such, the industry relies on a robust and mature licensing system known as Digital Rights Management (DRM).
DRM is a digital licensing system that allows content owners to define how and by whom their content can be accessed.
Because of its robustness and proven track record in fighting piracy, DRM is widely employed in industries that range from video games and music to coffee makers and tractors.
While DRM is a term broadly applied to describe this system, there are different application approaches.
Some of the DRM systems on the market today include Microsoft PlayReady, Apple FairPlay, and Google Widevine, which are incidentally owned by 3 of the biggest tech companies in the world.
Let's dig a little bit deeper and look at how a DRM system works behind the scenes in the context of the Web.
We can divide this process into three steps: encryption, licensing, and decryption.
Step 1: Encryption
In the first step, the DRM system requests an encryption key and encrypts the content with a symmetrical algorithm like AES. For every key, a corresponding content ID is stored on the licensing server.
Step 2: Licensing
In the second step, the user requests access to the content by contacting the server. If the user is authorized, it receives the encrypted content stored on the server or CDN. Then, the EME API comes into play, allowing the client to securely interact with the licensing server, obtain the decryption key associated with the content, and deliver it to the Content Decryption Module.
Step 3: Decryption
And here we have the third and final step. In the closed-source Content Decryption Module (sandboxed and protected with anti-debugging and anti-tampering techniques), the content is decrypted and ready to be delivered to the end-user.
Although this explanation is very high-level, it sheds some light on the complexity of DRM systems and why they are such a widely employed anti-piracy solution. Every step of the way is secured to the highest degree so that, in the end, breaking the DRM system becomes a near-impossible task.
It may seem that our story is about to draw to a close, but this is not the end of it. If it were, piracy wouldn’t be such a gigantic (and growing) business problem. And so, in our next post, we will answer one question: why isn't DRM enough?
For an in-depth analysis of this topic of security in OTT media delivery, read our free white paper.
Must read next
Keeping OTT Content Secure: SSL, CDNs, and Encryption
OTT services have changed the way we consume content. As the industry tackles the issue of piracy, we explore the parts played by SSL, CDNs, and encryption.
April 16, 2020 | By Jscrambler | 3 min read
Keeping OTT Content Secure: Why Is DRM Not Enough?
In this third chapter of our series on piracy in OTT, we explore one of the biggest pitfalls of DRM and why watermarking is a much needed anti-piracy layer.
May 8, 2020 | By Jscrambler | 3 min read