May 12, 2020

Keeping OTT Content Secure: Resilient Forensic Watermarking

By Jscrambler | 3 min read

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 here.

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 this.

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.

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

At the client-side, the logic is either implemented at the firmware or at the SDK level and it inserts OTT client-related information. This information should always be generated in the form of a randomized ID at 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 so security measures — including at the hardware level — have to be added. 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 again are led to the threat of tampering with the source code of the client-side watermarking agent.

White Paper OTT Security

Securing Client-Side Watermarking

As mentioned above, placing the watermarking client on 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 both 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 off with JavaScript obfuscation, which transforms the code into something that is 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 is 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.

Author
JscramblerThe leader in client-side Web security. With Jscrambler, JavaScript applications become self-defensive and capable of detecting and blocking client-side attacks like Magecart.
View All Posts

Subscribe to our weekly newsletter

Learn more about new security threats and technologies.

I agree to receive these emails and accept the Privacy Policy.