Keeping OTT Content Secure: Tokens and DRM

This post is the second part of our "Keeping OTT Content Secure" series. Feel free to read part one here.

Now that we have discussed why SSL isn't helpful when it comes to protecting content in Web OTT media delivery, the question remains: how can OTT providers ensure that only legitimate, rightful users can access their content?

Generally speaking, tokens provide a way to protect content from being shared or embedded in 3rd party players.

There are different approaches to achieve 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 lacks the corresponding valid token.

Another approach is attaching a token ID (usually a hash) to the URL of the content. This allows the server to quickly detect if a request is coming from a legitimate client or not.

While these approaches generally work well for web services in general, they are not really a good fit when it comes to the high stakes that exist in OTT media delivery. As so, 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 several different approaches when it comes to applying it. Some of the major 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, as seen in the image below.

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 in the licensing server.

In the second step, the user requests access to the content by making a request to the server. If the user has permission to do so, it receives the encrypted content stored in the Server/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.

And here we have the third and final step — in the closed-source Content Decryption Module (which is 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 very simple question: why is DRM not enough?

Stay tuned!

For an in-depth analysis of this topic of security in OTT media delivery, read our free white paper.