Abstract
Stealing content directly from the Content Delivery Network (CDN) of legitimate content providers has become too easy. It is time for CDNs to join the fight against piracy, rather than turning a blind eye to the issue.
In a classic form of piracy, one of the legitimate clients grabs the regular video stream displayed on her screen, using a screen-casting tool for instance, and redistributes it on a dedicated illegal infrastructure for pirate viewers. While being a known curse, such piracy has not really taken off due to the cost that pirate providers have to bear for the illegal delivery infrastructure and the lower quality of the pirate stream. Yet, in a new form of piracy, referred to as CDN leeching, pirates simply share some tokens that grant access to the content from the delivery infrastructure of the legal service provider. It doubles the pain for Over-The-Top (OTT) service providers: not only some illegal users access their content without authorization, but also the content provider pays for the delivery to these pirates. Furthermore, the 'pirate stream' quality is on par with the legal service, which increases churn from the legal services. Despite the implementation of authentication tokens and Digital Rights Management (DRM), OTT video streaming services have hardly hampered the ramp up of CDN leeching.
Streaming security experts have largely overlooked the role of the CDNs for a long time. To fight piracy, service providers have first focused on trusted hardware authentication from controlled set-top-boxes, and then implemented DRM for their OTT services. The CDN tokens have been designed to offer a light-weight optional security layer without compromising the streaming scalability, which is the baseline purpose of CDN servers. The adoption of software-based authentication to support mobile devices and the vulnerabilities of DRMs, epitomized by Widevine L3 [2], have put CDNs in a more central position and calls for revisiting the design of CDN tokens.
A CDN token is a small digital object, which encodes the requirements to be granted access to a resource [1, 4]. It is piggybacked in every request from the client to the CDN server. This involves three entities: the content provider, the client, and the CDN server. The client triggers the generation of a new token by sending some data related to its next request(s) to the content provider. The content provider validates the request(s) and issues an encrypted and integrity-protected token, usually relying on some cryptographic primitives. The client then sends the token along with its request(s) to the CDN server, which (i) decrypts the token, (ii) validates the integrity of the token, (iii) checks whether the requirements of the token are met, and (iv) validates the access if everything checks out. Crypto-secrets needed to perform these tasks are typically acquired from the content provider and managed at configuration level.
One-time tokens, constructed for one specific request and one specific client, guarantee that a token cannot be replayed. However, it requires scaling the security part of the delivery infrastructure accordingly. A single client generates many requests during a video streaming session: every five seconds, the client requests a manifest, a video segment, and an audio segment, not mentioning other related data. Issuing and validating tokens for each individual object and user may be challenging for most existing content provider's token servers or CDN servers.
In practice, the streaming community has not agreed on a best practice yet. The CTA Wave working group, which standardizes a common CDN token format [3], has postponed the release of its first reference document. Meanwhile, the industry, in desperate need for a token, has designed multiple proprietary formats, which prevents re-use and multi-vendor delivery services. We also miss a reference study on the best implementation of time expiration in tokens. The community distinguishes short-lived tokens (which either have a short expiration time or refer to a small number of consecutive assets) and long-lived tokens (which either have a long expiration tine or refer to a long series of consecutive assets).
In this paper, we will bridge those two gaps. First, we will identify the parts of CAT that will undoubtedly be implemented in the final specification and thus can already be implemented and adopted by the industry. We strongly believe that we cannot wait any further the definition of a token, so we call for an informal adoption of a subset of claims. Second, we will compare the impact of long and short-lived tokens to help infrastructure administrators identifying the sweet operating spot for their service. Eventually, we will explore the concept of mixed-lived token, which could make pirate operations more difficult, and the changes it would require from content providers, video players, and CDN servers.
