CENC и CBCS: common encryption для стриминга

TL;DR

Common Encryption (CENC), описанный в стандарте ISO/IEC 23001-7, – это способ зашифровать видео так, чтобы один и тот же набор файлов могли открыть все три основные системы защиты контента: Google Widevine, Microsoft PlayReady и Apple FairPlay, и при этом вы шифруете каталог лишь однажды. Стандарт определяет два реально применяемых «рецепта» шифрования: cenc использует шифр AES в режиме счётчика (AES-CTR), а cbcs – AES в режиме сцепления блоков (AES-CBC) с повторяющимся паттерном; они дают разные зашифрованные байты, поэтому устройство понимает только тот рецепт, который знает его система. Apple FairPlay принимает только cbcs, а современные Widevine и PlayReady принимают оба, и именно поэтому вся индустрия сошлась на одном правиле – шифруйте один раз по cbcs, и контент откроется на любом устройстве. Эта статья простыми словами объясняет, что такое режимы AES, subsample-шифрование и pattern-шифрование, почему две схемы несовместимы, почему FairPlay предопределил выбор cbcs и какие именно байты и метаданные делают один файл читаемым тремя разными системами защиты.

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

Если вы основатель, продакт-менеджер или впервые отвечаете за стриминг как CTO, это самое весомое техническое решение во всей вашей защите контента – и умещается оно в одну строку конфигурации упаковки: какую схему шифрования вы выбираете. Сделаете правильно – одна зашифрованная копия каталога играет на любом экране в мире; ошибётесь – либо платите за двойное хранение и шифрование, либо выпускаете библиотеку, которая показывает чёрный экран на каждом устройстве Apple, и узнаёте об этом уже после релиза. Реализовывать всё это самому не нужно – криптографию делает multi-DRM-сервис или упаковщик, – но понимать выбор нужно достаточно хорошо, чтобы выставить его верно, прочитать спецификацию вендора и пройти security review студии. К концу статьи вы сможете объяснить, почему «шифруем один раз, лицензируем многократно» физически возможно, вслух назвать разницу между cenc и cbcs и знать, почему упаковку стоит стандартизировать на cbcs.

Это техническое сердце нашего блока про защиту контента. Здесь мы открываем «коробку шифрования» и смотрим на шестерёнки под капотом статьи Multi-DRM: один воркфлоу, любое устройство, которая показывала пайплайн «шифруем один раз» с высоты птичьего полёта. Статья предполагает, что вы уже знаете расклад по устройствам из Три системы DRM: Widevine, PlayReady, FairPlay. Бэкграунд в криптографии не нужен – каждый термин мы строим с нуля.

Какую одну проблему решает Common Encryption

Начнём с проблемы, потому что замысел понятен, только когда чувствуешь боль, которую он снимает. Защита контента – это не одна технология, а три конкурирующие, и каждая принадлежит своей платформенной компании и встроена в её устройства: Google Widevine, Microsoft PlayReady и Apple FairPlay. У них разные форматы лицензий и разные «рукопожатия», и ни одна не покрывает все экраны. Платформа, которая хочет играть на устройствах Apple, телефонах Android, ноутбуках Windows и десятке марок умных телевизоров, обязана удовлетворить все три. (Карта «устройство – система» – тема статьи Три системы DRM; здесь мы берём её как данность.)

Наивный путь – зашифровать каталог трижды, в приватном формате каждого вендора. Это утраивает вычисления на кодирование, утраивает хранение и утраивает операционную головную боль, не давая ни грамма дополнительной защиты. Стандарт, который делает эту тройку ненужной, называется Common Encryption, сокращённо CENC, и описан в ISO/IEC 23001-7. Его задача, словами самого стандарта, – задать «методы шифрования и сопоставления ключей, позволяющие расшифровать один и тот же файл разными системами DRM и управления ключами».

Перечитайте: один и тот же файл, расшифрованный разными системами DRM. Common Encryption – это не сам DRM. Он не выдаёт лицензии, не хранит ключи и не применяет правила – он намеренно «оставляет детали сопоставления прав, получения и хранения ключей, правил соответствия DRM и т. п. самой системе или системам DRM». Стандартизирует он только шифрование байтов и небольшой набор меток, которые подсказывают любому совместимому DRM, где находится запертая дверь. Представьте морской контейнер со стандартным креплением под замок: три разные охранные фирмы могут навесить на одну и ту же петлю свой замок. Common Encryption – это стандартная петля. Замки – Widevine, PlayReady и FairPlay.

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

Два слоя ещё раз: шифрование против лицензирования

Перед механикой зафиксируем разделение, на котором держится вся статья, потому что почти каждая путаная статья про DRM его смазывает. У защищённого потока два отдельных слоя.

Слой шифрования – это собственно шифрование байтов видео и аудио ключом. Этот слой общий: все три системы DRM читают одни и те же зашифрованные файлы, если файлы используют схему, понятную всем трём. Именно этот слой стандартизирует Common Encryption, и именно о нём эта статья.

Слой лицензии – это небольшое сообщение, выдаваемое вживую при воспроизведении, которое передаёт конкретному устройству ключ для расшифровки, упакованный так, чтобы открыть его могло только доверенное «железо» этого устройства. Этот слой свой для каждой системы: у каждого вендора свой формат лицензии и своё рукопожатие, и они не взаимозаменяемы. Как сервер лицензий на деле доставляет этот ключ – тема статьи Лицензионные серверы и доставка ключей.

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

AES простыми словами: ключи и блоки по 16 байт

Само шифрование использует Advanced Encryption Standard, AES – тот же рабочий шифр, что защищает банковский трафик и хранилища паролей. Внутренности знать не нужно, достаточно трёх фактов.

Во-первых, AES работает с блоками: фиксированными кусками ровно по 16 байт. Стандарт Common Encryption так и определяет блок – «отрезок данных сэмпла в 16 байт, который может быть зашифрован или расшифрован блочным шифром AES-128». Ваше видео – длинная река байтов; AES режет защищаемые части на блоки по 16 байт и шифрует их по одному.

Во-вторых, AES нужен ключ – секретное число, здесь длиной 128 бит (те самые «128» в AES-128). Один и тот же ключ запирает и отпирает. Вся игра DRM – доставить этот ключ нужному устройству и больше никуда; само шифрование – простая стандартизированная часть.

В-третьих, «сырому» блочному шифру нужен режим работы – правило, как отдельные блоки по 16 байт связаны друг с другом по мере движения вниз по реке. Если наивно зашифровать каждый блок одним ключом и больше ничем, два одинаковых блока видео дадут одинаковый результат и выдадут паттерны. Режим это предотвращает, и именно на выборе режима расходятся cenc и cbcs. В игре два режима, и разница между ними – центральный факт всей статьи.

CTR против CBC: два режима, разводящие схемы

Вот два режима, каждый – с картинкой простыми словами. Не спешите: по одной мысли на каждый.

Режим счётчика, AES-CTR. Счётчик не шифрует ваше видео напрямую. Вместо этого он шифрует растущий счётчик – 1, 2, 3 и так далее, – соединённый со стартовым числом сэмпла, которое называется вектор инициализации (IV): значение (8 или 16 байт), делающее поток ключей уникальным. Шифрование счётчика даёт псевдослучайный поток байтов – keystream, и видео шифруется, комбинируясь с этим потоком. Полезное свойство: поскольку каждый блок зависит только от своего значения счётчика, можно прыгнуть сразу к блоку № 5000 и расшифровать его, не трогая 4999 предыдущих. Этот произвольный доступ и возможность расшифровывать блоки параллельно – причина, по которой режим счётчика стал исходным выбором для доставки MPEG-DASH. На нём построена схема cenc.

Режим сцепления блоков, AES-CBC. Режим сцепления шифрует блоки видео напрямую, но каждый блок сначала смешивается с зашифрованным результатом предыдущего блока – блоки сцеплены, как связка альпинистов на одной верёвке. Первый блок смешивается с вектором инициализации; каждый следующий – с предыдущим. Важное свойство: нельзя расшифровать блок № 5000, не пройдя цепочку до него, поэтому сцепление последовательно, без произвольного доступа. Стриминг Apple с самого начала использовал CBC – почему, разберём чуть ниже. На сцеплении построена современная схема cbcs.

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

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

Полное против subsample: почему заголовки оставляют открытыми

Поверх выбора режима есть второй выбор: сколько каждого кадра шифровать. Зашифровать каждый байт файла кажется самым надёжным, но это кое-что ломает. Видеопоток – не однородный «комок», а последовательность структурированных пакетов. У современных кодеков эти пакеты называются NAL-юнитами (Network Abstraction Layer): каждый несёт небольшой заголовок «какие данные дальше» и затем сами сжатые данные картинки.

Плееры, упаковщики и устройства должны читать эти заголовки, чтобы ориентироваться в потоке – находить границы кадров, переключать качество, стартовать с нужного места. Если зашифровать и заголовки, каждый узел в цепочке доставки слепнет. Поэтому Common Encryption определяет subsample-шифрование: внутри каждого кадра небольшую открытую часть (структурный заголовок) оставляют в открытом виде, а шифруют только защищаемую часть (тяжёлые сжатые данные картинки, идущие следом). Стандарт так и определяет subsample – «открытая часть, за которой непосредственно следует защищаемая часть». Открытые заголовки дают цепочке рулить; зашифрованная нагрузка – то, что стоит украсть, – остаётся запертой.

Это и причина, почему DRM защищает поток и ключи, но не экран: байты нечитаемы в пути и в покое, но расшифрованный, декодированный кадр всё равно надо нарисовать на дисплее, а камера, наведённая на дисплей, видит картинку. Модель угроз разобрана в Зачем нужен DRM и что он на самом деле защищает; пока держите точную формулировку: шифрование скрывает сжатую нагрузку, а не итоговые пиксели.

Pattern-шифрование: 1:9, благодаря которому 4K дёшево расшифровывать

Третья и последняя механика – она же объясняет название современной схемы. Даже шифровать только нагрузку каждого кадра – это много криптографической работы, когда нагрузка – это поток 4K с высокой частотой кадров, и эта работа идёт ещё и на стороне расшифровки, на телефонах и чипах телевизоров с ограниченной мощностью. Поэтому в редакции стандарта 2016 года добавили pattern-шифрование: вместо шифрования всей защищаемой нагрузки шифруется повторяющаяся её доля.

Паттерн задаётся двумя небольшими числами, которые стандарт называет crypt_byte_block и skip_byte_block – сколько 16-байтовых блоков вы шифруете, затем сколько оставляете открытыми, повторяя до конца нагрузки. Прижилась рекомендованная стандартом схема 1:9 – зашифровать один блок, пропустить девять, повторить. Это значит, что шифруется лишь около одной десятой блоков нагрузки, но поскольку зашифрованные блоки густо рассыпаны по каждому кадру, поток бесполезен без ключа. Объяснение стандарта, зачем это добавили, прямое: «Pattern-шифрование снижает вычислительную мощность, необходимую устройствам для расшифровки видеодорожек».

Посчитаем вслух, потому что это и есть причина существования паттерна. Пусть защищаемая нагрузка кадра – 200 блоков по 16 байт:

Полное subsample-шифрование (cenc, cbc1):
  зашифровано блоков = 200  (100% нагрузки)

Pattern-шифрование 1:9 (cbcs, cens):
  один зашифрованный на десять = 200 / 10 = 20 блоков (10% нагрузки)
  работа на расшифровку        ≈ десятая часть от полного шифрования

На телефоне, декодирующем 4K от батареи, делать десятую часть работы по расшифровке – это разница между плавным воспроизведением и горячим, дёргающимся устройством. Две детали завершают картину. Pattern-шифрование применяется только к видео; аудио достаточно маленькое, чтобы шифровать его целиком (паттерн настроен шифровать всё, без пропусков). И cbcs сочетает pattern-шифрование с постоянным вектором инициализации, переиспользуемым по сэмплам, что упрощает «железо», тогда как cenc несёт свежий IV на каждый сэмпл. Эти детали ваш упаковщик делает автоматически – но именно из-за них две схемы ощущаются разными на практике, а не только в теории.

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

Четыре схемы – и две, которые реально применяются

Сложите выбор режима (CTR или CBC) с выбором охвата (полностью или паттерн) – и получите небольшую таблицу. Common Encryption даёт каждой комбинации четырёхсимвольный код. Действующая редакция 2023 года определяет пять схем, но реально применяются в мире только две. Эту таблицу и стоит запомнить.

Две схемы несут практически весь стриминг: cenc (режим счётчика, полностью) и cbcs (режим сцепления, паттерн 1:9). Остальные три есть в стандарте, но встретите вы их почти никогда – cbc1 и cens были ступеньками, а sve1 (кодек-зависимая «контент-чувствительная» схема, добавленная в четвёртой редакции 2023 года, где зашифрованный битстрим остаётся валидным декодируемым потоком) слишком нова, чтобы на неё закладываться. Когда вендор, спецификация или студия говорят про «две схемы», они имеют в виду cenc и cbcs. Всё остальное – сноска.

История сжимается до трёх шагов. Исходный Common Encryption выпустил cenc (режим счётчика), и MPEG-DASH его принял. Apple же всегда шифровала свои HLS-потоки AES в режиме CBC. Редакция 2016 года добавила pattern-схемы cbcs и cens именно для того, чтобы CBC-подход Apple жил внутри того же стандарта, что и у всех. Это единственное добавление и сделало конвергенцию возможной – и задало правило, управляющее вашей упаковкой сегодня.

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

Почему FairPlay нужен `cbcs` – и почему это всё решило

Вот правило, которое превращает всё вышесказанное в одну инструкцию по упаковке. Apple FairPlay принимает только cbcs. Он вообще не читает cenc. Это не предпочтение и не настройка, которую можно поменять; это жёсткое ограничение каждого iPhone, iPad, Mac и Apple TV.

Причина историческая и теперь постоянная. Задолго до Common Encryption Apple построила HLS – свой формат стриминга – на методе шифрования SAMPLE-AES, который шифрует только сэмплы аудио и видео с помощью AES в режиме сцепления блоков (CBC). Когда в 2016 году индустрия вписала pattern-шифрование в стандарт, существующий CBC-подход Apple лёг на новую схему cbcs, а не на счётную cenc. Apple решила принять открытый стандарт для контента fMP4 вместо расширения своего приватного формата, но осталась на стороне CBC. Итог – неподвижный факт, вокруг которого приходится проектировать любой multi-DRM-каталог: устройство FairPlay, получив байты, зашифрованные по cenc, не видит ничего, потому что у него нет расшифровщика режима счётчика.

Теперь соедините это с другой стороной таблицы. Современные Widevine и PlayReady принимают обе схемы – cenc и cbcs: их давно обновили читать схему сцепления. Посмотрите, какие на деле есть варианты. Выберете cenc – обслужите Widevine и PlayReady, но потеряете все устройства Apple. Выберете cbcs – обслужите FairPlay и современный Widevine и современный PlayReady, все три. Есть ровно одна схема, которую читают все три системы, и это cbcs. Одностороннее ограничение FairPlay тихо предопределило стандарт по умолчанию для всей индустрии.

«`cbcs` везде»: современная конвергенция

У этой логики есть имя в стриминговых кругах – «cbcs везде» – и на 2026 год это просто то, как делается защищённый стриминг. Примерно к 2020 году каждый крупный модуль расшифровки выпустил поддержку cbcs, и правило свелось к одной строке: упакуйте каталог один раз по cbcs, в контейнере CMAF, и тот же мастер транслируется в Widevine, PlayReady и FairPlay. Упакуете по cenc – отрежете Safari и все устройства Apple.

Это и есть глубинная причина, почему обещание «шифруем один раз, лицензируем многократно» из статьи про multi-DRM физически реально, а не маркетинг. Оно держится на двух стандартах, работающих вместе: схема cbcs из Common Encryption даёт один набор зашифрованных байтов, который принимают все три системы, а Common Media Application Format (CMAF, ISO/IEC 23000-19) даёт один сегментированный контейнер, который читают и HLS Apple, и доставка MPEG-DASH. Одна схема, один контейнер, один проход шифрования – воркфлоу упаковки, который это производит, разобран в Упаковка: CMAF, HLS и DASH из одного мезонина.

Одно точное предостережение, потому что популярные гайды ошибаются в обе стороны. Некоторые до сих пор говорят, что multi-DRM-каталог «обязан» хранить две зашифрованные копии – одну cenc и одну cbcs. По стандарту и текущей поддержке устройств это верно, только если в вашей аудитории есть старые клиенты, появившиеся до поддержки cbcs, – сжимающийся «легаси-хвост». Для современного набора устройств один ассет cbcs обслуживает все три системы, а вторая копия cenc – опциональный запасной вариант, а не требование. Правило: стандартизируйтесь на cbcs и добавляйте cenc только как осознанное, отмеренное исключение под конкретный хвост старых устройств, который вы решили поддерживать.

Что на самом деле внутри файла: схемы, ключи и боксы

Шифрование вы теперь понимаете. Последняя часть – маркировка: небольшие структуры метаданных, называемые боксами в формате файла MP4/CMAF, которые подсказывают системе DRM, как найти свой ключ и открыть байты. Их названия встретятся вам на дашбордах вендоров и в security-чеклистах студий, поэтому четыре из них стоит узнавать.

Бокс схемы (schm) несёт четырёхсимвольный код – cenc или cbcs, – объявляющий применённый рецепт. Плеер читает его первым, чтобы решить, может ли вообще играть поток.

Бокс шифрования дорожки (tenc) несёт настройки шифрования по умолчанию для дорожки, включая default_KID – идентификатор ключа. KID – это не сам ключ; это 128-битное имя ключа, как номер ячейки в камере хранения. Один и тот же default_KID общий для всех трёх систем DRM, и каждая использует его, чтобы запросить настоящий ключ у своего сервера лицензий. Как говорит стандарт, системы DRM «поддерживают идентификацию ключа расшифровки через хранимые идентификаторы ключей (KID)», но «как именно каждая система DRM защищает и находит ключ, идентифицируемый KID, оставлено на DRM-специфичный метод». Называть ключ в открытую безопасно; сам ключ в файле не лежит никогда.

Бокс шифрования сэмплов (senc) несёт векторы инициализации по каждому сэмплу – те самые стартовые числа, нужные каждому зашифрованному сэмплу, – и, где применимо, карту того, какие диапазоны байтов в каждом кадре открыты, а какие зашифрованы.

Бокс заголовка системы защиты (pssh) – тот, что и делает multi-DRM реальностью. Каждый бокс pssh несёт приватные данные одной системы DRM, помеченные её известным SystemID. Один файл может нести несколько – один для Widevine, один для PlayReady, один для FairPlay – и «один файл может быть построен так, чтобы воспроизводиться несколькими системами ключей и DRM, включением ProtectionSystemSpecificHeaderBox для каждой поддерживаемой системы». При воспроизведении устройство сканирует боксы pssh, находит тот, что соответствует системе, с которой оно родилось, игнорирует остальные и использует его, чтобы получить ключ, названный в default_KID. (В современном DASH этот заголовок всё чаще доставляют в манифесте, а не в файле, ради операционной гибкости, но роль та же.)

Свяжите всё одной фразой, которую можно нарисовать на доске: бокс schm говорит, какая схема, бокс tenc называет ключ через default_KID, бокс senc хранит IV, а по одному боксу pssh на систему позволяет Widevine, PlayReady и FairPlay найти каждой свою дверь к одному и тому же запертому контенту. Это и есть Рисунок 1, теперь во всех деталях.

Как плеер проверяет до того, как зайдёт: EME и `encryptionScheme`

Остаётся один практический вопрос: как веб-плеер узнаёт заранее, способно ли стоящее перед ним устройство вообще прочитать cbcs? Ответ – браузерный интерфейс Encrypted Media Extensions (EME), стандарт W3C, который позволяет плееру договариваться с DRM, не зная внутренностей каждой системы. EME расширили полем encryptionScheme, чтобы плеер мог заранее спросить устройство: «поддерживаешь cbcs?» (или cenc) и получить «да» или «нет» до того, как решит, что грузить. Это позволяет одному плееру адаптироваться: спросить схему, затем запросить подходящий поток. Полное согласование DRM в браузере – модуль расшифровки, реальность по браузерам – тема статьи Encrypted Media Extensions и браузерный DRM-стек. Для решения о шифровании вывод такой: проверка возможностей существует, поэтому грамотно сделанный плеер никогда не гадает.

Частая ошибка: шифрование только по `cenc`, которое ломает Apple

Самая дорогая ошибка во всей этой области – тихая, потому что проходит все тесты, которые гоняет команда, – пока не доберётся до устройства Apple. Команда шифрует каталог старой счётной схемой cenc, подтверждает воспроизведение на Android и Windows и выпускает. Затем каждый iPhone, iPad, Mac и Apple TV показывает чёрный экран, потому что FairPlay не читает cenc, а запасного варианта нет. Сбой невидим в лаборатории из Chrome и Android и всплывает, только когда реальное устройство Apple – или реальный клиент – пытается играть. К этому моменту каталог уже зашифрован и в продакшене.

Лекарство – правило, к которому ведёт вся статья: стандартизируйтесь на cbcs с первой же задачи упаковки. Один ассет cbcs обслуживает FairPlay, Widevine и PlayReady вместе. Если – и только если – нужно поддержать конкретный хвост старых устройств без cbcs, добавьте вариант cenc как осознанный, задокументированный запасной, но не как умолчание, бросающее Apple. И протестируйте на хотя бы одном реальном устройстве из каждой экосистемы, прежде чем считать упаковку готовой; схемы не взаимозаменяемы, и единственный способ убедиться – нажать «play» на «железе» всех трёх систем.

Вторая, помельче, ошибка – небрежно смешивать схемы внутри одного потока. Руководства по совместимости прямы: внутри набора взаимозаменяемых уровней качества каждый уровень должен использовать одну и ту же схему, а клиенты не должны пытаться играть контент cenc и cbcs одновременно. Если вы предлагаете обе схемы, предлагайте их как две полные, равные альтернативы, а не как смесь внутри одной. Ваш упаковщик это обеспечивает при верной настройке; сбой всплывает, только когда кто-то правит манифест вручную.

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

Выбор схемы шифрования – одна строка конфигурации, которая решает, играет ли каталог на любом экране или тихо отказывает на трети из них, и неверный выбор всплывает только в продакшене, на самых трудных для теста устройствах. Фора Софт с 2005 года создаёт ПО для видеостриминга, OTT/Internet TV, e-learning и телемедицины – 250+ выпущенных проектов для 400+ клиентов, – и правильный Common Encryption проходит через всю эту работу: стандартизация каталога на схему cbcs в CMAF, чтобы один зашифрованный мастер обслуживал Widevine, PlayReady и FairPlay; настройка сигнализации schm/tenc/senc/pssh, чтобы каждое устройство находило свой путь к лицензии по общему default_KID; решение, когда запасной cenc стоит своего хранения, а когда это балласт; и проверка воспроизведения на реальном «железе» всех трёх экосистем до релиза. Когда медиакомпании нужна защита, работающая с первого раза по всей матрице устройств – без двойного шифрования и хранения каталога, – именно эту инженерию на уровне схем мы и приносим.

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

• Common Encryption (ISO/IEC 23001-7) даёт открыть один зашифрованный файл и Widevine, и PlayReady, и FairPlay.
• Реально применяются две схемы: cenc (AES, режим счётчика, полностью) и cbcs (AES, режим сцепления, паттерн 1:9).
• Схемы не взаимозаменяемы – устройство читает только тот рецепт, что понимает его DRM.
• FairPlay принимает только cbcs; современные Widevine и PlayReady – обе, поэтому cbcs обслуживает все три.
• Стандартизируйтесь на cbcs в CMAF; добавляйте копию cenc только под конкретный хвост старых устройств.
• Pattern-шифрование (1:9) снижает работу на расшифровку примерно вдесятеро, делая 4K дешёвым в воспроизведении.

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

• Multi-DRM: один воркфлоу, любое устройство
• Лицензионные серверы и доставка ключей
• Эталонная архитектура DRM и защиты контента