DRM at Vimeo

Sumanth Srinivasan
Vimeo Engineering Blog
6 min readAug 3, 2021

--

Digital Rights Management, or DRM, enables secure transmission of media such that no entity besides its intended recipient is able to access it meaningfully.

Vimeo is in the business of providing access to video, and as we support bigger studios via our Vimeo OTT service, license holders want to exercise greater and more nuanced control over their content; bigger studios have stricter DRM requirements when they stream online. Discerning the configurable parts of DRM from the black boxes is hence paramount to ensuring seamless playback while also meaningfully protecting licensed video.

In its current form, the technology enabling DRM is a set of iterative updates to communication methods from the cold-war era — a combination of cryptography, information theory, and signal processing. While the implementation details are remarkably different today, the fundamental system involving encryption, decryption, and a key source continues to form its backbone.

The following schematic from a 1949 paper by Claude Shannon is a great starting point for understanding how DRM for video streaming works, and is remarkably similar to Vimeo’s DRM architecture.

Schematic from Communication Theory of Secrecy Systems (1949) by Claude Shannon (Left), Vimeo’s DRM system (Right)

In both cases, there are two pieces of information being transferred: the encrypted media itself, and the key. In modern DRM solutions, this distinction is important because we use different methods to transmit each securely.

Traditional DRM technologies from the VHS and DVD era, constrained by the physical medium, sent both the key and the media out together. As an additional layer of security, the key to access the media was encrypted such that only an authorized hardware player containing the Key Encryption Key, or KEK, could do the unlocking: first for the key itself, and then for the media.

DVDs used Symmetric Key Cryptography to secure both the media and key. The paper “Cryptography: A Comparative Analysis for Modern Techniques” describes Symmetric Key Cryptography as “focused towards ensuring secure communication between sender and receiver by using [the] same secret key.” An alternative to the Symmetric Key approach is Asymmetric Cryptography. This method uses a set of public and private keys, the combination of which is necessary to access information.

In case of DRM on the web, there is no constraint requiring the media and the key to be transmitted together. This has enabled the development of different strategies to securely transmit each, and an evolution of key encryption techniques. Modern DRM solutions across the streaming media industry use symmetric keys for encryption and decryption of media, such as AES-based encryption; and asymmetric cryptography with ECC or RSA key exchange for the key.

Encryption: Fastly DRM

At Vimeo we use the DRM encryption capabilities offered as part of Fastly’s on-the-fly packaging service.

Fastly can encrypt videos packaged into HLS using Envelope/AES-128 or SAMPLE-AES; and MPEG-DASH using MPEG-CENC with ClearKey by generating a unique content encryption key for each video. This encryption system interfaces with all the major DRM providers that Vimeo supports. Fastly also stores references to keys associated with a given video asset.

Older iterations of DRM at Vimeo were set up for encryption at source, which meant that a media asset in storage was only accessible with the initial set of keys it was encrypted with at the time of upload. This results in assets being beholden to one set of keys, increasing potential risk in case of a key leak. Using an on-the-fly mechanism prevents this dependency by enabling ad-hoc generation of new and unique keys when a playback session is initiated.

Decryption: Player, HTML5 EME, and CDM

Decryption of media for playback is handled by Content Decryption Modules, or CDM, in the browser. These modules can be utilized for encrypted media to be played inside HTML elements using a set of web standards called HTML5 Encrypted Media Extensions, or EME. While every CDM is implemented differently, the EME capabilities are designed to act as a liaison with HTML media elements, providing room for some amount of standardization. The Vimeo player uses EME to interact with CDMs while attempting to play encrypted media in the browser.

“Encrypted Media Extensions”, Copyright © 2021 W3C® (MIT, ERCIM, Keio, Beihang). This software or document includes material copied from or derived from Encrypted Media Extensions.

The extent of involvement that CDMs have in video playback isn’t exhaustively defined in the EME specification, and so a CDM may handle the decoding (or decompression) of media as well as decryption. Depending on the browser and operating system, it may even take care of rendering individual frames of video.

Key encryption

In order for playback to ensue successfully, the key to unlock media needs to be transmitted securely from the key source to CDM in the browser. We use Intertrust ExpressPlay as the key source for our DRM solution. ExpressPlay has been certified by all major DRM providers, and it’s capable of interfacing with most common CDMs, such as Apple FairPlay, Google Widevine, and Microsoft PlayReady.

While ExpressPlay is the keeper of keys, secure transmission of a key to the client is taken care of by the DRM provider, which encrypts each key such that a CDM in the browser can access it. DRM providers and browser CDMs hence go hand in hand (and often by the same names), as they require shared context around key encryption. The robustness of DRM systems largely depends on the security of this shared context.

To avoid potential vulnerabilities in this area, actual implementation of a CDM is often deliberately obfuscated and presented as a black box. For additional protection against exploits, DRM providers also frequently publish updates to CDMs.

HDCP and SD fallback mechanism in the player

High-bandwidth Digital Content Protection, or HDCP, is a form of digital copy protection to stop encrypted content from being played on unauthorized devices or devices that have been modified to copy media.

HDCP support is not universal, and its addition prevents playback on Chromebooks, older Amazon Fire TVs, and computers with external monitors. DRM is hence best implemented as a ladder that gets increasingly more stringent as the quality of the video increases.

In order to facilitate this ladder model, any Vimeo video with HDCP and SD fallback enabled has multiple DRM keys, each unlocking certain renditions of the video while restricting others. Generation and usage of multiple keys is facilitated by ExpressPlay and Fastly’s on-the-fly service. The player contains a DRM keychain that stores URLs for multiple keys associated with a session and switches appropriately when necessary.

In case of an attempt to play an HDCP-protected video on a device without support, the browser fires an event to alert the player, causing it to switch to a key that permits unrestricted access to SD renditions. The CDM in the browser, with the aid of HTML5 EME, then makes authentication and key requests to set up for decryption. Each key can be set to unlock multiple renditions of a video. With the right configuration, the player hence is still capable of using its adaptive bitrate-switching algorithms, continuing to provide a good quality of experience.

Summing up

Providing world-class video streaming as a service today means that DRM becomes an imperative offering. Based on our video playback metrics, DRM-enabled videos account for 13 percent of all Vimeo OTT playback sessions in 2021 so far.

Despite offering advantages in protecting licensed content, DRM can amplify device differences — a viewer can be locked out of protected content for simply using an older computer or smartphone, for example — and affect playback quality of experience by adding an additional layer of complexity to video streaming. For that reason, DRM at Vimeo is still a strictly opt-in feature.

Interested in flexing your engineering chops at Vimeo? Join our team!

--

--