{"id":22450,"date":"2026-09-04T11:59:48","date_gmt":"2026-09-04T11:59:48","guid":{"rendered":"https:\/\/www.vdocipher.com\/blog\/?p=22450"},"modified":"2026-09-04T12:13:06","modified_gmt":"2026-09-04T12:13:06","slug":"drm-encryption-explained-every-layer-where-encryption-and-decryption-actually-happens","status":"publish","type":"post","link":"https:\/\/www.vdocipher.com\/blog\/drm-encryption\/","title":{"rendered":"DRM Encryption Explained: Every Layer Where Encryption and Decryption Actually Happens"},"content":{"rendered":"

This article is more about DRM encryption specifically and not around the whole DRM system and its working. We will be looking mainly at the layers where encryption and decryption is happening.<\/p>\n

Most DRM content stops at, \u201cmedia is encrypted with AES\u201d, and almost nobody maps the distinct cryptographic layers (content encryption, CDM to license-server session crypto, and key-wrapping and delivery). Let us dig into the specs so the article holds up technically.<\/p>\n

What is DRM Encryption?<\/b><\/h2>\n

DRM encryption is not a single encryption performed on a media file where you will get an encryption key and content identifiers. It is not as simple as that.<\/p>\n

A DRM-protected streaming pipeline is not even just AES-128. It is a stack of at least four cryptographic layers:<\/p>\n

    \n
  1. Symmetric content encryption at packaging time (AES-128 in CTR or CBC mode via ISO\/IEC 23001-7 Common Encryption).<\/li>\n
  2. An asymmetric license-request handshake built on each CDM’s factory-provisioned device key (RSA-2048 for Widevine, ECC P-256 for PlayReady, an Apple-issued RSA app certificate plus derived AES keys for FairPlay).<\/li>\n
  3. Server-side key wrapping, where the content key is re-encrypted uniquely for the requesting device.<\/li>\n
  4. On-device key-ladder decryption inside a TEE or Secure Enclave, plus HDCP link encryption on the output.<\/li>\n<\/ol>\n

    A simple way to picture it: the video file is a locked shipping container. The container lock is the same for everyone and it is a fast, cheap lock, because it has to be opened millions of times per second while video plays. The interesting security is not the container lock at all. It is that the key is never shipped with the container, that a device must prove its factory identity before receiving the key, that the key is then placed in a second box only that one device can open, that the key is kept inside a sealed part of the chip the operating system cannot read, and that the decoded video gets re-encrypted one more time on the cable to your screen.<\/p>\n

    Now further on we will discuss these 4 layers.<\/p>\n

    Layer 1: Content Encryption at Packaging Time<\/b><\/h2>\n

    \"\"<\/p>\n

    After transcoding and segmentation into fMP4 or CMAF (or MPEG-TS for legacy HLS), the packager encrypts the media samples, not the container boxes, with a symmetric content key (CEK), a 16-byte AES key. CENC is deliberately not a key-management or license protocol. It standardizes only the encryption format and metadata so any compliant DRM can locate the right key.<\/p>\n

    That distinction matters more than it sounds. The container structure stays readable, so a player can parse timing, codec configuration and segment boundaries without any key at all. Only the picture and sound data is scrambled. This is why a DRM-protected stream still seeks, still adapts bitrate and still reports duration correctly before a license is ever fetched.<\/p>\n

    Two schemes matter in production, both AES-128: cenc, which is AES-128-CTR over the full protected range, and cbcs, which is AES-128-CBC with pattern encryption. The manifest and the segments end up carrying the key ID, the IVs, the scheme and the per-DRM PSSH boxes. They never carry the content key itself.<\/p>\n

    Layer 2: Client-Side CDM Cryptography<\/b><\/h2>\n

    \"\"<\/p>\n

    Layer 1 protected the content. Layer 2 is about the device proving who it is, in a way that cannot be forged or replayed, before anyone hands it a key.<\/p>\n

    The Content Decryption Module holds a private key provisioned at manufacture, generates the license request, signs it with that key, and encrypts a fresh per-session secret into it. Widevine does this with RSA-2048, PlayReady with ECC P-256, FairPlay with an Apple-issued RSA application certificate plus an AES key derived from a shared application secret.<\/p>\n

    The output of this layer is a single opaque binary blob: a Widevine license request, a FairPlay SPC, or a PlayReady license challenge. Your application code never generates it, never signs anything, and never inspects it. It only forwards bytes.<\/p>\n

    Layer 3: License Server and KSM Cryptography<\/b><\/h2>\n

    \"\"<\/p>\n

    The server does two logically separate jobs, and keeping them separate makes the whole architecture easier to reason about.<\/p>\n

    The first is entitlement: is this user, on this session, allowed to watch this content right now? That is business logic, normally answered by validating a signed token, and it involves no content keys at all.<\/p>\n

    The second is the crypto step: open the request the client sent using a server-held private key, extract the client’s session secret, fetch the content key from the key management system, and re-encrypt that content key so that only the one device that made the request can open it. The result is a Widevine license, a FairPlay CKC, or a PlayReady XMR license. The content key never leaves the server unwrapped.<\/p>\n

    Layer 4: Device Decryption and Output Protection<\/b><\/h2>\n

    \"\"<\/p>\n

    The CDM opens the license using its own private key, recovers the content key, and loads it into a key store. On hardware-backed devices, meaning Widevine L1, PlayReady SL3000 and Apple’s Secure Enclave, that key store is inside the TEE and the CDM only ever holds an opaque handle, never the key bytes. On software levels, Widevine L3 and PlayReady SL2000, the key is protected only by white-box cryptography in ordinary memory.<\/p>\n

    Encrypted samples are then handed to a secure decryptor, and on hardware levels the decrypted frames land in protected memory that the OS, applications and screen recorders cannot read. Finally, HDCP re-encrypts the decoded video on the physical link to the display, using its own handshake, its own session key and its own cipher.<\/p>\n

    The Complete Cryptographic Sequence, Start to Finish<\/b><\/h2>\n\n\n\n\n\n\n\n\n\n\n\n
    Step<\/b><\/td>\nHop<\/b><\/td>\nOperation<\/b><\/td>\nAlgorithm<\/b><\/td>\n<\/tr>\n
    1<\/td>\nPackager<\/td>\nEncrypt samples with the CEK<\/td>\nAES-128-CTR (cenc) or AES-128-CBC with 1:9 pattern (cbcs)<\/td>\n<\/tr>\n
    2<\/td>\nPackager to key server<\/td>\nExchange CEK, KID and PSSH<\/td>\nCPIX, keys wrapped to a document or public key, document signed<\/td>\n<\/tr>\n
    3<\/td>\nManifest<\/td>\nSignal KID, scheme and PSSH<\/td>\nCleartext metadata, no CEK<\/td>\n<\/tr>\n
    4<\/td>\nClient<\/td>\nDetect encryption, encrypt the request<\/td>\nEME generateRequest, CDM builds the request.<\/td>\n<\/tr>\n
    5<\/td>\nTransport<\/td>\nDeliver challenge and response<\/td>\nTLS plus JWT authorization<\/td>\n<\/tr>\n
    6<\/td>\nLicense server<\/td>\nAuthorize the session<\/td>\nToken validation, no content keys involved<\/td>\n<\/tr>\n
    7<\/td>\nTEE or key store<\/td>\nLoad the CEK into the key ladder<\/td>\nHardware-backed key handle on L1<\/td>\n<\/tr>\n
    8<\/td>\nDisplay output<\/td>\nLink encryption<\/td>\nHDCP, AES-128-CTR<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    The rest of this article takes each mechanism in that sequence and explains what is actually happening cryptographically.<\/p>\n

    CENC vs CBCS Cryptographic Difference<\/b><\/h2>\n

    In CENC, AES-CTR turns the block cipher into a stream cipher: the CEK encrypts a counter block (IV concatenated with a counter), and the resulting keystream is XORed with the plaintext. The 16-byte counter is the per-sample IV. It increments once per 16-byte block and carries across subsamples within a sample. CTR mode allows random access and parallel decryption because any block can be computed independently, historically the reason non-Apple pipelines preferred it.<\/p>\n

    In CBCS, AES-CBC chains blocks (each ciphertext block feeds the next block’s XOR). The IV is applied to the first encrypted block of each subsample.<\/p>\n

    Put less formally: CTR mode generates a very long random-looking ribbon of numbers and lays it over the video data. Because any part of that ribbon can be computed directly from a counter value, you can jump to the middle of a segment and start decrypting immediately, and you can decrypt many blocks in parallel on different cores. CBC mode instead links each block to the one before it, like a chain, so it is inherently more sequential. Neither is weaker. They have different performance characteristics, which is why Apple and everyone else initially went different ways.<\/p>\n

    Where the DRM Encryption Metadata Lives: The ISOBMFF Boxes<\/b><\/h2>\n

    For video-on-demand with a single key, the encryption metadata sits in the init segment (moov) and in each fragment (moof):<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
    Box<\/b><\/td>\nLocation<\/b><\/td>\nWhat it holds<\/b><\/td>\n<\/tr>\n
    pssh<\/td>\nmoov<\/td>\nProtection System Specific Header, opaque per-DRM data, one box per system ID<\/td>\n<\/tr>\n
    sinf<\/td>\nmoov\/trak\/…\/stsd<\/td>\nProtection Scheme Information Box, wraps the original sample entry format<\/td>\n<\/tr>\n
    frma<\/td>\nsinf<\/td>\nOriginal format box, records that an encv or enca entry is really avc1 or mp4a<\/td>\n<\/tr>\n
    schm<\/td>\nsinf<\/td>\nScheme type (cenc, cbcs and so on)<\/td>\n<\/tr>\n
    tenc<\/td>\nsinf\/schi<\/td>\nTrack Encryption Box: default_isProtected, default_Per_Sample_IV_Size (0, 8 or 16), the 16-byte default_KID, plus default_crypt_byte_block and default_skip_byte_block for pattern schemes and default_constant_IV for cbcs<\/td>\n<\/tr>\n
    senc<\/td>\nmoof\/traf<\/td>\nSample Encryption Box: per-sample IVs and the subsample clear and protected ranges<\/td>\n<\/tr>\n
    saiz and saio<\/td>\nmoof\/traf<\/td>\nSample Auxiliary Information Sizes and Offsets, which locate the senc auxiliary data<\/td>\n<\/tr>\n
    sbgp and sgpd<\/td>\nmoof\/traf<\/td>\nSample-to-Group and Sample Group Description, used with a seig entry to override the default KID per group during key rotation<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Encrypted sample entries are renamed from avc1 to encv for video and from mp4a to enca for audio, with the original format preserved in frma. For key rotation, a fresh moof\/pssh can carry new keys per crypto period alongside the sbgp and sgpd mapping.<\/p>\n

    How HLS Signals DRM Encryption<\/b><\/h2>\n

    HLS<\/a> uses the #EXT-X-KEY tag in media playlists, and #EXT-X-SESSION-KEY in the master playlist, with a METHOD attribute:<\/p>\n