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

TL;DR

Common Encryption – сокращённо CENC, стандартизованный как ISO/IEC 23001-7 (действующее 3-е издание, 2023 г.) – это формат, позволяющий одному и тому же зашифрованному видеофайлу расшифровываться в любой из трёх крупнейших систем управления цифровыми правами: 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. Какие байты внутри каждого видео-сэмпла зашифрованы, а какие остаются открытыми? – чтобы медиаплатформа плеера могла анализировать контейнер и структурные элементы кодека без наличия ключа.
2. Какой ключ использовался? – он указан в виде 16-байтового идентификатора default_KID в метаданных.
3. Какие DRM-системы имеют право разблокировать файл и где расположены их серверы лицензирования? – эта информация содержится в одном или нескольких боксах pssh, по одному на каждую DRM-систему.
4. Какой режим шифрования и какой паттерн применяются? – это определено четырёхбуквенным тегом схемы (cenc, cbc1, cens или cbcs) в боксе schm.

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

Стандарт не описывает протокол управления ключами, API лицензионного сервера или конкретный 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 в версии 4.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-описания и содержит четырёхбуквенное имя схемы. Когда вы открываете 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 шестнадцатеричных цифр, разделённых дефисами, например 34e5db32-8625-47cd-ba06-68fca0655a72. По внешнему виду напоминает UUID, но стандарт не накладывает на биты таких ограничений, как RFC 4122 для UUID, поэтому проверять его как UUID не нужно – достаточно считать произвольным 16-байтовым идентификатором. Распространённая ошибка: некоторые библиотеки Windows при сериализации первых трёх групп UUID используют порядок байт little-endian (в соответствии с соглашением «Microsoft GUID»), тогда как остальные инструменты работают в big-endian. DASH-IF чётко требует, чтобы порядок байт в бинарном tenc и в строковом представлении атрибута MPD совпадал. Если перепутать – сервер лицензирования вернёт неверный ключ, CDM расшифрует данные в мусор, и плеер либо покажет чёрный экран, либо выдаст MEDIA_ERR_DECODE без какой-либо диагностики.

pssh (Protection System Specific Header box) – именно здесь реализуется поддержка multi-DRM. На каждую DRM-систему приходится отдельный бокс pssh, содержащий 16-байтовый System ID, который идентифицирует поставщика DRM, а также небольшой специфичный для DRM полезный груз (payload). Widevine помещает туда Protobuf-сообщение, PlayReady – base-64-кодированный XML с «Pro header», а FairPlay, как правило, не использует этот бокс, а передаёт информацию через нативные строки EXT-X-KEY в HLS. System ID не создаются произвольно – они выдаются централизованно и поддерживаются в реестре DRM-идентификаторов 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 (метаданные шифрования на выборку) находятся внутри каждого фрагмента в moof/traf и содержат векторы инициализации на выборку, а также, если диапазоны подвыборок различаются, – счётчики байтов подвыборок. Обычно их не пишут вручную – этим занимается упаковщик. Но если mediastreamvalidator или mp4dump из Bento4 жалуется на отсутствующий senc-бокс, вы сразу поймёте, где произошёл сбой.

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

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

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

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

Упаковщик нигде в файле не хранит K. Ключ K существует только в системе управления ключами (KMS) стриминг-сервиса и индексируется по default_KID. Зашифрованный файл без K бесполезен, а сам ключ никогда не передаётся напрямую плееру – только на сервер лицензирования 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-сервера сервиса. Сервер аутентифицирует запрос, извлекает ключ K из KMS по default_KID, упаковывает его в DRM-специфичный blob и возвращает. CDM распаковывает K в своей защищённой памяти, расшифровывает каждый сэмпл с использованием IV из senc-бокса и режима из schm, после чего декодированные пиксели поступают напрямую в аппаратный видео-пайплайн устройства – оставаясь недоступными ни для JavaScript, ни для ядра, ни для любого непривилегированного процесса.

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

К 2026 году экономия на сторадже становится определяющей. Стриминг-сервис с каталогом в 1000 часов в форматах 4K HDR, 1080p SDR и различных аудиорендеров хранит около 8 ТБ на один проход кодирования; двойное шифрование удваивает этот объём – до 16 ТБ. Оно же удваивает и трафик при перепакете, увеличивает кеш-футпринт на каждом 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 и структурные NAL-юниты SEI/SPS/PPS открытыми. Объём зашифрованных данных на один сэмпл составляет порядка 6–12 КБ для кадра в разрешении 1080p.

Под cenc каждый 16-байтовый блок в этих 6–12 КБ обрабатывается с помощью AES-128 CTR – примерно 400–750 раундов AES на сэмпл, или 48 000–90 000 раундов на сегмент. Современные 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-4 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-кодированное содержимое pssh-бокса. Типичный стрим 2026 года включает три таких элемента – один общий CENC, один для Widevine, один для PlayReady – плюс четвёртый <ContentProtection> с сигнализацией, специфичной для FairPlay, предназначенной для HLS-аналога. DASH-IF Implementation Guidelines for Security требуют, чтобы дескриптор защиты был определён на уровне adaptation set, а не отдельных представлений.

В 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 задаёт эндпоинт лицензионного сервера – или, чаще, короткий префикс с токеном, который плеер передаёт в API-обработчик лицензий платформы.

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

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

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

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

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

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

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 – в формате 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 и интернет-ТВ, телемедицины, видеоконференций, e-learning и видеонаблюдения. Паттерн везде одинаков: выбираем упаковщик с поддержкой CMAF + cbcs (в продакшене использовали Shaka Packager, Bento4, AWS MediaPackage и Unified Streaming), подключаем его к KMS, поддерживающей Content Protection Information Exchange (CPIX), нацеливаем плееры на managed multi-DRM license-сервер от вендора и интегрируем эндпоинт license-сервера в модель session-токенов продукта. Само шифрование – всего две конфигурационные опции в современном упаковщике; основная работа – в политическом слое над ним: гео-правила, правила защиты вывода, срок действия сессии, выбор между persistent и streaming лицензиями. Именно на этом этапе уходит основное инженерное время при каждом запуске платного стриминга.

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

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

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

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

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