Keeping OTT Content Secure: Resilient Forensic Watermarking
May 12th, 2020 | By Jscrambler | 3 min read
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.
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.
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.
If you’d like to know more about these security solutions, get in touch with us.
Must read next
Security in OTT Media Delivery [White Paper]
With OTT media providers set for a decade of growth, they must tackle new security threats to secure their premium content and intellectual property.
February 20, 2020 | By Jscrambler | 4 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