Common Encryption (CENC) подробно

TL;DR

Common Encryption – сокращённо CENC, стандартизованный как ISO/IEC 23001-7 (действующее 3-е издание, 2023 г.) – это формат, который позволяет одному и тому же зашифрованному видеофайлу быть расшифрованным любой из трёх крупных систем Digital Rights Management: Widevine от Google, FairPlay Streaming от Apple и PlayReady от Microsoft. CENC определяет четыре схемы защиты – cenc, cbc1, cens и cbcs – из которых на практике используются только две: cenc (AES-128 в режиме счётчика, полное покрытие подсэмпла) и cbcs (AES-128 в режиме CBC, паттерн 1-из-10 по NAL-подсэмплам). В 2026 году продакшен-дефолт – это CMAF, упакованный один раз, зашифрованный по схеме cbcs и описанный одновременно в HLS и DASH, чтобы один и тот же набор файлов обслуживал все устройства; FairPlay принимает только cbcs, а Widevine и PlayReady добавили полную поддержку cbcs, что свело multi-DRM к единственной схеме шифрования. Стандарт также определяет бокс pssh (Protection System Specific Header), который называет каждую DRM в файле, и бокс tenc (Track Encryption), несущий идентификатор ключа по умолчанию – вместе это та метаданные, которые делают один файл, три DRM и единый сценарий воспроизведения.

Почему это важно

Если вы доставляете платное видео в открытом интернете – вы шифруете его по CENC. Никаким другим способом нельзя поставить Widevine, FairPlay и PlayReady поверх одного и того же закодированного материала, а отгружать все три DRM – это цена доступа к каждому домашнему устройству (см. нашу статью DRM 101). Продакт-менеджеру, планирующему OTT-запуск, эта статья отвечает на вопрос «почему мы шифруем один раз, но платим за три DRM?». Инженеру – это полевой гайд по pssh, tenc, default_KID и по разнице между cenc и cbcs, превращающей работающий CMAF-пайплайн в сломанный FairPlay-пайплайн. Основателю, выбирающему между двойным и одинарным шифрованием каталога, – это стоимостная лестница, которую DASH-IF Implementation Guidelines for Security окончательно склонили в сторону cbcs после сентября 2020 года.

Что такое Common Encryption на самом деле

Перед тем как ронять акронимы, зафиксируем задачу. Упаковщик (packager), который готовит видео к стримингу, должен сделать файл невоспроизводимым для тех, у кого нет права. Он шифрует аудио- и видео-сэмплы – собственно пиксели и звуковую волну – внутри контейнера, используя симметричный ключ, называемый контентным ключом, который могут получить только авторизованные плееры. Common Encryption – это не само шифрование; это согласованный формат записи этого шифрования в файл, чтобы любой совместимый DRM мог распознать файл и запросить нужный ключ.

То есть CENC отвечает на четыре вопроса, которые должен решать любой multi-DRM стрим:

1. Какие байты внутри каждого видео-сэмпла зашифрованы, а какие остаются открытыми? – чтобы media-платформа плеера могла парсить контейнер и структурные части кодека, не имея ключа.
2. Какой ключ использовался? – это записано как 16-байтовый идентификатор default_KID в метаданных.
3. Какие DRM-системы вправе разблокировать файл и где у каждой её license-сервер? – это описано в одном или нескольких боксах pssh, по одному на DRM.
4. Какой режим шифрования и какой паттерн используется? – это записано четырёхбуквенным тегом схемы (cenc, cbc1, cens или cbcs) в боксе schm.

Запомните эти четыре вопроса – всё остальное в статье просто их раскрывает. Стандарт, определяющий все четыре, – ISO/IEC 23001-7:2023, сейчас в 3-м издании (конец 2023 г.), который надстраивается над ISO Base Media File Format (ISO/IEC 14496-12), описывающим контейнеры MP4, fragmented MP4 и CMAF.

Стандарт не описывает протокол управления ключами, API license-сервера или конкретный DRM. Он намеренно нейтрален: любой DRM, умеющий читать метаданные файла и получить нужный контентный ключ, может его расшифровать. В этой нейтральности и есть весь смысл – одно шифрование, много DRM.

Нажмите, чтобы увеличить

Четыре схемы защиты (и почему выживают только две)

Стандарт определяет четыре схемы, и их имена важны – вы встретите их в флагах упаковщика, в сигнализации манифеста и в логах. Каждая схема делает два выбора: режим блочного шифра (CTR-счётчик против CBC-сцепления блоков) и покрытие шифрования (каждый байт сэмпла против периодического паттерна).

cenc – AES-128 в режиме CTR (счётчик), применяется ко всему содержимому каждого подсэмпла. Это исходная схема 2012 года и исторический дефолт для MPEG-DASH на не-Apple устройствах. CTR позволяет декодеру параллельно дешифровать и перематывать сэмплы, не цепляясь за шифротекст предыдущего сэмпла – отсюда естественная совместимость с быстрыми видео-пайплайнами.

cbc1 – AES-128 в режиме CBC, применяется ко всему содержимому каждого подсэмпла. Определена, но почти не используется в продакшене. CBC цепляет каждый 16-байтовый блок к предыдущему, что делает произвольный доступ чуть дороже, чем CTR.

cens – AES-128 в режиме CTR с паттерном: шифруется только один из каждых десяти 16-байтовых блоков подсэмпла; остальные девять идут открытым текстом. Паттерн был добавлен, чтобы устаревшие чипы смарт-ТВ и недорогие телефоны успевали в реальном времени дешифровать высокобитрейтные стримы. Определена, но в продакшене редкость.

cbcs – AES-128 в режиме CBC с тем же паттерном 1-из-10. Это та схема, которую требует Apple FairPlay Streaming, и она стала продакшен-дефолтом в 2026 году. Технически паттерн – это crypt_byte_block = 1 и skip_byte_block = 9: один 16-байтовый блок шифруется, девять пропускаются, повторить – измеряется внутри каждого NAL-подсэмпла видео.

Из четырёх схем в продакшен идут только две: cenc (легаси-DASH, до 2018 г.) и cbcs (совместимая с Apple, совместимая со всеми, дефолт 2026 года). Паттерн-режимы cens и cbc1 существуют на бумаге, но ни один крупный DRM-вендор не сделал их стандартом.

Почему паттерн вообще важен – стоит абзаца. 4K HDR-стрим на 30 кадрах в секунду гонит примерно 15–25 Мбит/с закодированного видео. Если каждый байт каждого видео-сэмпла должен проходить через AES-раунд на пятилетнем смарт-ТВ, аппаратный ускоритель чипа может не справиться в реальном времени. Паттерн-шифрование Apple представил в 2014 году (в первой FairPlay Streaming для HLS) ровно потому, что iPhone 4s и более ранние устройства не могли позволить себе AES-дешифрование каждого байта HD-видео в софте. Зашифрованный 1-из-10 даёт примерно ту же защиту от пассивного атакующего – зашифрованных блоков достаточно, чтобы открытые блоки не несли полезной структуры для парсера кодека – при одной десятой стоимости CPU. После того как Apple сделал cbcs дефолтом FairPlay, остальной индустрии пришлось последовать.

Замечательно, насколько полно cbcs победил в 2026. Apple требовал его с первого дня (FairPlay никогда ничего другого не поддерживал). Widevine добавил полную поддержку cbcs в середине 2018 года в Modular DRM v15. PlayReady добавил поддержку cbcs в v4.2 (2019). DASH-IF Content Protection Information Exchange (CPIX) и DASH-IF Implementation Guidelines for Security закрепили правило: зашифрованный DASH-контент ОБЯЗАН использовать либо схему cenc, либо cbcs, две схемы взаимоисключающи внутри одного adaptation set, и современные упаковщики дефолтят на cbcs – потому что только её Apple соглашается дешифровать.

Нажмите, чтобы увеличить

Метаданные-боксы, которые держат всё вместе

ISO/IEC 23001-7 определяет небольшой набор метаданных-боксов – коротких самоописательных бинарных блоков – которые упаковщик записывает в каждый защищённый файл. Четыре из них нужно знать.

schm (Scheme Type box) располагается в иерархии sample-description и несёт четырёхбуквенное имя схемы. Когда вы открываете CMAF init-сегмент через mp4dump или Bento4, schm будет где-то под moov/trak/mdia/minf/stbl/stsd/sinf/schm и сообщит cenc или cbcs. Этот четырёхсимвольный код и говорит плееру, в каком режиме дешифровать.

tenc (Track Encryption box) – самый важный бокс файла. Он несёт дефолтные параметры шифрования для каждого сэмпла трека: default_KID (16-байтовый идентификатор ключа – какой именно контентный ключ использован), размер IV по умолчанию, дефолтные crypt-byte-block / skip-byte-block для паттерн-схем и флаг «является ли защищённым». По правилам DASH-IF в каждом защищённом треке ровно один tenc-бокс, находящийся по пути moov/trak/mdia/minf/stbl/stsd/sinf/schi/tenc. Значение default_KID из tenc копируется в манифест как атрибут cenc:default_KID – и именно это значение плеер передаёт DRM как «мне нужен ключ с таким ID».

default_KID – 128-битное значение, записываемое в строковой форме как 32 hex-цифры с дефисами, например 34e5db32-8625-47cd-ba06-68fca0655a72. Внешне похоже на UUID, но стандарт не ограничивает биты так же, как это делает RFC 4122 для UUID – поэтому валидировать как UUID не нужно, валидируйте как произвольный 16-байтовый идентификатор. Распространённая ошибка: некоторые Windows-библиотеки сериализуют первые три группы UUID в little-endian (соглашение «Microsoft GUID»), тогда как остальной инструментарий – в big-endian. DASH-IF явно требует, чтобы порядок байт в бинарном tenc и в строковой форме атрибута MPD совпадал. Перепутаете – license-сервер вернёт неверный ключ, CDM расшифрует в мусор, и плеер либо покажет чёрный экран, либо отдаст MEDIA_ERR_DECODE без диагностики.

pssh (Protection System Specific Header box) – здесь и случается multi-DRM. По одному боксу pssh на каждую DRM-систему, каждый несёт 16-байтовый System ID, идентифицирующий вендора DRM, плюс небольшой DRM-специфичный payload (Widevine кладёт Protobuf-сообщение; PlayReady кладёт base-64 XML с «Pro header»; FairPlay обычно бокс не пишет, а сигнализирует через HLS-нативные EXT-X-KEY-строки). System ID не придумываются на ходу – они выдаются централизованно и поддерживаются в реестре DRM-system identifier DASH-IF. Три, которые встретятся в каждом multi-DRM стриме:

• Widevine – edef8ba9-79d6-4ace-a3c8-27dcd51d21ed
• PlayReady – 9a04f079-9840-4286-ab92-e65be0885f95
• Apple FairPlay – 94ce86fb-07ff-4f43-adb8-93d2fa968ca2 (редко пишется в файл; FairPlay-лицензирование обычно сигнализируется в HLS-манифесте, а не через moov/pssh)
• W3C Common SystemID – 1077efec-c0b2-4d02-ace3-3c1e52e2fb4b (определён в W3C "cenc" Initialization Data Format – позволяет плееру запросить ключ по KID без выбора конкретного DRM-вендора)

Современные рекомендации DASH-IF – класть pssh-боксы в MPD-манифест, а не в moov init-сегмента, поскольку манифесты проще обновлять, чем ре-муксить init-сегменты при каждом добавлении DRM. Init-сегмент может вовсе не содержать moov/pssh, и плеер заберёт pssh-данные из элемента <ContentProtection> манифеста под cenc:pssh (в base64). HLS делает то же через теги EXT-X-KEY и EXT-X-SESSION-KEY.

senc, saiz, saio (per-sample encryption metadata) живут внутри каждого фрагмента в moof/traf и несут initialisation vectors per-sample и, если диапазоны подсэмплов варьируются, счётчики байтов подсэмплов. Руками вы их обычно не пишете – это работа упаковщика. Но если mediastreamvalidator или mp4dump из Bento4 жалуется на отсутствующий senc-бокс – вы знаете, где сломался слой.

Нажмите, чтобы увеличить

Как одно шифрование становится тремя лицензиями

Трюк, делающий multi-DRM экономически выгодным, – не в криптографии, а в адресации. Вот вся цепочка сквозь, пройденная один раз, чтобы дальше уже не повторяться.

Упаковщик шифрует каждый adaptation set одним 16-байтовым контентным ключом – назовём его K. Он записывает идентификатор ключа – default_KID – в бокс tenc и пишет по одному pssh-боксу на каждую DRM, которую планирует поддерживать. Каждый pssh называет DRM через свой System ID и несёт небольшой DRM-специфичный payload, чтобы license-сервер этой DRM смог распознать именно этот стрим.

Упаковщик не хранит K нигде в файле. K живёт только в Key Management System (KMS) стриминг-сервиса, проиндексированный по default_KID. Зашифрованный файл без K бесполезен, а K никогда не уходит к плееру напрямую – только к license-серверу DRM.

Когда зритель нажимает Play, плеер загружает манифест, видит сигнализацию защиты и выбирает DRM, который поддерживает устройство (Widevine в Chrome, FairPlay в Safari, PlayReady на Tizen-телевизоре). Плеер передаёт соответствующие pssh-данные – или в HLS, данные EXT-X-KEY – в Content Decryption Module устройства через W3C-API Encrypted Media Extensions. CDM формирует blob запроса лицензии, плеер POST-ит его на эндпоинт license-сервера сервиса, license-сервер аутентифицирует запрос, достаёт K из KMS по default_KID, заворачивает K в DRM-специфичный blob и возвращает. CDM разворачивает K внутри своей защищённой памяти, расшифровывает каждый сэмпл с IV из senc-бокса и режимом из schm, и декодированные пиксели идут прямо в аппаратный видео-пайплайн устройства – невидимо ни для JavaScript, ни для ядра, ни для любого непривилегированного процесса.

Это и есть весь multi-DRM трюк. Один файл, один ключ, несколько DRM, у каждой свой license-сервер, и все они согласованы по default_KID как индексу. Различия между тремя DRM целиком ниже API-слоя – все они говорят с теми же CENC-зашифрованными байтами через EME.

Дефолт 2026 года: CMAF + `cbcs` + два манифеста

Этот раздел – практический вывод из всего вышенаписанного.

В 2026 году у платных стриминг-сервисов доминирует стек, который можно назвать single-encryption multi-DRM: один набор CMAF-сегментов в fMP4, зашифрованных однажды по cbcs, сигнализированных в двух манифестах – HLS-плейлист для Apple-устройств и MPEG-DASH MPD для всего остального – и расшифровываемых Widevine, FairPlay или PlayReady в зависимости от того, какой CDM есть у устройства. Один и тот же набор сегментов служит всем трём DRM.

Так было не всегда. С 2012 по примерно 2018 индустрия жила на двойном шифровании: закодировать каталог, потом зашифровать дважды – один раз cenc для пути DASH/Widevine/PlayReady и один раз cbcs для пути HLS/FairPlay – хранить обе копии на origin и подавать их через два параллельных манифестных пайплайна. Цена – чистое удвоение origin-стораджа и операционный оверхед на поддержание двух параллельных пакетных пайплайнов в синхроне.

Переход к cbcs-только случился в три шага. Первое – Apple на WWDC 2016 анонсировал поддержку fMP4-в-HLS, что технически позволило использовать одни и те же CMAF-сегменты в обоих протоколах. Второе – DASH-IF Implementation Guidelines for Security формализовали правило, что cbcs – допустимая схема защиты для DASH (исторически DASH дефолтил на cenc). Третье – крупнейшие DRM-вендоры добавили полную поддержку cbcs в свои license-серверы и CDM-ы (Widevine в 2018, PlayReady в 2019), убрав последнюю причину поддерживать параллельный cenc-пайплайн.

К 2026 году экономия на сторадже определяющая. Стриминг-сервис на тысячу часов каталога в 4K HDR + 1080p SDR + аудио-рендициях хранит примерно 8 ТБ на проход кодирования; путь двойного шифрования удваивал это до 16 ТБ. Двойное шифрование удваивало и трафик при перепакете, плодило кеш-фootprint на каждом edge CDN и гнало два пайплайна управления ключами через KMS. Одиночное cbcs-шифрование схлопывает каждую из этих линий, и единственное, что двойной путь ещё даёт – совместимость с легаси-DASH-плеерами, которые не обновлялись с 2018 года. Для нового стриминг-сервиса в 2026 году шифровать дважды – это нести постоянные расходы на проблему, которой уже нет.

Одна оговорка: DASH-IF guidelines всё ещё разрешают двойное шифрование в варианте, когда в одном Period предлагаются обе схемы как равные альтернативы для клиентов с разными возможностями. На практике почти не встречается – большинство современных плееров умеют cbcs нативно – но стандарт оставляет дверь открытой.

Рабочий пример: шифрование одного CMAF-стрима

Прогоним числа по одному сегменту, чтобы байтовая экономика стала конкретной. Возьмём 4-секундный CMAF-сегмент 1080p H.264 на примерно 2.5 Мбит/с – это около 1.25 МБ на сегмент.

Внутри сегмента – около 120 видео-сэмплов (по одному на кадр при 30 fps). Каждый сэмпл содержит несколько NAL-юнитов; для H.264 зашифрованный диапазон покрывает только slice-data часть каждого VCL NAL-юнита, оставляя байт NAL-заголовка и структурные SEI/SPS/PPS NAL-ы открытыми. Зашифрованный диапазон на сэмпл – порядка 6–12 КБ для 1080p-кадра.

Под cenc каждый 16-байтовый блок внутри этих 6–12 КБ проходит через AES-128 CTR – примерно 400–750 AES-раундов на сэмпл, или 48 000–90 000 AES-раундов на сегмент. Современные CPU и видео-пайплайны GPU цепляют AES-NI для этой работы; Cortex-A53 в пятилетнем смарт-ТВ делает это в софте и платит реальной нагрузкой CPU.

Под cbcs паттерн crypt_byte_block = 1, skip_byte_block = 9, и из каждых десяти 16-байтовых блоков шифруется только первый. На тех же 6–12 КБ зашифрованного диапазона теперь нужно 40–75 AES-раундов на сэмпл – примерно одна десятая работы cenc. Всего на сегмент: 4 800–9 000 AES-раундов. На бюджетном смарт-ТВ это разница между «роняем кадры» и «успеваем за видеочасами».

Замечание про IV: под cenc IV строится per-sample из base IV в tenc плюс per-block счётчик; под cbcs IV – фиксированное 16-байтовое значение на сэмпл из бокса senc, применяемое к первому зашифрованному блоку каждого паттерна. senc также сообщает CDM, где начинается и заканчивается зашифрованный диапазон каждого подсэмпла, чтобы CDM пропустил открытые NAL-заголовки без парсинга H.264-битстрима.

Последнее важно в продакшене: поскольку CDM работает только с зашифрованными байтовыми диапазонами и никогда не парсит кодек, он одинаково работает для H.264, H.265, AV1 и любого будущего кодека – парсеру кодека не нужно знать про DRM. Нейтральность CENC по кодекам – одна из причин, по которым он пережил переход на AV1 неизменным.

Как CENC проявляется в манифесте

Когда вы дебажите реальный стрим, вы видите CENC через манифесты, а не через бинарные боксы. Вот как выглядит сигнализация в каждом протоколе.

В MPEG-DASH MPD каждый зашифрованный adaptation set несёт минимум два элемента <ContentProtection>. Первый использует schemeIdUri="urn:mpeg:dash:mp4protection:2011", объявляет схему защиты в атрибуте value (cbcs или cenc) и несёт атрибут cenc:default_KID, называющий контентный ключ. Второй и третий используют schemeIdUri="urn:uuid:<systemid>" с System ID конкретной DRM, плюс дочерний элемент cenc:pssh, содержащий base64-encoded содержимое pssh-бокса. Типичный стрим 2026 года несёт три таких элемента – один общий CENC, один Widevine, один PlayReady – плюс четвёртый <ContentProtection> с FairPlay-специфичной сигнализацией для HLS-сиблинга. DASH-IF Implementation Guidelines for Security требуют, чтобы дескриптор был определён на уровне adaptation set, а не отдельных representations.

В HLS multi-variant playlist шифрование сигнализируется тегами EXT-X-KEY внутри каждого media playlist варианта. Два метода, которые вы увидите: METHOD=SAMPLE-AES (для легаси MPEG-TS-в-HLS с FairPlay и для современного fMP4-в-HLS с cbcs) и METHOD=SAMPLE-AES-CTR (для fMP4-в-HLS с cenc – в 2026 редкость). Атрибут KEYFORMAT называет DRM: com.apple.streamingkeydelivery для FairPlay, urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed для Widevine (когда поддерживается в hls.js) и т.д. Атрибут URI называет эндпоинт license-сервера – или, чаще, короткий префикс с токеном, который плеер передаёт в платформенный license-server-helper API.

В CMAF шифрование – в fMP4-иерархии боксов, описанной выше. Один и тот же CMAF-сегмент служит и HLS, и DASH, потому что бинарная структура боксов идентична – отличается только манифест над ней.

Тег EXT-X-SESSION-KEY, добавленный во вторую редакцию HLS (RFC 8216bis), позволяет multi-variant playlist объявить ключи один раз наверху, не повторяя их в каждом варианте. Современные HLS-авторы используют его, чтобы анонсировать один и тот же контентный ключ на все рендиции adaptation set – зеркалируя то, как DASH ставит сигнализацию защиты на уровень adaptation set.

Сравнение: `cenc` против `cbcs` в реальности

Вывод в одну ячейку: для любого нового пайплайна выбирайте cbcs. cenc выбирайте только если у вас уже есть DASH-only пайплайн с плеерами, которые нельзя обновить.

Типичные ошибки и подводные камни

В продакшене мы видим одни и те же четыре ошибки раз за разом. Их стоит перечислить – каждая стоила клиенту релизной недели на отладку.

1. Зашифровали cenc, а потом узнали про FairPlay. Команда запускает DASH-only OTT-продукт, шифрует каталог по cenc, отгружает в продакшен и узнаёт из ревью iOS-приложения, что Safari и tvOS нуждаются в FairPlay. FairPlay не дешифрует cenc. Лечение – перешифровать каждый кодированный ассет в cbcs, что удваивает сторадж на время существования обеих копий и втрое увеличивает срок выхода на iOS. Правильный ответ на этапе упаковки – cbcs по умолчанию; неправильный – откладывать решение про iOS до того момента, когда каталог уже зашифрован.

2. Положили default_KID big-endian в tenc и little-endian в манифест. Некоторые Windows-библиотеки используют байтовый порядок «Microsoft GUID» для первых трёх групп UUID – первые 4 байта, следующие 2 и следующие 2 пишутся little-endian, остальное big-endian. DASH-IF требует, чтобы порядок байт в бинарном tenc и в строковом атрибуте cenc:default_KID совпадал. Перепутаете – license-сервер вернёт не тот ключ, CDM расшифрует в мусор, плеер покажет чёрный экран или отдаст MEDIA_ERR_DECODE без диагностики. Лечится одной строкой в GUID-сериализации упаковщика, но обычно ищется день.

3. Записали pssh-боксы только в moov и забыли манифест. Старые рекомендации предлагали moov/pssh внутри init-сегмента. Современный DASH-IF кладёт pssh-данные в элемент <ContentProtection> манифеста под cenc:pssh, потому что манифесты дешевле обновлять, чем init-сегменты. Если команда добавляет новую DRM (скажем, PlayReady поверх существующего Widevine/FairPlay запуска) и переписывает init-сегменты вместо обновления манифестов – каждый закешированный init-сегмент на каждом edge CDN нужно инвалидировать, и это многодневная просадка кеша, которую манифест-исправление полностью отменяет.

4. Один и тот же контентный ключ на весь каталог. Технически допустимо шифровать каждый ассет одним K и одним default_KID. И это единственная точка отказа: если K утечёт один раз – расшифрован весь каталог, а отзыв через политику DRM сделать гораздо сложнее, чем ротацию ключей по тайтлам или эпизодам. Рекомендации по защите контента, выровненные на MPA, требуют свежего контентного ключа как минимум на каждый тайтл, а лучше – на период (несколько часов live или сутки VOD). Современные KMS делают per-title ключи дешёвыми – делайте.

Где здесь Фора Софт

Мы строим слой шифрования-и-DRM внутри видеопродуктов в видеостриминге, OTT и Internet TV, телемедицине, видеоконференциях, e-learning и видеонаблюдении. Паттерн всегда один и тот же: выбрать упаковщик с поддержкой CMAF + cbcs (мы шипили в продакшен с Shaka Packager, Bento4, AWS MediaPackage и Unified Streaming), завести его в KMS, говорящую на Content Protection Information Exchange (CPIX), нацелить плееры на managed multi-DRM license-server-вендора и интегрировать эндпоинт license-сервера в session-token модель продукта. Само шифрование – две конфигурационные опции в современном упаковщике; работа – в политическом слое над ним: гео-правила, output-protection rules, истечение сессии, persistent vs streaming licenses. Именно туда уходит инженерное время на каждом запуске платного стриминга.

Нажмите, чтобы увеличить

Ключевые выводы

• CENC – это формат, благодаря которому один зашифрованный CMAF-файл дешифруется Widevine, FairPlay или PlayReady через один вызов license-сервера на сессию.
• Четыре схемы защиты определены; в продакшен идут только две – cenc (AES-CTR full-subsample, легаси) и cbcs (AES-CBC pattern, дефолт 2026 года).
• Боксы pssh, tenc, schm и senc – четыре структуры метаданных, на которых стоит каждый multi-DRM стрим.
• Современные DASH-IF guidelines кладут pssh-данные в манифест, а не в init-сегмент – добавление DRM не требует пере-муксинга ассетов.
• Двойное шифрование (cenc для DASH + cbcs для HLS) – паттерн до 2020 года; в 2026 одно cbcs-шифрование обслуживает оба протокола.

Что почитать дальше

• DRM 101: почему три системы и почему вы ставите все три
• CMAF: формат упаковки, объединивший HLS и DASH
• Encrypted Media Extensions (EME): как DRM живёт в браузере