Transloadit

What is DRM Encryption?

DRM encryption converts encoded media into ciphertext that a player can only decrypt with the matching content key. A license system releases that key and its usage rules to clients it authorizes.

How DRM Encryption works

Encryption is applied by the packager, after encoding. With Common Encryption (ISO/IEC 23001-7), which fragmented MP4 streams for DASH and HLS use, encrypted samples use a 128-bit AES key under one of the standard’s four schemes; the two that the W3C stream format for Encrypted Media Extensions permits are cenc (counter mode) and cbcs (cipher block chaining, with a pattern that encrypts only part of each video sample). A protected stream may also contain unencrypted samples, for example a clear lead at the start. The media does not expose the content key in the clear. It carries a key ID, by default in the track encryption box (tenc). What a DRM system’s client needs in order to request a license is its initialization data, and where that lives depends on the delivery format. For DASH, DASH-IF describes a protection system specific header (pssh) for each system, carried in the media, in the manifest as a cenc:pssh element, or in both; the manifest also states the key ID as cenc:default_KID. An HLS playlist signals keys in EXT-X-KEY tags, whose URI attribute specifies how to obtain the key; FairPlay content must use the key format com.apple.streamingkeydelivery in that tag. The player hands the initialization data to the device’s content decryption module, relays the module’s license request to the license service, and returns the license; decryption then happens inside the module. The samples are encrypted once and only the license is issued per client, so every viewer downloads the same encrypted segments and they can be shared and cached like unencrypted ones.

Key facts

  1. cenc or cbcs? The two schemes are not interchangeable, and a device must support the one the content was packaged with. FairPlay content must use the HLS SAMPLE-AES method, which RFC 8216 defines for fragmented MP4 as the cbcs scheme, and Apple’s authoring specification states that SAMPLE-AES-CTR shall not be used on Apple devices. RFC 8216 defines no counter-mode method, yet Android’s Media3 documentation lists HLS in fragmented MP4 as a supported format for Widevine cenc and, on Android TV, PlayReady cenc. The same documentation lists Widevine cenc from Android 4.4 but cbcs only from Android 7.1 (Widevine’s own platform table says Android 7.x and later), and PlayReady added cbcs in client version 4.0, where it remains optional. A single cbcs copy can therefore serve FairPlay, Widevine, and PlayReady clients that support the scheme, which a PlayReady 4.0 version number alone does not guarantee, and older Android or PlayReady clients need a second copy in cenc. If you package both, Microsoft states that a service must not encrypt the same content in both modes with the same key ID and key.
  2. Is the key ID secret, and what must it match? No, it is a label. The key ID travels unencrypted in the tenc box, in pssh data, and in DASH manifests, and tells the client and the license service which key is needed; only the key itself is secret and it is delivered inside a license. The identifiers have to agree at every level: DASH-IF requires the manifest’s cenc:default_KID to match the value in the tenc box, which it treats as the source of truth, and a license that supplies a key under a different ID leaves the samples undecryptable even though the stream loads.
  3. Does one encrypted copy work with several DRM systems? Yes, for systems that support the scheme used: Common Encryption exists so that multiple key systems can decrypt the same media. Each system still needs its own signaling and a license service able to return the same key. Packagers generate that signaling per system; Shaka Packager, for example, can emit Widevine, PlayReady, and FairPlay signaling for one set of keys. Where the signaling lives matters for browsers: DASH-IF advises against pssh boxes in initialization segments, because each one a browser processes can start another license request unless the player detects and blocks the duplicates, and notes that carrying pssh data in the manifest lets a DRM system be added without modifying the content.
  4. When is key rotation worth its complexity? DASH-IF describes its main purpose as forcing periodic re-authorization for continuous live content, for example at program boundaries, and says explicitly that the aim is not to make the encryption stronger. In Common Encryption the changing key IDs are signaled per sample through seig sample groups, optionally with license data in pssh boxes inside movie fragments; in HLS, each EXT-X-KEY tag applies to the segments that follow it until the next tag with the same KEYFORMAT or the end of the playlist. Rotation needs player support (Android’s Media3 requires its multi-session mode for streams with rotating keys), key changes aligned to segment boundaries, and license requests spread over time so that all clients do not ask at the same instant. DASH-IF describes one way to spread them that makes the DRM system responsible: current and upcoming keys are announced in pssh data, and each client picks a random time to request its license.

When DRM Encryption matters

Configure encryption while packaging streams intended for controlled playback and protect the keys separately. A mismatched key identifier, scheme, or license configuration makes correctly encoded media unplayable.

Sources

Turn media knowledge into a working pipeline

Connect uploads, processing, AI, storage, and delivery through one declarative API — with the encoding stack, scaling, and format churn handled for you.

Try Transloadit for free