A New Security Layer

Earlier this month AWS posted an interesting blog titled “Secure content using CloudFront Functions“. It discussed how OTT service providers, who are AWS customers, can leverage such functionality to increase the level of security in their streaming services. The blog went on to explain how AWS offers Signed Cookies and Signed URLs as the basis for content protection mechanisms, and compliments it with CloudFront Functions for more flexible functionality. Signed Cookies and Signed URLs deal with access to unauthorized content by users, a scenario that web application designers often face. In other words, you want to make sure that a user can only access what that user is entitled to.

When it comes to OTT services, however, there are other use cases that are no less impactful, as OTT has several vulnerabilities. One such vulnerability, and a fundamental one at that, lies in the use of tokens that are inherent to the OAuth framework, on which OTT exchanges are based. Tokens are susceptible to abuse, as they are easily duplicated and reused. And so the challenge is to verify that a token is only used by the user and client to whom it was granted.

The common method being offered in such cases is to include the IP address of the client requesting authorization in the token or cookie. It can then be validated against the IP address of the client attempting to access content using the token or cookie, to  ensure it is the same one.

This method, however, is far from robust, nor is it fully secure.

IP addresses don’t necessarily remain static, whether because the user is on the move, or just switching between Wi-Fi and cellular. In such cases, the streaming video would be disrupted, offering a sub-optimal user experience. Additionally, multiple devices could be located behind Network Address Translation (NAT) sharing the same IP address, or they could be proxied through another server, so that all would appear to be coming from the same IP address. The CDN vendors who offer this method acknowledge that it is not recommended, and that their customers who attempted it refrain from using it.

Another attempt to avoid token abuse is to try to assign an ID to the client. It is, however, very difficult to prevent such an ID from being duplicated, similar to the way that tokens are duplicated.

A different threat lies in access by what appears to be legitimate users, that are, in fact, abusive client impersonators. This is one of the common methods used by illegal actors, that has recently been widely observed across streaming service providers as the source of stolen content.

Thus, if you want to keep pirates out of your service, a solution that addresses the currently existing vulnerabilities should, at least, have the following properties:

• Identify a client uniquely in a non-cloneable fashion. It’s not enough to just make up a unique ID. The identity must not be cloneable, or else many clients may falsely present themselves as the same one.
• Obtain signing keys. The client must be able to prove its identity using cryptographic signing keys. It should not be allowed to make up whatever keys it desires, or else it could be exploited by pirates.
• Have a highly protected client environment. Protecting the client’s identity and its cryptographic keys requires very sophisticated client technology that is resistant to tampering. This way, the service is denied if is modified in any way. It also stays resistant to reverse engineering to such an extent that it becomes uneconomical for anyone to spend the time figuring out just how it works. The latter can be achieved if you can not only strongly obfuscate the code, but also make the behavior of each client different from any other client and changing over time. The idea being that even if pirates spend the time understanding how a client works, it couldn’t be cloned, or used for more than a fixed period, and they’d have to start all over again.
• Bind tokens to clients. A token must be associated with a client in such a way that when a token is presented by a client, the service is able to verify that the token does indeed belong to that client by having the client prove its own identity. This prevents tokens from being cloned or used by other clients.
• CDN validation. The CDN also needs to be able to make similar validations, so that multiple clients cannot access the CDN using the same CDN token.
• Tamper resistance. The solution must be able to identify and prevent clients that have been tampered with from getting service, or your service could be breached.
• Open platform coverage. The solution needs to broadly cover the open platforms your customers use to access your service.
• No impact on user experience. All the above must be achieved without having any noticeable impact on the user experience.
• Easy to integrate. Naturally, you also want a solution that wouldn’t burden your own engineers or your infrastructure in any significant way.

Deploying a solution with the above properties would ensure that you can keep pirates out of your service, as well as avoid paying the CDN and associated infrastructure costs generated by free-riding pirate subscribers.

We, at Synamedia, have built such a solution. As you can imagine, it was far from trivial to achieve all of the aforementioned properties. But now that we have, Service Providers can benefit from our extensive experience in the field, our deep understanding of piracy techniques, and our highly advanced technology.