Next-Generation Token to Fight Piracy and CDN Leeching
Originally Aired - Saturday, April 13 | 3:40 PM - 4:00 PM PT
Pass Required: Core Education Collection Pass
Don't have this pass? Register Now!
Create or Log in to myNAB Show to see Videos and Resources.
Videos
Resources
{{video.title}}
Resources
This Session Has Not Started Yet
Be sure to come back after the session starts to have access to session resources.
A new form of piracy, referred to as CDN leeching, has become dominant in the OTT video industry. Pirates share some tokens that grant access to the content from the delivery infrastructure of the legal service provider. With these tokens, the pirates can directly fetch the data from CDN. It doubles the pain for 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. 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, 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. 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 decrypts the token, validates the integrity of the token, checks whether the requirements of the token are met, and 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 are constructed for one specific request and one specific client. They guarantee that a token cannot be replayed. However, they require 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 is challenging for most existing content provider’s token servers or CDN servers. The community had adopted loose forms of timed-based tokens, between short-lived tokens (which have a short expiration time) and long-lived tokens (which have a long expiration time). The longer is the token expiration delay, the lesser are computing resources, but the higher is the piracy risk. 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 named Common Access Token (CAT), has postponed the release of its first reference document. In this paper, we present a comprehensive tour of the token-based security policy. We call for a new approach, which is no longer based on timed token but from other randomized mechanisms, which are better suited to fight piracy at scale.
Presented as part of:
Speakers
