How video DRM works?

Industry standard DRMs (like Widevine, Playready, Fairplay) protects content in all possible ways.

1. Transferred over the internet (content is always encrypted, licensing key exchange is through HTTPS key exchange mechanism)
2. Played back on devices (hardware level protection)

In this blog we will see how the content is encrypted and encryption key are transferred and used for decryption without leaking key or content.

DRM data flow

Background process: (At video production end)

1. Content providers (video owners) transcode their video into multiple bitrates for better playback experience (adaptive bit rate playback). Encrypt all bit rate video segments with a ‘Key’ (Encryption is based on the standard for all DRM providers called ‘CENC’ — which is nothing but AES-128 CTR).
2. Upload the encrypted content into CDN.
3. Upload the ‘Key’ (KeyId +actual encryption Key) to the DRM license provider. KeyId is a public information used to retrieve the encryption key during playback.

Runtime process: (During playback in a player)

1. Obtain the video manifest and video segments from the CDN
2. Extract the KeyId from the manifest (or from video segments sometimes)
3. Create the license request specific to the player/device
4. Send the license request to the license server
5. DRM License server send the License (with Key) to player/application
6. Player updates the license to CDM component
7. CDM extract the ‘Key’ from license file received from the server and use it to decrypt the video segments. Then decode the decrypted video segment
8. Plays the decoded video

Ref: https://ottverse.com/eme-cenc-cdm-aes-keys-drm-digital-rights-management/

The runtime activities are typically handled with 2 main components

1. The player takes care of obtaining the movie, parsing the manifest, extracting the KeyId, making the requests to the DRM License Server
2. Another component called the CDM (Content Decryption Module) takes care of creating the license request, decrypting & decoding the content.

CDM or Content Decryption Module

Every DRM provider provides a CDM with their own

1. algorithm for creating license request (using the KeyId, device, signing algorithm, etc.)
2. algorithm to decode the license response received from the DRM License Server and extract the decryption key.
3. rules around storing the license locally on the client, license renewal, expiry, etc.

DRM vendors (like Widevine) test and certify these CDMs implementations (on devices) to ensure all specifications are followed

• For license requests
• They do not leak the decryption keys or decoded videos
• They securely store the decryption keys based on the license specifications (store the key for X days, for example)
• They transfer decoded video to the screen (hardware assisted)

CDM and Security levels

For video playback, CDM (Content Decryption Module) plays an important role in preventing data leaks because it only has the decrypted raw data. CDM typically has below options

1. decrypt video and hand over the bitstream to application/player
2. decrypt, decode, and pass on the decoded frames of video to the platform’s display engine.
3. decrypt, decode, and display the video by itself (most secure)

The implementation of content decryption, decoding in CDM can be done in software or hardware. Hardware based implementation is considered more secure because all the operations take place in the Trusted Execution Environment or TEE. TEE inWikipedia => “a secure area of a main processor that guarantees code and data loaded inside to be protected with respect to confidentiality and integrity”.

Based on devices capabilities (low end, typically) cannot perform hardware decryption and decoding and they are stamped different levels. Different DRM providers stamp different security levels. For e.g., Google’s Widevine defines three security levels — L1 (highest), L2, and L3 (lowest).

Security Level 1 (L1): Cryptography and video decoding operations are performed within the Trusted Execution Environment (TEE)

Security Level 2 (L2): Only cryptography operations are done inside TEE.

Security Level 3 (L3): Device doesn’t have a TEE or all processing is done outside TEE. Typically we have WBC (WhiteBox Cryptography) and software obfuscations is implemented here for protection.

Security levels and Blocking HD content

Typically content providers has the flexibility to allow different bitrates for different security levels. These are handled with rules in license files. Usually for playing HD and above quality videos L1 level of security is needed in client side.