Политика лицензий DRM: аренда, офлайн, защита выхода

TL;DR

Лицензия системы управления правами (digital rights management, DRM) несёт две вещи – ключ, который открывает видео, и политику: небольшой набор правил о том, как долго, на каком устройстве и через какой кабель контент можно показывать. Эти правила не случайны: это контракт студии, который ваш сервер лицензий переводит в поля, исполнять которые устройство обязано – аренда с окончанием срока, скачивание, работающее офлайн фиксированное время, поток 4K, который отказывается покидать устройство, пока кабель к телевизору не зашифрован, телефон без защищённого чипа с потолком в 480p. Эта статья простыми словами объясняет четыре рычага любой лицензии – время (подписки, аренда, покупка), офлайн (постоянная лицензия), output control (защита выхода, High-bandwidth Digital Content Protection, HDCP) и уровень безопасности (потолок разрешения) – и показывает, как их выражают Widevine, PlayReady и FairPlay. Ошибётесь в одну сторону – нарушите лицензию студии; ошибётесь в другую – закроете воспроизведение миллионам легальных зрителей.

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

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

Лицензия говорит больше, чем «да»

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

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

Держите в голове одно разделение из прошлых статей. В статье «CENC, CTR и CBCS» мы зашифровали каталог один раз, одни и те же байты для всех. Слой лицензий устроен наоборот: он под каждый запрос, и политика может отличаться для каждого зрителя и каждого устройства, даже для одного тайтла. Кто-то арендует, кто-то по подписке. Кто-то смотрит на телефоне с защищённым чипом, кто-то в браузере ноутбука без него. Зашифрованный файл идентичен; лицензия, которую получает каждое устройство, – нет. Эта гибкость и есть тема статьи.

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

Откуда берутся правила: контракт студии

Поля политики не начинаются с ваших инженеров. Они начинаются с фразы в лицензии на контент – «тайтлы раннего окна в Ultra HD должны быть защищены аппаратным DRM, HDCP 2.2 на канале и сессионным forensic watermarking» – и едут по цепочке, пока не станут числом в лицензии, которой устройство подчиняется.

Эталон для таких фраз – MovieLabs Specification for Enhanced Content Protection (ECP), написанная крупными студиями, чтобы дать каждой платформе общую цель защиты контента 4K, расширенного динамического диапазона и раннего релиза. Впервые опубликованная в 2013 году и обновлённая в v1.2 (2018) и v1.3, она требует, среди прочего, аппаратный корень доверия для хранения ключей DRM и защиты канала, HDCP 2.2 для контента, идущего на удалённый дисплей, защищённый медиаконвейер и forensic watermarking для самого ценного контента. Менее ценный или старый каталог несёт более лёгкие условия.

Цепочку стоит увидеть как четыре звена, потому что каждое принадлежит своей команде и каждое – место, где сборка ломается:

1. Пункт контракта – юрист владельца контента вписывает требование защиты в сделку.
2. Правило на сервере лицензий – ваша команда (или DRM-вендор) кодирует этот пункт как шаблон политики: «для этого тира тайтла, на этом классе устройств выдавать эти поля».
3. Лицензия – при воспроизведении сервер штампует реальные значения в лицензию: срок, флаг офлайна, требование HDCP, минимальный уровень безопасности.
4. Исполнение на устройстве – доверенный компонент устройства читает поля и подчиняется им или отказывается играть.

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

Рычаг первый – время: подписки, аренда и покупка

Самая привычная политика – это когда контент можно показывать. Бизнес-форм три, и каждая ложится на конкретные поля лицензии.

Подписка (SVOD). Доступ длится, пока подписка оплачена. Лицензия несёт абсолютный срок – фиксированную дату-время, после которой устройство обязано прекратить расшифровку. Пример Microsoft: подписчик с днём продления 15-го числа начинает смотреть 2 ноября; сервер выдаёт лицензию со сроком до 16 ноября и перевыдаёт свежую каждый раз при оплате следующего месяца. Срок намеренно короткий – дни, не месяцы, – чтобы отменённый аккаунт переставал работать вскоре после остановки платежей. (Бизнес-сторона этого – биллинг подписок и entitlement в Блоке 5; здесь мы только проставляем даты.)

Аренда (TVOD). Вот где ошибаются, потому что у аренды двое часов, а не одни. Первые часы – окно аренды: сколько после покупки можно начать смотреть, обычно 30 дней. Вторые часы – окно показа: сколько после первого нажатия play можно досмотреть, обычно 24 или 48 часов. Каноническая модель – «30 дней на старт, 48 часов на финиш». Двое часов существуют потому, что клиент покупает аренду во вторник, а смотрит в субботу, и студия готова дать ему месяц на начало, но лишь пару дней после того, как он начал.

Каждый DRM выражает двое часов разными именами:

• Widevine использует rental_duration_seconds (окно до первого запуска) и playback_duration_seconds (окно после начала показа), плюс license_duration_seconds для лицензии в целом. Это поля политики лицензии Widevine.
• FairPlay выдаёт для офлайн-аренды два ключа: первый несёт срок хранения (аренды) – например, 2 592 000 секунд, 30 дней, – и второй, получаемый при нажатии play, несёт срок показа – например, 86 400 секунд, 24 часа, – и замещает первый.
• PlayReady комбинирует политику Begin Date, абсолютную Expiration и политику Expiration After First Play, которая «указывает … что клиент обязан прекратить … расшифровку, если число секунд после первого показа» превысило значение.

Вот математика, выписанная вслух, потому что в ней сердце аренды. Допустим, вы продаёте аренду на 48 часов с окном старта 30 дней, клиент купил в 18:00 1 июня и впервые нажал play в 20:00 20 июня:

окно аренды  = 30 дней с покупки      → истекает 18:00 1 июля (последний момент НАЧАТЬ)
первый запуск = 20:00 20 июня          → внутри окна, разрешено
окно показа   = 48 часов с первого play → истекает 20:00 22 июня (последний момент ДОСМОТРЕТЬ)

Побеждает более ранний из «конец окна показа» и «конец окна аренды». Если бы клиент впервые нажал play в 17:00 1 июля – за час до закрытия окна аренды, – он всё равно получил бы полные 48 часов, потому что часы показа стартуют с первого play, а не с дедлайна аренды.

Покупка / electronic sell-through (EST). «Купить» значит играть бессрочно, поэтому лицензия не несёт никакого срока. Но «бессрочно» – ловушка для строителей: люди меняют телефоны и переустанавливают приложения, а DRM-идентичность устройства может смениться при перепровижининге. Указание Microsoft прямое – сервисы «должны быть готовы в любой момент перевыдать лицензии на купленный контент», потому что исходная лицензия привязана к устройству, которого может уже не быть. Спланируйте путь повторного скачивания с первого дня.

Под всеми тремя формами лежит правило безопасности: любая политика на основе времени надёжна ровно настолько, насколько надёжны часы устройства. PlayReady требует доверенные часы (Secure Clock или Anti-Rollback Clock), прежде чем клиент станет уважать срок, и рекомендует к каждому абсолютному сроку добавлять Begin Date, чтобы перевод часов назад не оживил мёртвую аренду. Если устройству нельзя доверить знание времени, ему нельзя доверить аренду.

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

Рычаг второй – офлайн: постоянная лицензия

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

Вспомните из статьи «Лицензионные серверы и доставка ключей», что обычная онлайн-лицензия – это temporary в браузерном стандарте Encrypted Media Extensions (EME): она живёт в памяти и умирает с вкладкой, не оставляя секрета. Офлайн-лицензия – противоположность. Спецификация W3C EME определяет тип сессии persistent-license, чья лицензия и ключи «сохраняются … так, что их можно извлечь … даже после закрытия» – пишутся на диск, привязаны к origin, который их создал, и работают вообще без сети. Эта постоянная лицензия и есть механизм скачивания.

Компромисс точен и стоит одного предложения: постоянная лицензия – это осознанный секрет, записанный на чужой диск. Это цена офлайна, и она меняет, как вы ставите остальные рычаги. Отсюда три следствия:

• Включать нужно явно. Для Widevine «и устройство, и контент должны быть включены с офлайн-политикой»; булево can_persist должно быть установлено, а доверенный модуль расшифровки хранит лицензию в защищённом постоянном хранилище и отдаёт идентификатор, чтобы перезагрузить её позже. Офлайн никогда не по умолчанию – вы включаете тайтл в него.
• Сроки короче, обновление спланировано. Поскольку секрет лежит на диске днями, офлайн-окна аренды держат тесными, а лицензии проектируют обновляемыми, когда устройство в следующий раз выходит в сеть. Widevine даже несёт renewal_recovery_duration_seconds – окно отсрочки, в которое показ продолжается, пока обновление пытается, но не удаётся из-за проблем на бэкенде, – чтобы шаткая сеть не оставила платящего зрителя посреди фильма.
• Поведение клиента – отдельная тема. Как приложение качает сегменты, управляет хранилищем и удаляет истёкший контент – тема статьи «Офлайн-скачивание и воспроизведение» в Блоке 6. Эта статья владеет только лицензионной стороной: флаг персистентности и сроки. Их проектируют вместе.

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

Рычаг третий – output control: защита последнего метра

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

Это отдельный слой защиты, и это не DRM. Это High-bandwidth Digital Content Protection (HDCP) – система под управлением Digital Content Protection LLC, которая шифрует канал между источником (вашей приставкой, консолью или стиком) и дисплеем и отказывается отдавать картинку, пока устройство на том конце не докажет, что оно настоящий лицензированный дисплей, а не рекордер. Аналогия: DRM – это запертый сейф, где лежит фильм; HDCP – запечатанная труба со следами вскрытия, по которой фильм едет из сейфа к экрану, с охранником на каждом конце, проверяющим, что другой легитимен.

HDCP бывает версиями, и версия ложится на тир разрешения:

• HDCP 1.4 защищает Full HD (1080p) по HDMI; старая, широко поддержанная, с известными слабостями.
• HDCP 2.2 сделана для 4K Ultra HD, с более сильной криптографией и «проверкой локальности», которая замеряет время отклика между источником и дисплеем, чтобы пресечь ретрансляцию контента по сети. Эту версию MovieLabs ECP требует для 4K.
• HDCP 2.3 – новейшая, расширяет на очень высокие разрешения с обновлённой криптографией.

Лицензия – это то, как владелец контента требует тот или иной уровень. Каждый DRM выражает требование:

• PlayReady ставит значение Output Control for Uncompressed Digital Video – 100, 250, 270 или 300 (с допустимыми уровнями сжатого видео 400 и 500). На уровне 300 «клиент ОБЯЗАН задействовать HDCP на выходе HDMI». Если устройство не может задействовать HDCP, у него ровно два совместимых выбора: играть, но заблокировать этот выход (показать на внутреннем экране, погасить сигнал HDMI) или вообще не играть. PlayReady также несёт отдельные политики HDCP Type Restriction и Maximum Decode Resolution для тонкого контроля.
• Widevine несёт поле OutputProtection, чьё значение hdcp – это перечислимый минимум: HDCP_NONE, HDCP_V1, HDCP_V2, HDCP_V2_1, HDCP_V2_2, HDCP_V2_3 или HDCP_NO_DIGITAL_OUTPUT (запретить цифровой выход полностью) – плюс cgms_flags (COPY_NEVER, COPY_ONCE, COPY_FREE) для аналогового сигнала контроля копий.
• HLS, формат стриминга Apple, выставляет требование в самом манифесте. Атрибут HDCP-LEVEL в EXT-X-STREAM-INF (IETF RFC 8216, §4.3.4.2) сообщает плееру, что поток «может не проиграться, если выход не защищён» HDCP, и спецификация велит клиентам без защиты выхода не загружать такой поток. Точный, датированный нюанс: RFC 8216 (2017) определял только значения TYPE-0 и NONE; значение TYPE-1 добавили позже в преемнике спецификации HLS (rfc8216bis) – оно сигнализирует более строгое требование, что контент нельзя передавать на старые устройства HDCP 1.x. Если читаете «TYPE-1 есть в RFC 8216» – это ошибка версии.

Один межвендорный факт замыкает круг и подставляет многие команды: HDCP Type 1 поддерживается только начиная с HDCP версии 2.1, поэтому требование задействовать HDCP Type 1 «не получится на устройствах, поддерживающих лишь HDCP 2.0 или 1.4». Потребуете сильнейшую защиту канала – молча отсечёте каждый старый телевизор в своей аудитории.

В этом ловушка рычага, и она бизнесовая, а не техническая. Потребуете HDCP 2.2 на каждом потоке – защитите каталог 4K и заодно сгенерируете вал тикетов «не играет на моём ТВ» от всех, у кого 1080p-панель, купленная до 2015 года. Правильная позиция – требовать сильный канал только для того тира контента, которому он контрактно нужен, и мягко падать вниз (меньшее разрешение с более лёгкими правилами выхода) для всего остального.

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

Рычаг четвёртый – уровень безопасности: потолок разрешения

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

Механизм – уровень безопасности устройства, заданный в статье «Три системы DRM». В терминах Widevine L1 значит, что вся расшифровка и работа с ключами идут внутри аппаратного Trusted Execution Environment (TEE), невидимого хост-системе; L3 значит, что работа идёт в софте, без аппаратной изоляции, что куда легче атаковать. PlayReady несёт эквивалент как политику Minimum Security Level со значениями 150, 2000 или 3000 – лицензия привяжется только на клиенте этого уровня или выше.

Рычаг политики – ограничивать разрешение по уровню безопасности. Почти универсальное отраслевое правило: устройства только с софтовой защитой (Widevine L3) ограничены стандартным разрешением – обычно 480p, – а всё выше SD требует аппаратной защиты (L1). Важная тонкость, и точка, где большинство статей ошибаются: этот потолок – решение политики на сервере лицензий, продиктованное контрактом студии, а не жёсткий технический предел DRM. Сервер лицензий, видя устройство низкой безопасности, просто выдаёт лицензию на SD-рендишн (или политику, запрещающую HD-рендишны). PlayReady делает ту же идею явной политикой Maximum Decode Resolution. Соедините этот рычаг с остальными – и один тайтл рождает очень разные лицензии:

Это и есть итог всей статьи: один пункт контракта студии («4K только на аппаратном DRM с HDCP 2.2 и водяным знаком») становится четырьмя согласованными полями – уровень безопасности, потолок разрешения, минимум HDCP, флаг водяного знака – собранными заново под каждое устройство в момент выдачи лицензии. (Сам водяной знак – это forensic watermarking, следующий слой защиты за лицензией.)

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

Один запрос, одна политика: как это собирается

Отступим – и четыре рычага окажутся не отдельными переключателями, а собранными вместе, под каждый запрос, сервером лицензий. Когда устройство просит ключ, сервер отвечает на три вопроса и перемножает ответы в одну политику:

1. Что требует контент? Из тира тайтла в каталоге и контракта студии – правила в духе MovieLabs.
2. Чему можно доверить это устройство? Из самого запроса лицензии – уровень безопасности, поддерживаемый HDCP, проверка.
3. За что заплатил этот пользователь? Из вашего сервиса прав – подписка, аренда с её двумя часами или покупка.

Пересечение – это лицензия. Новинка, в аренде, на защищённом телефоне по Wi-Fi получает: 48-часовое окно показа, онлайн (temporary) лицензию, разрешённый 4K, требование HDCP 2.2, включённый водяной знак. Тот же фильм, та же аренда, в браузере старого ноутбука получает: то же 48-часовое окно, но потолок 480p и без требования HDCP, потому что канал его не несёт. Зашифрованные байты не менялись. Менялись только правила.

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

Частые ошибки

Короткий полевой справочник по сбоям, которые мы видим чаще всего при проектировании политики лицензий:

• Одни часы для аренды. Поставить только дату окончания и забыть окно показа – и клиент, начавший на 29-й день, получит час, а не обещанные 48. Всегда ставьте и окно аренды, и окно показа.
• Длинные необновляемые офлайн-лицензии. Выдать постоянную лицензию с долгой жизнью, «чтобы скачивания работали», – значит оставить рабочий ключ на диске куда дольше, чем разрешает владелец контента. Держите офлайн-сроки короткими и требуйте обновления.
• Максимализм по HDCP. Требовать HDCP 2.2 на каждом потоке «для спокойствия» и утонуть в тикетах от зрителей со старыми 1080p-телевизорами. Сопоставляйте требование канала тиру контента.
• Забыть о доверенных часах. Уважать срок на устройстве, чьи часы можно перевести назад, – и «аренда» никогда по-настоящему не кончится. Требуйте доверенные часы и к каждому сроку добавляйте дату начала.
• Нет пути перекачивания для покупок. Считать «покупку» одноразовой лицензией и бросать клиентов при смене телефона. Стройте перевыдачу с первого дня.
• Ограничивать разрешение в плеере, а не в лицензии. Доверять приложению «просить только SD на слабых устройствах» – обходится тривиально. Потолок разрешения обязан быть политикой, выданной сервером.

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

Платформы, которым нужна точность политики, – это те, что работают на масштабе: OTT/Internet TV-сервис, запускающий каталог студии на телефонах, в браузерах, на смарт-ТВ и стиках, где одно слишком строгое правило множится в тысячи неудачных воспроизведений, а одно слишком мягкое проваливает аудит безопасности. Фора Софт строит видеостриминг, OTT/Internet TV и другие системы защищённого видео с 2005 года – 250+ проектов для 400+ клиентов за 20+ лет – и этот опыт лежит в неброском среднем звене цепочки: превратить контракт владельца контента в шаблон политики сервера лицензий, который проходит ревью студии и всё же играет на длинном хвосте реальных устройств, которыми ваша аудитория владеет на самом деле. Мы вендор-нейтральны к тому, какой multi-DRM-сервис выдаёт лицензии; значимая инженерия – это проектирование политики вокруг него.

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

• Лицензия DRM – это ключ плюс политика: правила времени, офлайна, выхода и безопасности.
• Контракты студий (MovieLabs ECP) становятся шаблонами сервера, полями лицензии, исполнением на устройстве.
• У аренды двое часов: окно, чтобы начать, и отдельное окно, чтобы досмотреть.
• Офлайн – это постоянная лицензия, осознанный секрет на диске; держите сроки короткими и обновляйте.
• HDCP защищает кабель, не файл; требование слишком высокой версии отсекает старые ТВ.
• Уровень безопасности задаёт потолок разрешения политикой сервера – L3/софт ограничен SD, не техническим пределом.

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

• Лицензионные серверы и доставка ключей – как ключ (и эта политика) попадают на устройство.
• Офлайн-скачивание и воспроизведение – клиентская сторона постоянной лицензии.
• Forensic watermarking: отследить утечку – слой защиты за лицензией.