Multi-DRM: один воркфлоу, любое устройство

Кратко

Multi-DRM – это стандартный современный способ защитить стриминговый каталог сразу для всех экранов: вы шифруете видео один раз, а затем выдаёте каждому устройству лицензию Google Widevine, Microsoft PlayReady или Apple FairPlay – в зависимости от того, с какой системой защиты оно родилось. Страх «три системы DRM стоят втрое дороже» неверен, потому что все три используют один слой шифрования – схему cbcs из Common Encryption (ISO/IEC 23001-7), упакованную в CMAF, – и различаются лишь лицензией, выдаваемой при воспроизведении, так что хранение и кодирование не утраиваются. Кусок, благодаря которому один шаг упаковки обслуживает все три системы, – это стандартизированная передача ключей от вашего поставщика DRM упаковщику, заданная форматом DASH-IF CPIX и реализованная такими API, как AWS SPEKE, чтобы упаковщик зашифровал один раз и записал сигнализацию, нужную всем трём системам. Эта статья простыми словами объясняет, что такое multi-DRM, как воркфлоу «зашифровать один раз – лицензировать многократно» собирается от начала до конца и как решить, покупать сервис multi-DRM или строить слой защиты самим.

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

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

Это статья-хаб нашего блока про защиту контента. Она предполагает, что вы уже знаете модель угроз из материала зачем нужен DRM и что он на самом деле защищает и реальность устройств из трёх систем DRM: Widevine, PlayReady, FairPlay. Если вы ещё не нарисовали карту «устройство → DRM», начните с неё; здесь мы превращаем эту карту в единый рабочий пайплайн.

Задача, которую решает multi-DRM, в одном абзаце

Вспомним факт, который задаёт всю конструкцию, установленный в статье про три системы DRM: защита контента – это не одна технология, а три конкурирующие, и каждую владеет платформенная компания и встраивает в собственные устройства. Google Widevine покрывает Android, Chrome и большинство смарт-ТВ и стримерских стиков; Microsoft PlayReady – Windows, Xbox и большую долю ТВ и приставок; Apple FairPlay – Safari, iPhone, iPad, Mac и Apple TV, и больше ничего, потому что Apple не лицензирует его никому. Ни одна система не дотягивается до каждого экрана, и пробелы – глухие стены. Значит, платформа, которая хочет охватить всех, обязана удовлетворить все три. Эта статья отвечает не на вопрос «какие системы вам нужны» – это уже сказала карта устройств, – а на вопрос «как обслужить все три, не строя, не храня и не оплачивая всё в трёх экземплярах». Ответ – multi-DRM.

Что на самом деле означает multi-DRM: зашифровать один раз, лицензировать многократно

Начнём с простого определения, потому что «multi-DRM» часто употребляют размыто. Технология, которая не даёт копировать премиальное видео, называемая управлением цифровыми правами (digital rights management, DRM), обычно привязывает устройство к системе одного вендора. Multi-DRM – это практика защиты одного каталога так, чтобы его могли воспроизвести все три вендорские системы – Widevine, PlayReady и FairPlay, – шифруя видео один раз и выдавая ту лицензию, которую понимает пришедшее устройство. Фраза, которую стоит пронести через всю статью, – зашифровать один раз, лицензировать многократно.

Почему это работает, опирается на разделение, которое пропускают почти все статьи в духе «собери клон Netflix», – поэтому сделайте его центром своей модели. У защищённого потока два отдельных слоя:

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

Представьте один запертый ящик с вашим каталогом и три по-разному выточенных ключа – по одному на каждую марку замка, которой пользуются устройства мира. Ящик вы строите один раз. Меняется лишь то, какой ключ вы выдаёте на входе. Вы не строите три ящика и не кладёте внутрь три копии каталога. Эта картинка – один ящик, три ключа – и есть multi-DRM, и именно поэтому страх стоимости неуместен: вы платите за один ящик плюс небольшую плату за каждую выточку ключа, а не за три каталога.

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

Общий слой шифрования: одна схема, один контейнер

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

• cenc шифрует видео алгоритмом AES в режиме счётчика (AES-CTR).
• cbcs шифрует его алгоритмом AES в режиме сцепления блоков с повторяющимся паттерном (AES-CBC).

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

Частое предупреждение, которое вам встретится, заслуживает точной поправки, потому что ошибка здесь гонит лишние расходы. Многие вендорские гайды категорично заявляют, что multi-DRM «обязан хранить две зашифрованные копии – cenc для Widevine и PlayReady, cbcs для FairPlay». По стандарту и текущей поддержке вендоров это верно лишь тогда, когда в вашем списке устройств есть старые клиенты, появившиеся до поддержки cbcs. Для современной целевой аудитории один ассет cbcs обслуживает все три, а вторая копия cenc – необязательный запасной вариант для legacy-«хвоста», а не требование. В любом случае число, которое никогда не меняется, – самое важное: вы никогда не делаете три зашифрованные копии, по одной на DRM, и никогда не перекодируете видео под каждую систему. Глубокая механика двух схем – зачем нужен паттерн в cbcs и как произошла конвергенция – тема статьи CENC, CTR и CBCS: common encryption простыми словами; для воркфлоу запомните одно правило: стандартизируйтесь на cbcs.

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

Один шаг упаковки: как ключи попадают к упаковщику

Вот часть, которая превращает «зашифровать один раз» из лозунга в реальный пайплайн, и здесь статья идёт глубже листиклов. Чтобы зашифровать каталог, компонент, который пакует ваше видео, – упаковщик (иногда это делает энкодер), – нуждается в контентных ключах и специфической для каждого DRM сигнализации, по которой система узнаёт свои лицензии. Эти ключи приходят от поставщика ключей DRM (вашего сервиса multi-DRM или собственного сервера ключей). Вопрос: как поставщик ключей передаёт упаковщику ровно нужные ключи и сигнализацию так, чтобы это работало с любым упаковщиком и любым вендором DRM? Если бы каждая пара требовала кастомной интеграции, multi-DRM был бы кошмаром проводки.

Индустрия решила это стандартным форматом документа для передачи: CPIX – Content Protection Information Exchange Format, спецификация DASH-IF. Документ CPIX – это небольшой структурированный файл, который несёт контентные ключи плюс данные каждой системы DRM: идентификаторы ключей (KID) и специфические для системы защиты заголовочные боксы (PSSH), которые записываются в манифесты и сегменты, чтобы клиент Widevine, PlayReady или FairPlay потом нашёл и запросил свою лицензию. Сам документ CPIX можно шифровать и подписывать, так что ключи защищены при передаче. Коротко: CPIX – это общий язык, на котором поставщик ключей DRM и упаковщик говорят, чтобы один шаг упаковки дал файлы, годные для всех трёх систем.

CPIX – это формат; нужен ещё способ запросить его в момент упаковки. Широко используемый для этого API – SPEKE, Secure Packager and Encoder Key Exchange, открытая спецификация, изначально от AWS, задающая «запрос/ответ» между энкодером или упаковщиком и поставщиком ключей DRM, с CPIX в роли структуры данных. Со SPEKE любой SPEKE-совместимый упаковщик (например, AWS Elemental MediaPackage или MediaConvert) может запросить ключи у любого SPEKE-совместимого поставщика, а новый SPEKE v2 (на CPIX 2.3) поддерживает даже разные ключи для разных дорожек – скажем, один для аудио, другой для видео. Практический эффект: вы можете соединить управляемый облачный упаковщик с вендором multi-DRM, и они работают «из коробки», потому что оба говорят на SPEKE/CPIX.

Запоминать эти аббревиатуры, чтобы вести платформу, не обязательно, но узнавать их на звонке с вендором стоит, потому что именно они делают «один воркфлоу» буквально правдой. Когда вендор DRM говорит «мы SPEKE-совместимы», он имеет в виду, что его сервер ключей встанет в ваш упаковщик без кастомного «клея». Это разница между интеграцией в неделю и интеграцией в квартал.

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

Что различается по устройствам: лицензия при воспроизведении

Когда каталог зашифрован один раз и лежит в вашей сети доставки (CDN), единственное, что меняется от зрителя к зрителю, – это лицензия, выдаваемая вживую, когда кто-то нажимает Play. В вебе плеер спрашивает у браузера, какая система защиты есть на устройстве, через стандартный браузерный интерфейс Encrypted Media Extensions (EME), спецификацию W3C. EME задаёт именованные key systems, которые плеер может запросить:

• com.widevine.alpha – Google Widevine
• com.microsoft.playready.recommendation – Microsoft PlayReady
• com.apple.fps – Apple FairPlay Streaming

Плеер предлагает свой список; устройство выбирает ту систему, что у него реально есть, через встроенный доверенный компонент расшифровки (Content Decryption Module, CDM). Затем плеер отправляет запрос лицензии этой системы на соответствующий endpoint вашего сервиса DRM, получает обёрнутый ключ – и воспроизведение начинается. Один плеер, написанный один раз под EME, передаёт три license endpoint и даёт каждому устройству выбрать своё. Полное рукопожатие и реальность поддержки по браузерам разобраны в Encrypted Media Extensions и браузерном DRM-стеке; нативная сторона по платформам – AVPlayer с FairPlay на iOS, ExoPlayer с Widevine на Android – в воспроизведении на iOS и Android. Общий поток того, как лицензионный сервер вообще доставляет ключ во всех трёх системах, – в статье лицензионные серверы и доставка ключей.

Заметьте, что произошло с вашей архитектурой. Слой медиа общий и статичный – зашифрован один раз, закэширован в CDN, одинаков для всех. Слой лицензий динамичный и дешёвый – несколько сотен байт на воспроизведение, выдаваемых сервисом. Именно это разделение и есть причина масштабируемости multi-DRM: обслужить миллион зрителей – это не миллион шифрований, а один каталог и миллион небольших вызовов лицензий.

Весь пайплайн за один проход

Сложите кусочки по порядку – и воркфлоу читается одной строкой слева направо:

1. Mezzanine-мастер – ваш высококачественный исходник входит в пайплайн.
2. Кодирование – он перекодируется в лестницу битрейтов (набор уровней качества) ровно так же, как и без DRM.
3. Запрос ключей – упаковщик запрашивает у поставщика ключей DRM контентные ключи и сигнализацию по SPEKE/CPIX.
4. Зашифровать один раз + упаковать – упаковщик шифрует сегменты один раз по cbcs, оборачивает их в CMAF и пишет манифесты HLS и DASH со встроенной сигнализацией Widevine, PlayReady и FairPlay.
5. Доставить – зашифрованные сегменты уходят в CDN, где кэшируются и отдаются как любой файл. CDN не видит ни одного незащищённого байта.
6. Воспроизвести – устройство запрашивает поток, берёт лицензию у соответствующего endpoint, и его CDM расшифровывает видео внутри защищённого железа.

Только шаги 3 и 6 специфичны для DRM, и оба берёт на себя ваш сервис DRM. Шаги 1, 2, 4 и 5 – это тот же пайплайн кодирования и доставки, который вы построили бы и так. Вот структурный вывод, который стоит повторить: multi-DRM добавляет к существующему пайплайну обмен ключами и вызов лицензии; он не добавляет второй или третий пайплайн.

Почему три DRM – не тройная стоимость

Теперь арифметика, потому что страх стоимости – главная причина, по которой команды переусложняют. Проговорим вслух.

Во-первых, хранение и кодирование не умножаются на три. Вы кодируете одну лестницу и храните одну копию, зашифрованную по cbcs и упакованную в CMAF. Допустим, каталог кодируется в 5 ТБ защищённых сегментов. С multi-DRM расчёт такой:

хранимых зашифрованных копий = 1   (cbcs CMAF, читают все три DRM)
хранение                     = 5 ТБ        (а не 15 ТБ)
лишних проходов кодирования на DRM = 0   (кодирование не зависит от DRM)

Если бы вы вместо этого строили по пайплайну на систему – ошибка, – вы хранили бы 15 ТБ и кодировали трижды ради защиты не сильнее, чем у версии с одной копией. Именно общий слой шифрования вас и спасает.

Во-вторых, слой лицензий – это маленькая плата за событие, а не за тайтл. Сервисы multi-DRM обычно берут либо плату за лицензию (за запрос), либо фиксированную месячную плату за платформу. Цена за лицензию – в диапазоне от доли цента до нескольких центов за выданную лицензию (актуальные ставки уточняйте у каждого вендора, они меняются). Разберём показательный случай: сервис на 100 000 подписчиков, каждый в среднем стартует 30 воспроизведений в месяц, и примерно одна лицензия выдаётся на сессию воспроизведения:

запросов лицензий / мес = 100 000 подписчиков × 30 просмотров = 3 000 000
стоимость при $0,0005 / лицензия = 3 000 000 × $0,0005        = $1 500 / мес

Полторы тысячи долларов в месяц за защиту каталога, который приносит шестизначную месячную выручку подписки, – доля процента, и она покупает защиту сразу на каждом устройстве. (Кэширование и персистентные лицензии тянут реальное число вниз, ведь не каждое воспроизведение требует свежей лицензии.) Суть – в порядке величины: слой защиты – погрешность округления против стоимости контента и CDN, если вы используете схему с общим шифрованием. Картина стоимости по всей платформе – где DRM стоит рядом с кодированием, egress и origin – в статье модель стоимости OTT.

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

Строить или купить слой DRM

Главное решение в multi-DRM не техническое, а «делать самим или купить», и почти для всех ответ – купить. Реалистичных варианта три, и различаются они тем, какую часть «сантехники» защиты вы держите сами.

Причина, по которой «купить» выигрывает у большинства, та же, по которой вы не держите собственный удостоверяющий центр: DRM – движущаяся мишень. Возможности вендоров, поддержка устройств и требования к сертификации меняются – сдвиг поддержки PlayReady на ТВ Samsung Tizen, разобранный в миграции PlayReady на Samsung 2026, – ровно тот тип изменения, который сервис впитывает за вас, а самостоятельный стек делает вашей проблемой. Вендор multi-DRM также держит отношения и сертификации с Google, Microsoft и Apple, которых требует индивидуальная интеграция. Среди заметных поставщиков multi-DRM – Axinom, EZDRM, PallyCon, BuyDRM (KeyOS), Verimatrix и castLabs, среди прочих; называйте несколько, датируйте сравнение и проверяйте актуальное покрытие устройств и цены перед выбором, потому что всё это меняется. Полная логика «делать vs купить» для всей платформы, а не только DRM, – в статье build, buy или собрать: OTT-платформа build-vs-buy.

Что лицензия может сказать – окна аренды, офлайн-воспроизведение, защита вывода (HDCP) и лимиты разрешения, привязанные к уровню безопасности устройства, – это политика, которую вы настраиваете поверх любого выбранного варианта, и она разобрана в политике лицензий: аренда, офлайн, output control и права. Купить сервис не значит отдать этот контроль; это значит не вести серверы, которые его применяют.

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

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

Две ошибки дают большую часть слитого бюджета и сломанных запусков в этой области, и назвать их – самый быстрый способ их избежать.

Первая – считать «три системы DRM» как «три пайплайна». Команда читает, что нужны Widevine, PlayReady и FairPlay, и ставит три отдельных пути кодирования-и-упаковки, утраивая вычисления и хранение. Лечение – модель из всей этой статьи: три системы используют один слой шифрования и различаются лишь лицензией. Стройте один пайплайн cbcs CMAF и выдавайте из него три типа лицензий. Если вы замечаете, что кодируете один тайтл больше одного раза по причинам DRM, – стоп: это сигнал, что вы построили неправильную форму.

Вторая – шифрование только cenc, которое молча ломает Apple. Команда шифрует всё старой схемой режима счётчика cenc, проверяет, что играет на Android и Windows, и запускается – а потом каждый iPhone, iPad и Mac показывает чёрный экран, потому что FairPlay вообще не читает cenc. Сбой невидим, пока кто-то не протестирует на реальном устройстве Apple, – поэтому он доживает до продакшена. Лечение – стандартизироваться на cbcs с первой же упаковки, чтобы один набор файлов обслуживал все три системы. Если нужно поддержать старый «хвост» только-cenc, добавьте вариант cenc как осознанный запасной – но не как умолчание, бросающее Apple.

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

Чем здесь помогает Фора Софт

Multi-DRM – это место, где охват устройств, контентные сделки и счёт за защиту должны сойтись в одном пайплайне, и неверная форма на старте всплывает как утроенный счёт за кодирование или каталог, не проходящий security review студии. Фора Софт строит ПО для видеостриминга, OTT/Internet TV, e-learning и телемедицины с 2005 года – 250+ выпущенных проектов для 400+ клиентов, – и задача «зашифровать один раз» проходит через эту работу: стандартизация каталога на cbcs Common Encryption и CMAF, чтобы один пакет обслуживал каждый экран, подключение поставщика ключей multi-DRM к упаковщику по SPEKE/CPIX, передача трёх license endpoint'ов плеерам в вебе, на мобильных и ТВ, и сопоставление политики лицензий уровню безопасности, которого требует каждая контентная сделка. Когда медиакомпании нужна защита, работающая с первого раза на всей матрице устройств – и без оплаты тройного кодирования и хранения каталога, – именно эта инженерия «зашифровать один раз, лицензировать многократно» и есть то, что мы приносим.

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

• Multi-DRM – это зашифровать один раз, лицензировать многократно: один каталог, три типа лицензий.
• Слой шифрования общий (cbcs Common Encryption, CMAF); по устройствам различается лишь лицензия.
• Стандартизируйтесь на cbcs – его требует FairPlay, а современные Widevine и PlayReady принимают.
• CPIX/SPEKE – стандартная передача ключей, дающая одному шагу упаковки обслужить все три системы.
• Хранение и кодирование не утраиваются; слой лицензий – небольшая плата за событие.
• Покупайте сервис multi-DRM, если вы не очень крупная платформа со строгим контролем и командой DRM.

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

• CENC, CTR и CBCS: common encryption простыми словами
• Лицензионные серверы и доставка ключей
• Эталонная архитектура DRM и защиты контента