The Limitations of CDN One-Time Token Validation

It’s hardly news that streaming video service providers suffer from piracy. More recently, however, it has become commonly known that pirates exploit vulnerabilities in the OTT protocol in order to abuse video services and gain unauthorised access to video content directly from the service provider’s CDN.

One of the key vulnerabilities they go after is manipulating tokens, which are a fundamental building block on which OTT exchanges are typically based.

What are tokens and what do they do?

Tokens serve as ‘tickets’ that grant access to content, provide authorisation, and help maintain sessions. Though they are difficult to forge, they are simple to obtain, duplicate and reuse, making it easier for unauthorised devices to gain access to content and services. Pirate scripts, which are computer programs built to gain unauthorized access to content directly from the service provider’s CDN, automate such token exploits.

Certain CDN vendors suggest enforcing a one-time—or limited time—use of each token to mitigate the problem. While this sounds like a solution, it’s only looking at a small, insignificant part of the problem. And to top it off, it is rather costly.

Looking beyond its incomplete approach and high costs, it also requires the service provider to do more work. In order to track token reusage, service providers must have access to a database of tokens so that each time a device requests access, the CDN can check whether the token has been used.

While this approach may have some benefits, it suffers from several shortcomings:

Security

CDN transactions are based on both short- and long-term tokens. Short-term tokens are typically granted by the service provider and authorize initial access to the CDN asset. Long-term tokens, on the other hand, are granted by the CDN and help maintain a session.

Throughout the session the device will only need to present the long-term token to obtain additional segments of the same asset. The solution referenced above only focuses on short-term tokens but is unable to address the long-term ones. A long-term token is typically valid for several hours, and by nature cannot be a one-time token. In fact, it is often enough to show a valid long-term token to gain access – and not even have to obtain a short term one – thereby allowing hackers to reuse them and bypass the entire solution.

There are additional common scenarios in which the suggested solution will be ineffective. Some pirate scripts target other tokens used by the service provider in the process, rather than the duplication of a CDN token. These scripts provide a unique CDN token to each client they serve, making enforcement of one-time use tokens unhelpful.

Costs

Each time a device requests access, it queries the service provider’s database to check whether the one-time token has been used. This doubles the amount of service provider requests because every request – after being processed by the authorisation system – reaches the CDN and then doubles back to the service provider-maintained database, generating extra cost. In the event that this database is implemented by the CDN vendor, then the resulting extra cost needs to be paid to the CDN vendor for their service.

Redundancy and Performance

On top of the high costs, the database also acts as a single point of failure and needs to be built for high availability. Additionally, having to check every request on the database adds potential latency to each transaction, and ultimately impacts the user experience.

Do One-Time Policies Solve the Problem?

In one word, no.

The core problem is that tokens are difficult to bind to a single device, and the enforcement of one-time use on the CDN doesn’t address this core issue.

Other attempts to solve the problem include trying to assign an ID to the client and using the IP address or MAC address. However, these mechanisms also provide very partial coverage, and are easy for hackers to bypass. Solutions that obfuscate and harden the application are also limited, since they don’t prevent pirate scripts from impersonating legitimate clients.

There is Another Way…

At Synamedia, we take a holistic, expansive approach to piracy intelligence and combine it with deep technological expertise to study the problem of pirate scripts. Synamedia’s OTT ServiceGuard creates a trusted environment that acts as a security anchor, much like in hardware protected devices, making the environment expensive to break. The environment is based on the concept that each client’s code is highly protected against reverse engineering, differs from client to client, and changes over time. This means that even if a hacker is able to break a client’s code, it is not scalable, as each code works differently. Ultimately, attempting to break any additional client code would be just as difficult as breaking the first one, making the whole process extremely cost-ineffective for pirates.

Synamedia’s OTT ServiceGuard thus addresses the issue at its core, by maintaining a unique identity per client that cannot be cloned, and a set of highly protected signing keys, binding each token to a client identity. The binding can be verified by the service, preventing token duplication and abuse.

The solution extends to the CDN as well, where the same validation can take place, preventing token duplication and abuse, not just at the service provider’s backend but also on the CDN. The secure process enabled by OTT ServiceGuard ultimately requires simple signing on the client side and simple validation on the server side, making it very efficient and cost-effective, with no impact on the user experience or on server performance.

Lastly, Synamedia’s OTT ServiceGuard doesn’t just protect its own code, it also protects the service provider’s applications from being hacked. Synamedia’s solution shuts down access to streaming services from the get-go by detecting, and protecting against, application tampering, device rooting and jailbreaking.

Naturally, this grants service providers much needed peace of mind.

Contact us to learn more about OTT ServiceGuard.