Keeping OTT Content Secure: Resilient Forensic Watermarking

This post is the fourth and last part of our "Keeping OTT Content Secure" series. Feel free to read part three: Keeping OTT Content Secure: Why Is DRM Not Enough?

Previously, we explored why forensic watermarking directly answers piracy concerns and why it is commonly implemented alongside DRM.

In a nutshell, forensic watermarking enables providers to quickly track down the origin of leaked content and stop that source of piracy.

We ended our previous part by mentioning that we had Jscrambler engineers working closely with the teams of watermarking providers to uncover a key threat: the risk of tampering with forensic watermarking solutions.

And to understand this threat, we must explore the different possible implementations of forensic watermarking.

Forensic Watermarking Implementations

We can divide watermarking into bitstream and A/B watermarking. In bitstream watermarking, specific changes that are imperceptible to the human eye (forensic watermarking) can be applied and will uniquely identify the client that leaked the content. This may sound familiar because our previous explanation of watermarking was based on it.

Then, there’s A/B watermarking, where the server pre-processes the content to build two watermarked versions, which are combined through the use of a manifest specific to that client and session when streaming the content. This approach by itself has some pitfalls that you can explore in more detail in our white paper about securing content and intellectual property in OTT Media Delivery.

Both of these watermarking techniques can be embedded on the server-side, on an edge server, on the client-side, or a combination of these.

Client-side

On the client-side, the logic is either implemented at the firmware level or the SDK level, and it inserts OTT client-related information.

This information should always be generated in the form of a randomized ID on the server-side to harden the task of an attacker reverse-engineering the information that is inserted into the content.

The client-side approach requires integration at the client device level and security measures, including at the hardware level. In the “hybrid” approach, the server will still preprocess the content to build different versions, and the watermark is either inserted or managed at the edge servers or on the client-side.

With OTT providers wanting to maximize the end-user's experience (better player performance) and reduce costs, client-side, or hybrid,” approaches have grown in adoption. And as we look closer at this implementation, we are again led to the threat of tampering with the source code of the client-side watermarking agent.

Securing Client-Side Watermarking

As mentioned above, placing the watermarking client in an adversarial environment (the client-side) means that its logic is exposed.

Using readily available tools such as a browser debugger, an end-user may find ways to tamper with and ultimately bypass watermarking. This can be achieved by reverse-engineering the agent’s exposed JavaScript code or by tampering with the DOM, introducing, changing, or removing visual elements in the application.

Providers can address the first problem, JavaScript reverse-engineering, by protecting the watermarking agent’s JavaScript code. While JavaScript encryption is not feasible, an industry-recommended approach is JavaScript protection.

This layered security approach starts with JavaScript obfuscation, which transforms the code into something extremely hard to understand and reverse-engineer, while still running on the Web browser just like the original code, as shown below.

On top of obfuscation, a robust JavaScript protection approach adds anti-tampering and anti-debugging capabilities. These break the web player whenever an ill-intentioned user tries to debug or modify the watermarking agent’s logic. As a result, these capabilities help prevent any type of dynamic or static code analysis.

To address the second problem, DOM tampering, providers must monitor the DOM in real-time to detect/block any attempt by an end-user to hide, remove, or modify the watermark.

This includes changes to overlays, which are achieved by tampering with the DOM by changing either its HTML elements or CSS properties. Such a webpage monitoring solution must detect these changes regardless of their delivery mechanism.

Major forensic watermarking providers employ cutting-edge JavaScript Protection and Webpage Monitoring provided by Jscrambler to ensure that their solutions can run on the client-side with minimal exposure to attacks.

If you’d like to know more about these security solutions, get in touch with us.