Encrypted Media Extensions и браузерный DRM-стек

TL;DR

Encrypted Media Extensions (EME) – это стандартный интерфейс браузера (Recommendation W3C с 2017 года), который позволяет веб-плееру воспроизводить защищённое видео без плагина, передавая саму расшифровку отдельному компоненту – Content Decryption Module (CDM). EME – это не система управления правами (digital rights management, DRM); это общий адаптер, который соединяет ваш JavaScript-плеер с тем DRM, который уже встроен в браузер – Widevine в Chrome и Firefox, PlayReady в Edge, FairPlay в Safari, – а сам стандарт обязателен только в части тестового базиса под названием Clear Key. Поскольку ни один CDM не присутствует во всех браузерах, покрыть открытый веб можно лишь через multi-DRM: вы шифруете файл один раз с помощью Common Encryption и выдаёте лицензии Widevine, PlayReady и FairPlay из одних и тех же байтов. Эта статья простыми словами объясняет, что такое EME, из каких четырёх частей состоит браузерный DRM-стек, как именно устроен хендшейк лицензии по шагам, какую карту «браузер → CDM» вам нужно покрыть и как robustness-уровни решают, получит браузер 4K или 480p.

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

Если вы основатель, продакт-менеджер или CTO стриминга-новичок, браузер – это место, где большинство ваших зрителей нажмут «play», и при этом единственный экран, где DRM меньше всего под вашим контролем. CDM вы не пишете и установить его не можете; вы наследуете то, что даёт браузер и операционная система, а ваша задача – определить это, запросить нужный уровень защиты и направить лицензию. Ошибётесь в браузерном DRM-стеке – и сбой будет конкретным и видимым: у зрителя в Safari чёрный экран, потому что вы зашифровали только под Widevine, или каждый зритель в Chrome упёрся в стандартное разрешение, потому что вы запросили уровень безопасности, который их программный CDM не вытягивает. К концу вы сможете объяснить, что EME делает (и чего не делает), назвать, какой DRM живёт в каком браузере и почему, прочитать поток получения лицензии вслух и спроектировать multi-DRM веб-плеер, который играет везде. Это браузерный спутник статьи «Лицензионные серверы и доставка ключей», где разбиралось, как ключ доходит до устройства; здесь – браузерная машинерия, которая его запрашивает.

Задача, которую решает EME

Начнём с мира до EME – он объясняет всё про устройство EME. Десять лет назад браузер не мог сам воспроизвести защищённое видео студийного уровня. Защита жила в плагинах – Adobe Flash, Microsoft Silverlight – маленьких программах, вделанных в браузер, которые делали собственную расшифровку. Плагины были провалом с точки зрения безопасности и поддержки, и браузеры их убили. Осталась дыра: как браузеру играть премиальный контент, который по условиям контракта должен быть зашифрован, без плагина?

EME – это ответ. Формат, который позволяет веб-странице воспроизводить зашифрованное аудио и видео, общаясь с системой защиты контента, уже имеющейся на устройстве, называется Encrypted Media Extensions (EME); это стандарт W3C, расширяющий обычный HTML-элемент <video>. Название буквально: это расширение медиаэлемента. Браузер с его поддержкой может играть зашифрованное медиа; браузер без неё – просто не может, и это допустимо: EME необязателен для соответствия HTML.

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

Что такое EME – и чем он не является

Самая чистая аналогия – универсальный переходник для розеток. В поездке вы не переделываете электросеть каждой страны; вы везёте один переходник, который с одной стороны подходит к вашей вилке, а с другой – к местной розетке. EME – это такой переходник для браузерного DRM. Ваш плеер говорит на одном стандартном API со своей стороны; с другой стороны сидит тот DRM, который оказался в браузере. Напишите плеер один раз – и он работает против трёх разных систем защиты без трёх разных путей кода.

Чтобы использовать EME, нужны четыре названные вещи, и три из них к EME вообще не относятся:

• Key System – имя нужного вам DRM-механизма. W3C определяет Key System как «общий термин для механизма расшифровки и/или поставщика защиты контента», идентифицируемый строкой в обратной доменной форме. com.widevine.alpha – это Widevine; com.microsoft.playready – PlayReady; com.apple.fps – FairPlay; org.w3.clearkey – тестовый базис.
• Content Decryption Module (CDM) – софт (или железо), который реально делает работу. Определение W3C: CDM «это клиентский компонент, обеспечивающий функциональность, включая расшифровку, для одной или нескольких Key Systems». CDM проприетарен, поставляется с браузером или операционной системой, и вы его не пишете и внутрь не заглядываете.
• Сервер лицензий (ключей) – сервис, который раздаёт ключи, обёрнутые в политику. Это та часть, которую запускаете вы (или multi-DRM-вендор). Подробно – в статье «Лицензионные серверы и доставка ключей».
• Пакетировщик – апстрим-инструмент, который изначально зашифровал видео с помощью Common Encryption. См. «CENC, CTR и CBCS».

Один базис важен для тестов. EME требует, чтобы каждый совместимый браузер реализовал одну Key System без настоящего DRM за ней – Clear Key (org.w3.clearkey): спецификация говорит, что «только система Clear Key обязательна к реализации как общий базис». Clear Key позволяет зашифровать файл и воспроизвести его, просто передав ключ открытым текстом – без сервера лицензий, без согласования со студией. Он бесценен для проверки вашей EME-обвязки и бесполезен для защиты реального контента, потому что ключ виден странице. Никогда не путайте «мой Clear Key-демо играет» с «мой контент защищён».

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

Четыре части и кто владеет каждой

Точность во владении важна, потому что самая частая ошибка ментальной модели – думать, будто ваш плеер «расшифровывает» видео. Это не так. Пройдём стек от байтов внутрь.

Пакетировщик запускается один раз, апстрим, и выдаёт зашифрованные сегменты с помощью Common Encryption – стандарта ISO (ISO/IEC 23001-7), который позволяет одному зашифрованному файлу кормить любой DRM. Плеер – это ваш JavaScript: открытый движок вроде Shaka Player, hls.js или dash.js либо ваш собственный. Он тянет сегменты, отдаёт их видеоэлементу и оркеструет EME – но работает только с шифротекстом и непрозрачными сообщениями, никогда с пригодным ключом. EME API – стандартная поверхность браузера: объекты MediaKeys, MediaKeySystemAccess и MediaKeySession, которые вызывает ваш плеер. CDM – это прибор за этой поверхностью: проприетарный, проверенный браузером, делающий расшифровку (и часто декодирование) в защищённой зоне, куда ваш код не дотянется. Сервер лицензий – ваш, в сети, выдаёт ключи, обёрнутые в политику.

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

Как получают лицензию: хендшейк EME по шагам

Вот последовательность, которую задаёт спецификация, по порядку. Шагов кажется много, но каждый мал, и схема всегда одна: CDM создаёт запечатанный запрос, ваш плеер несёт его на сервер лицензий, ваш плеер несёт запечатанный ответ обратно.

1. Плеер пытается воспроизвести зашифрованное медиа. Он отдаёт сегменты элементу <video> (обычно через Media Source Extensions – парный API, поставляющий байты для адаптивного стриминга; как устроена эта часть – см. адаптивный битрейт-стриминг).
2. Браузер шлёт событие encrypted. Он прочитал из заголовка файла, что медиа защищено, и передаёт плееру метаданные шифрования (initData).
3. Плеер спрашивает, какой DRM доступен. Он вызывает navigator.requestMediaKeySystemAccess() со строкой Key System и конфигурацией (кодеки, robustness, тип сессии). Спецификация описывает это как вызов, который «запрашивает доступ к указанной Key System». Требуется secure context – EME работает только по HTTPS.
4. Плеер создаёт объект MediaKeys для доступной Key System и привязывает его к видеоэлементу через setMediaKeys(). Этот объект представляет живой экземпляр CDM.
5. Плеер открывает сессию через createSession(), получая MediaKeySession – объект, который, по словам спецификации, даёт «контекст обмена сообщениями с CDM» и представляет время жизни одной лицензии и её ключей.
6. Плеер просит у CDM запрос лицензии через generateRequest(), передавая initData из шага 2.
7. CDM шлёт событие message – запечатанный запрос лицензии с доказательством того, что этот CDM подлинный и доверенный.
8. Плеер отправляет это сообщение POST-запросом на ваш сервер лицензий (обычный fetch/XHR). Сервер проверяет права, собирает политику и возвращает лицензию.
9. Плеер передаёт ответ в CDM через update(). CDM распаковывает ключ.
10. CDM расшифровывает, видео играет. Расшифровка (и часто декодирование) происходит в защищённом тракте CDM; чистые кадры идут на экран, никогда обратно в ваш JavaScript.

Момент, на котором спотыкаются новички: всё между CDM и сервером лицензий непрозрачно для браузера и приложения. Ваш плеер видит, что сообщение является запросом лицензии, но не то, что внутри. Вы маршрутизируете запечатанные конверты. Поэтому и аутентификация – ваша задача, а не EME: кто имеет право на лицензию, вы решаете до шага 8, своим логином и сервисом прав.

// Минимальный поток EME (показан Clear Key; настоящий DRM меняет keySystem + запрос на сервер лицензий)
const config = [{
  initDataTypes: ['cenc'],
  videoCapabilities: [{ contentType: 'video/mp4; codecs="avc1.640028"',
                        robustness: 'SW_SECURE_DECODE' }]
}];

video.addEventListener('encrypted', async (e) => {
  const access  = await navigator.requestMediaKeySystemAccess('com.widevine.alpha', config);
  const mediaKeys = await access.createMediaKeys();
  await video.setMediaKeys(mediaKeys);

  const session = mediaKeys.createSession('temporary');
  session.addEventListener('message', async (ev) => {
    const license = await fetch('https://license.example.com/widevine', {
      method: 'POST', body: ev.message            // запечатанный запрос -> ваш сервер лицензий
    }).then(r => r.arrayBuffer());
    await session.update(license);                 // запечатанный ответ -> CDM
  });
  await session.generateRequest(e.initDataType, e.initData);
});

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

Карта браузерного DRM: какой CDM где живёт

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

Chrome и Firefox несут Widevine (Google). Microsoft Edge несёт и Widevine, и PlayReady (Microsoft), а на Windows может дотянуться до аппаратно-защищённого тракта PlayReady для 4K. Safari на macOS и iOS несёт FairPlay (Apple) и больше ничего. Нет браузера, в котором можно выбрать другой DRM, потому что CDM приварен к браузеру и операционной системе.

Прочтите последний столбец. Ни один браузерный CDM не покрывает открытый веб. Widevine не работает в Safari; FairPlay не работает в Chrome; PlayReady – это путь Microsoft. Поэтому единственный способ играть защищённое видео везде – поддержать все три, и это ровно паттерн multi-DRM: зашифровать сегменты один раз схемой cbcs Common Encryption, а затем выдавать лицензии Widevine, PlayReady или FairPlay из этих же байтов в зависимости от того, какой браузер пришёл. Полный паттерн и решение build-vs-buy за ним – в «Multi-DRM: один workflow, все устройства»; шифрование, которое это делает возможным, – в «CENC, CTR и CBCS». Браузерный стек – это почему multi-DRM обязателен, а не опционален.

Два браузер-специфичных факта экономят реальное время отладки. Первый: Safari требует серверный сертификат для FairPlay до любого обмена лицензиями – одноразовый шаг настройки, которого Widevine и PlayReady не требуют, и частая причина «работает везде, кроме Safari». Второй: старые версии Safari используют легаси WebKit-API (WebKitMediaKeys, key system com.apple.fps.1_0) вместо стандартного интерфейса EME, поэтому надёжный веб-плеер держит для них фолбэк.

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

Robustness и уровни безопасности: насколько крепок замок?

EME спрашивает не просто «можешь расшифровать?» Он позволяет спросить «можешь расшифровать достаточно безопасно?» Это строка robustness, и именно так правило владельца контента «4K только на аппаратно-защищённых устройствах» доходит до браузера.

Когда плеер вызывает requestMediaKeySystemAccess(), каждая capability может нести значение robustness. Спецификация описывает его прямо: «уровень robustness, связанный с типом контента. Пустая строка означает, что приемлема любая способность расшифровать и декодировать тип контента», и предупреждает, что «приложениям СЛЕДУЕТ указывать требуемые уровни robustness во избежание неожиданной несовместимости клиентов». Для Widevine значения идут от софта до полного железа: SW_SECURE_CRYPTO, SW_SECURE_DECODE, HW_SECURE_CRYPTO, HW_SECURE_DECODE и HW_SECURE_ALL. Они ложатся на уровни безопасности устройства из статьи «Три системы DRM»: софтовый robustness соответствует Widevine L3, аппаратное декодирование – L1.

Вот почему это важно, с арифметикой типичного правила студии вслух. Допустим, ваш контракт разрешает 4K только на аппаратно-защищённых клиентах и ограничивает всё остальное 480p. Зритель открывает ваш сайт в десктопном Chrome, чей CDM Widevine только программный (L3):

правило контракта   : 4K  -> нужен аппаратный robustness (HW_SECURE_DECODE / L1)
                       SD  -> софтовый robustness (SW_SECURE_DECODE / L3) подойдёт
CDM десктоп Chrome  : только софт (L3)
плеер просит 4K     : robustness 'HW_SECURE_DECODE'  -> нет L1-CDM -> запрос ПАДАЕТ
плеер просит SD     : robustness 'SW_SECURE_DECODE'  -> совпадает -> играет 480p
итог                : зритель в десктоп Chrome корректно получает 480p, а не чёрный экран

Урок – двусторонняя ловушка. Попросите больше robustness, чем браузер может дать, – запрос упадёт, чёрный экран для платящего зрителя. Попросите меньше, чем требует контракт, – можете отдать 4K софтовому CDM и провалить ревью студии. Правильный дизайн запрашивает, что браузер поддерживает, затем просит максимальный robustness, который реально нужен тиру контента, – а не фиксированный максимум на всё. Сам потолок разрешения – это решение политики сервера лицензий, подробно в «Политике лицензий», а не жёсткий лимит EME.

Свежее, датированное добавление стоит флага. Обновление EME 2024 года (опубликовано Media Working Group W3C как First Public Working Draft 18 июля 2024 года, на пути к будущему «EME 2») добавляет ровно две минорные фичи поверх Recommendation 2017 года: детекцию поддержки схемы шифрования (заранее спросить, поддерживает ли CDM cenc или cbcs) и возможность запросить статус ключа, связанного с политикой HDCP (метод getStatusForPolicy() – спросить «будет ли разрешён 4K по этому HDMI-каналу?» до попытки воспроизведения). Обе уменьшают догадки, но как у черновика поддержка в браузерах разнится; сверяйте перед тем, как полагаться.

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

Приватность, individualization и почему EME был спорным

Статья о браузерном DRM, пропускающая аргумент о приватности, неполна – он сформировал стандарт. EME стал Recommendation W3C в 2017 году вопреки публичным возражениям групп, включая Electronic Frontier Foundation (EFF) и Free Software Foundation. Двигали два опасения, и оба стоит понимать как инженеру.

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

Спецификация отвечает на второе опасение прямо, и формулировки показательны. EME определяет Distinctive Identifier и Distinctive Permanent Identifier и жёстко их ограничивает: «Distinctive Permanent Identifiers НИКОГДА не должны раскрываться приложению, даже в зашифрованном виде», а любой distinctive identifier, раскрытый странице, должен быть «зашифрован, уникален для origin и профиля и очищаем». Также требуется согласие: когда конфигурация нуждается в distinctive identifier, «любые проверки разрешений или взаимодействие с пользователем, такие как запрос согласия, ДОЛЖНЫ выполняться до разрешения промиса». Поэтому некоторые DRM-настройки вызывают браузерный запрос разрешения, а идентификаторы изолированы по сайтам. Спор не остановил EME – его несёт каждый крупный браузер, – но он дал стандарт с реальными ограничениями приватности внутри, и эта история полезна, когда стейкхолдер по приватности или юрист спросит, как ваш веб-плеер обращается с идентификаторами устройства.

Разбор на цифрах: покрыть веб одной кодировкой

Сложите части в расчёт, который решает бюджет веб-запуска: сколько кодировок, сколько DRM? Инстинкт – «три браузера, каждому нужен свой DRM, значит три зашифрованные копии». Это дорогой и неверный ответ.

покрыть браузеры   : Chrome + Firefox + Edge + Safari
нужные DRM         : Widevine (Chrome, Firefox, Edge) + PlayReady (Edge) + FairPlay (Safari) = 3 DRM
зашифр. копий      : 1   <- cbcs Common Encryption, шифруем ОДИН раз
серверы лицензий   : 3 эндпоинта лицензий (по одному на DRM), обычно один multi-DRM-вендор

Вы шифруете один раз схемой cbcs и выдаёте лицензии тремя путями. Одна задача пакетирования, три пути лицензий, каждый браузер покрыт. Эта экономия «зашифровал раз, лицензий много» – вся причина существования Common Encryption и multi-DRM, а карта браузерного DRM выше – доказательство, почему вам нужны все три пути лицензий, а не один.

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

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

• Кодировка под один DRM. Выпустить только Widevine и обнаружить в Safari чёрный экран. Карта браузеров не обсуждается: покройте Widevine, PlayReady и FairPlay.
• EME как DRM. Считать, что «мы используем EME» значит «мы защищены». EME – адаптер; защита – это CDM и политика лицензии. Демо на Clear Key не защищает ничего.
• Максимальный robustness везде. Просить HW_SECURE_ALL в десктопном браузере, чей CDM только программный, – и сделать экран платящего зрителя чёрным. Просите robustness под нужный тир контента, определив поддержку.
• Забыть серверный сертификат Safari. FairPlay требует шаг с сертификатом, которого нет у других; его пропуск даёт «работает везде, кроме Safari».
• Отдавать DRM по HTTP. EME требует secure context; API просто не запустится без HTTPS.
• Логика прав в плеере. Решать права в JavaScript, который любой зритель отредактирует. Кто получит ключ, решает сервер лицензий.

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

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

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

• EME – это стандартный браузерный адаптер для DRM, а не сам DRM.
• CDM делает расшифровку; он проприетарен и поставляется с браузером, не с вашим приложением.
• Clear Key – только для тестов, он не защищает ничего реального.
• Каждый браузер несёт один CDM: Widevine (Chrome/Firefox), PlayReady (Edge), FairPlay (Safari).
• Ни один CDM не покрывает веб, поэтому браузер вынуждает multi-DRM – шифруем раз, лицензий три.
• Robustness-строки задают уровень безопасности и тем самым разрешение; попросите слишком много – показ упадёт.

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

• Multi-DRM: один workflow, все устройства – почему карта браузеров вынуждает паттерн multi-DRM.
• Лицензионные серверы и доставка ключей – с чем говорит хендшейк EME.
• Три системы DRM: Widevine, PlayReady, FairPlay – уровни безопасности за robustness-строками.