PlayReady подробно: DRM от Microsoft для 2026 года

TL;DR

PlayReady – это система Digital Rights Management (DRM) от Microsoft. На сегодня это единственный DRM, который работает на каждом классе устройств, куда ваш стриминговый продукт реально может прийти: Windows, Edge, Chrome на Windows 11, Xbox, Roku, любая крупная Smart TV-платформа, IPTV-приставки и растущий список Android STB. Именно поэтому PlayReady стоит рядом с Widevine и FairPlay практически в каждой OTT-инсталляции с премиальным контентом. Под капотом PlayReady оборачивает SOAP-XML-протокол выдачи лицензии вокруг контентного заголовка (WRMHEADER), который плеер несёт внутри MPEG-4 pssh-бокса. Сегменты шифруются теми же схемами ISO/IEC 23001-7 Common Encryption (cenc AES-CTR или cbcs AES-CBC), что и у Widevine с FairPlay, – значит, один CMAF-актив способен обслужить все три DRM. Клиенты делятся на три уровня безопасности: SL150 для разработки, SL2000 для «software-DRM» и SL3000 для аппаратно подкреплённых клиентов с Trusted Execution Environment, открывающих 4K и HDR. Текущий релиз – PlayReady 4.8 (апрель 2026); самое значимое серверное изменение за три года – counter-signed-сертификаты, появившиеся в 4.7 (август 2025).

Зачем это нужно

Если вы продаёте видео и ваша аудитория хоть в одной точке касается Windows, Xbox, Roku или любой крупной Smart TV-платформы – вы поставляете PlayReady. Safari не запускает PlayReady (там работает FairPlay Streaming), десктопный Chrome по умолчанию работает с Widevine, но как только аудитория задевает Microsoft Edge, Xbox, Smart TV в гостинице или – всё чаще – Chrome на Windows 11 с аппаратно-защищённым 4K, PlayReady становится единственным DRM, который ваш стрим воспроизведёт. Продакт-менеджер после этой статьи поймёт, почему «мы возьмём только Widevine на Smart TV» практически всегда не проходит ревью (Smart TV нативно несут PlayReady; Widevine поддерживается у разных вендоров и поколений непредсказуемо) и почему голливудские контракты на 4K в 2026-м по-прежнему пишут требование как «Widevine L1 ИЛИ PlayReady SL3000». Инженер уйдёт со схемой SOAP-обмена «на проводе», синтаксисом WRMHEADER, EME-строками key-system и четырьмя продакшен-ошибками, которые ломают релиз за неделю до запуска. Основатель получит конкретный ответ на «чем PlayReady отличается от Widevine?» – в двух словах: структурно похожи (оба делят клиентов на уровни безопасности, оба шифруют по Common Encryption, оба согласуют лицензию по HTTPS), коммерчески – разные (PlayReady шире там, где устройства идут от Microsoft или от чип-вендора с PlayReady TEE, а это сейчас почти каждый чипсет Smart TV на рынке).

Эта статья – четвёртая и последняя в мини-цикле о DRM: DRM 101: почему три системы и почему вы ставите все три – pillar; Common Encryption (CENC) подробно – упаковочный слой; Widevine: L1, L2, L3 – что они значат на самом деле – сторона Google; FairPlay Streaming подробно – сторона Apple. Этот текст – про Microsoft.

Что такое PlayReady на самом деле

Сначала определение, потом «на проводе». PlayReady – это формат контентного заголовка + протокол выдачи лицензии + клиентский Porting Kit + серверный SDK + многоуровневая лицензионная программа. Кусочки складываются так.

Контентный заголовок, называемый WRMHEADER, – это маленький XML-документ, который пакетизатор создаёт во время шифрования, а плеер считывает при воспроизведении. Он называет Key Identifier (KID) контента, алгоритм шифрования и опционально URL для запроса лицензии. Пакетизатор кладёт WRMHEADER внутрь pssh-бокса (Protection System Specific Header) в начале каждого MPEG-4 / fMP4 / CMAF-актива, а для HLS-доставок с Common Encryption – внутрь тега #EXT-X-SESSION-KEY.

Протокол выдачи лицензии – это обмен SOAP-over-HTTPS между клиентом и вашим лицензионным сервером. Клиент отправляет base64-кодированный challenge (XML-документ, подписанный клиентским сертификатом), сервер возвращает base64-кодированный response с одной или несколькими лицензиями; каждая лицензия – отдельный XML-документ, подписанный сервером. Клиент проверяет подпись, извлекает контентный ключ, и начинается расшифровка. Всё это умещается в один HTTPS POST.

Клиентский Porting Kit, или PlayReady Device Porting Kit (PK), – это исходники на C, которые Microsoft лицензирует производителям устройств, чтобы те реализовали PlayReady-стек внутри своего чипа. Microsoft не поставляет бинарного клиента; производитель портирует PK в свой Trusted Execution Environment (TEE), проходит аудит на robustness и выпускает устройство с зашитым клиентским сертификатом, у которого Security Level задан на этапе производства.

Серверный SDK, PlayReady Server SDK, – это .NET-библиотека, которую операторы лицензионных серверов (вы) встраивают в веб-сервис. По состоянию на апрель 2026-го есть две редакции: legacy .NET Framework для Windows-only-инсталляций и .NET 8.0 Core, которая идёт где угодно, включая Linux-контейнеры. Server SDK делает криптографическую работу: парсит challenge, проверяет подписи, подписывает лицензию. Бизнес-логика подключается к нему через небольшой набор хуков.

Лицензионная программа – это юридический слой. Microsoft лицензирует PlayReady двум разным аудиториям: client-имплементаторам (чип-вендоры, разработчики приложений, команды браузеров) и server-имплементаторам (стриминговые сервисы, поставщики лицензионных серверов). Обе стороны подписывают Compliance and Robustness-соглашение; клиентское соглашение включает SL3000 self-assessment, который Microsoft ввёл в апреле 2015-го, чтобы попасть под голливудские требования к 4K и HDR.

Из этого устройства следуют два вывода, и они формируют каждое решение, которое ваша команда принимает по PlayReady.

Первый. Охват PlayReady проходит по кремнию, а не по браузеру. Устройство работает с PlayReady, потому что его System-on-Chip несёт реализацию PlayReady TEE, а не потому, что ОС положила в комплект software CDM. Поэтому почти все Smart TV на рынке – Tizen, webOS, Vidaa, Android TV, Roku, Fire TV – воспроизводят PlayReady «из коробки»: чипсеты от MediaTek, Realtek, Amlogic, Broadcom и Sigma лицензируют PK и поставляют SL2000- или SL3000-клиент. По той же причине Widevine на Smart TV распределён куда неравномернее.

Второй. PlayReady на ПК означает Edge, а всё чаще – Chrome на Windows 11. Десктопный Safari PlayReady не запускает. Десктопный Firefox PlayReady не запускает. Десктопный Chrome исторически тоже не запускал PlayReady, но в конце 2024-го / начале 2025-го Chrome на Windows 11 (билд 22000 и выше, Chrome 140 и выше) получил поддержку SL3000 hardware-DRM через Edge-производный Content Decryption Module. Так что современный Chrome на свежей Windows-машине с совместимым GPU – теперь полноценная PlayReady SL3000-площадка. Старая EME-строка com.microsoft.playready по-прежнему работает для software-клиентов; новая com.microsoft.playready.recommendation – то, что нужно использовать для любого клиента, претендующего на 4K с аппаратной защитой.

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

Протокол «на проводе»: Challenge и Response

Запрос лицензии PlayReady – это двухсообщенческий HTTPS-обмен. Оба сообщения – SOAP-XML-документы, упакованные в base64-блоб; со стороны плеера они непрозрачные, но для инженера лицензионного сервера читаются полностью.

Сообщение 1 – Challenge. Когда плеер понимает, что нужна лицензия, он просит PlayReady-клиент сформировать challenge. Клиент собирает: WRMHEADER из pssh-бокса (чтобы сервер знал, какой KID искать); цепочку клиентских сертификатов (чтобы сервер проверил Security Level клиента); список поддерживаемых фич (чтобы сервер понял, готов ли клиент к многоалгоритмным лицензиям PlayReady 4.6 или умеет только старую одноалгоритмную форму); anti-replay nonce; и client-info-блок, в котором указаны ОС, версия PK и подсказки по политике. Клиент подписывает challenge приватным ключом устройства, base64-кодирует результат, и плеер делает HTTPS POST на ваш license URL – обычно с Content-Type: text/xml и SOAP-action-заголовком, называющим операцию (AcquireLicense, AcknowledgeLicense или JoinDomain).

Сообщение 2 – Response. Ваш PlayReady License Server получает challenge, передаёт его в Server SDK, и SDK:

1. Проверяет подпись клиента по цепочке сертификатов, доходит до root Microsoft и подтверждает, что сертификат не отозван (SDK сверяется с глобальным списком отзыва, который Microsoft публикует ежемесячно).
2. Читает WRMHEADER, чтобы узнать KID, и ищет соответствующий контентный ключ в вашей базе.
3. Считывает Security Level клиента из сертификата (150, 2000 или 3000), убеждается, что он соответствует политике, которой требует ваша бизнес-логика для этого контента.
4. Применяет бизнес-правила: авторизован ли пользователь, не закончилось ли окно проката, в разрешённой ли пользователь географии, нужно ли в лицензии HDCP-enforcement, защита выхода, persistence или ограничение по числу запусков.
5. Если все правила пройдены, SDK собирает одну или несколько лицензий (каждая – XML-документ, подписанный Server Deployment Certificate вашей команды, оборачивающий контентный ключ в session key, который клиент прислал в challenge), пакует их в response и подписывает конверт.

Response уходит обратно к плееру, плеер передаёт его PlayReady-клиенту, клиент проверяет подпись сервера по Server Deployment Certificate (Microsoft выдал его вашей команде при подключении к лицензионной программе), разворачивает контентный ключ, и начинается расшифровка. Как и в FairPlay и Widevine, контентный ключ никогда не появляется на проводе в открытом виде – он завёрнут в session key, который клиент сам прислал в challenge, а session key существовал только для этого одного response на этом одном устройстве.

Сокращённый SOAP-конверт с PlayReady-challenge выглядит так:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <AcquireLicense xmlns="http://schemas.microsoft.com/DRM/2007/03/protocols">
      <challenge>
        <Challenge xmlns="http://schemas.microsoft.com/DRM/2007/03/protocols/messages">
          <LA xmlns="http://schemas.microsoft.com/DRM/2007/03/protocols" Id="SignedData" xml:space="preserve">
            <Version>1</Version>
            <ContentHeader>
              <WRMHEADER xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader" version="4.3.0.0">
                <DATA>
                  <PROTECTINFO>
                    <KIDS><KID ALGID="AESCBC" VALUE="base64-KID"/></KIDS>
                  </PROTECTINFO>
                  <LA_URL>https://license.example.com/playready</LA_URL>
                </DATA>
              </WRMHEADER>
            </ContentHeader>
            <CLIENTINFO>...</CLIENTINFO>
            <RevocationLists>...</RevocationLists>
            <LicenseNonce>base64-anti-replay-nonce</LicenseNonce>
            <ClientTime>2026-05-25T12:00:00Z</ClientTime>
            <EncryptedData>...</EncryptedData>
          </LA>
          <Signature>...</Signature>
        </Challenge>
      </challenge>
    </AcquireLicense>
  </soap:Body>
</soap:Envelope>

License Server и Header Specification от Microsoft описывают побайтовый синтаксис целиком; пример выше – ориентир, а не спецификация.

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

WRMHEADER и PSSH-бокс

DASH-манифест с защитой PlayReady выглядит почти так же, как чистый. Различия – добавленный элемент ContentProtection, называющий PlayReady, и, если вы кладёте WRMHEADER не только в pssh-бокс внутри сегментов, а ещё inline в манифест, base64-кодированный pro-элемент с заголовком.

WRMHEADER – это единственный XML-документ, нужный каждому PlayReady-клиенту, чтобы начать запрос лицензии. Атрибут version идёт в формате MAJOR.MINOR.0.0; в активном использовании сегодня – 4.0.0.0, 4.1.0.0, 4.2.0.0 и 4.3.0.0. PlayReady Header Specification описывает синтаксис каждой версии целиком; практический ориентир такой:

• 4.0.0.0 – один KID, только AES-CTR. Используйте только если нужно поддерживать legacy SL2000-клиенты до 2017 года.
• 4.1.0.0 – добавляет custom data и расширенные атрибуты, по-прежнему один KID.
• 4.2.0.0 – добавляет поддержку нескольких KID в одном WRMHEADER. Обязательно для типичного multi-period DASH и multi-track CMAF, где у аудио и видео разные ключи.
• 4.3.0.0 – добавляет cbcs (ALGID="AESCBC") рядом с cenc (ALGID="AESCTR") и разрешает опускать CHECKSUM, когда алгоритм AESCBC (checksum – артефакт детерминированного counter-поведения AESCTR, в CBC он не нужен). Используйте эту версию, когда пакуете CMAF одним мастером для FairPlay-и-PlayReady-на-одном-активе.

Минимальный WRMHEADER 4.3.0.0 с одним AESCBC-ключом выглядит так:

<WRMHEADER xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader" version="4.3.0.0">
  <DATA>
    <PROTECTINFO>
      <KIDS>
        <KID ALGID="AESCBC" VALUE="base64-KID-16-bytes"/>
      </KIDS>
    </PROTECTINFO>
    <LA_URL>https://license.example.com/playready</LA_URL>
    <DS_ID>base64-Domain-Service-ID</DS_ID>
  </DATA>
</WRMHEADER>

Пакетизатор заворачивает WRMHEADER в PlayReady Object (маленький бинарный контейнер, описанный в спецификации), а PlayReady Object кладётся в pssh-бокс в начале MPEG-4-файла. SystemID pssh-бокса для PlayReady – фиксированный UUID 9A04F079-9840-4286-AB92-E65BE0885F95, и это та магическая константа, по которой каждый плеер узнаёт защищённый PlayReady-стрим. Плееры ищут этот бокс во всех DASH-сегментах, CMAF-фрагментах и HLS-fMP4-сегментах; найдя его с этим SystemID, передают содержимое своему PlayReady-клиенту, и acquisition стартует.

Для HLS-доставок, ориентированных на PlayReady (типично для Smart TV, которые предпочитают HLS вместо DASH), WRMHEADER ездит в плейлисте через:

#EXT-X-SESSION-KEY:METHOD=SAMPLE-AES,KEYFORMAT="com.microsoft.playready",KEYFORMATVERSIONS="1",URI="data:text/plain;charset=UTF-16;base64,<base64-WRMHEADER>"

Строка KEYFORMAT com.microsoft.playready – это магическая константа для PlayReady-on-HLS; плееры, которые её не понимают, пропускают тег и ищут другую DRM-строку в том же плейлисте. Так один HLS multi-variant-плейлист может нести FairPlay (com.apple.streamingkeydelivery) и PlayReady (com.microsoft.playready) рядом, а каждый плеер выберет ту строку, которую понимает его нативный DRM.

CMAF, CENC и режим шифрования, который объединил три DRM

Десять лет multi-DRM-экономика жила на дублировании: каждый премиум-стриминг пакетировал каталог дважды – один раз в cenc (AES-128 в counter-режиме, схема, которую потребляли PlayReady и Widevine) и один раз в cbcs (AES-128 в cipher-block-chaining с pattern, единственная схема, которую принимал FairPlay). Две копии каждого закодированного актива на каждой CDN-edge и пропорциональные расходы на трафик, хранение и пакетирование.

Это изменилось в октябре 2017-го с PlayReady 4.0, который добавил поддержку cbcs параллельно с cenc. С этого момента один CMAF-мастер, зашифрованный один раз в cbcs, можно было обернуть в DASH-манифест для PlayReady, в другой DASH-манифест для Widevine и в HLS-плейлист для FairPlay: три DRM, три манифеста, один набор зашифрованных сегментов на CDN. Экономика перевернулась. Хранение – пополам. Время пакетирования – пополам. Семьдесят пять процентов CDN-затрат, идущих на контент-egress, не изменились (зритель всё равно тянет один из трёх стримов), но оставшиеся двадцать пять процентов – хранение и пакетирование – резко упали. ISO/IEC 23001-7:2023 – зонтичный стандарт, который определяет обе схемы; ISO/IEC 23000-19 (CMAF) требует, чтобы каждый зашифрованный CMAF-track-sample использовал одну из двух схем CENC.

Подводный камень: каждый PlayReady-клиент, который потребляет cbcs, должен быть на PlayReady 4.0 или выше. Xbox One получил PlayReady 4.0 в прошивке 1709 (ноябрь 2017); современные Smart TV все на 4.0+; Windows 10 1709 и выше поддерживают cbcs. Устройства старше – небольшое меньшинство в 2026-м, но в long-tail-каталогах присутствует – потребуют cenc. Прагматичный дефолт 2026-го: «cbcs на всё новое; держите один legacy cenc-пакет, только если аналитика всё ещё показывает значимый трафик с устройств до 2017-го».

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

Уровни безопасности: SL150, SL2000, SL3000 – что они на самом деле значат

PlayReady делит клиенты на три Security Level. Каждый уровень – свойство клиентского сертификата, зашитое на этапе производства и видимое каждому лицензионному серверу, с которым клиент когда-либо разговаривает. Сервер может отклонить challenge, чей Security Level ниже политики MinimumSecurityLevel для контента, а клиент откажется привязываться к лицензии, у которой MinimumSecurityLevel выше его собственного уровня – симметричная защита с обеих сторон.

SL150 – разработка и тест. SL150 означает «ничто не закалено». Клиент может работать целиком в user-space-коде, ключи не защищены, сертификат устройства не привязан к железу. SL150 – это уровень, на котором разработчик плеера интегрируется с Porting Kit; собственная документация Microsoft по SL150 прямо пишет, что этот уровень «not suitable for commercial content». Лицензионный сервер в продакшене должен отклонять SL150-challenges, если они не идут из известного внутреннего IP-диапазона.

SL2000 – Software-DRM. SL2000 – это минимально допустимый уровень для коммерческого контента. Активы, клиентские секреты и контентные секреты защищены «программными или аппаратными средствами» – стандартное чтение: SL2000-клиент – это закалённая программная реализация с кодовой подписью, anti-debug и обфускацией, но без аппаратного Trusted Execution Environment. Десктопный Edge в software-режиме, старая EME-строка com.microsoft.playready без суффикса .recommendation, многие Android-STB без аппаратного DRM-TEE – всё это SL2000. SL2000 открывает SD и HD по стандартным голливудским соглашениям; 4K, HDR и прочий Enhanced Content – не открывает.

SL3000 – Hardware-DRM. SL3000 – уровень, которого голливудские контракты на 4K и HDR требуют. PlayReady-стек должен работать внутри Trusted Execution Environment (TEE) процессора – аппаратно изолированной области исполнения (ARM TrustZone, Intel SGX/TDX, Microsoft Pluton, AMD Platform Security Processor или проприетарного TEE чип-вендора: MediaTek, Realtek, Amlogic) – и внутри TEE одновременно работают и криптостек, и путь декодирования видео. Ключевой материал – приватные ключи, контентные ключи, производные ключи – никогда не покидает TEE; расшифрованные сжатые сэмплы не появляются в обычной системной памяти; путь decode→display использует protected video path, так что злоумышленник, получивший root, не сможет сделать screen capture. SL3000 также требует соответствия расширенному набору правил Compliance and Robustness, включая обновление от апреля 2015-го, которое ввело Enhanced Content Protection для 4K и HDR. SL3000 – единственный уровень, который сегодня открывает UHD-контент почти у каждого премиум-стриминга, с частичным исключением – Widevine L1 на Android – но стандартный 4K-пункт у студий гласит «Widevine L1 или PlayReady SL3000», так что даже Android-first-продукт всё равно поставляет PlayReady для остального флота устройств.

Пример того, как это раскладывается в коде политики лицензионного сервера:

if content.label == "UHD_4K_HDR":
    minimum_security_level = 3000
elif content.label == "HD_1080p":
    minimum_security_level = 2000
else:
    minimum_security_level = 2000

if client.security_level < minimum_security_level:
    return DenyLicense(reason="security_level_below_content_policy")

В реальных инсталляциях политика многослойнее – output protection (HDCP 2.2 для 4K, HDCP 1.4 для HD), persistence (часть 4K-аренды нельзя persist), ограничение по числу запусков и rental window живут рядом с проверкой Security Level, – но проверка Security Level всегда первый барьер. Response выставляет MinimumSecurityLevel в то же значение, и TEE клиента перепроверяет его при bind.

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

Что изменилось в PlayReady 4.6, 4.7 и 4.8

Эволюция PlayReady за последние четыре года была тихой, но содержательной. Три релиза важны для любой команды, которая сегодня строит или поддерживает лицензионный сервер.

PlayReady 4.6 (декабрь 2022) ввёл multi-algorithm Key Exchange-лицензии: один response может теперь нести несколько контентных ключей с разными алгоритмами – полезно, когда у контента один алгоритм для видео и другой для аудио, или когда трек меняет схему в середине периода. PlayReady 4.6 также мигрировал .NET Core Server SDK на .NET 6.0 и добавил IPackagingDataAcquisitionHandler для лицензионных серверов, которым нужно тянуть packaging-метаданные в момент acquisition.

PlayReady 4.7 (август 2025) добавил counter-signed (dual-signed) сертификаты – самое значимое серверное изменение за три года. Counter-signed-сертификат несёт две подписи: оригинальную подпись Microsoft и дополнительную подпись от назначенного counter-signer. Механизм даёт Microsoft путь катить authority, не аннулируя весь парк устройств: counter-signature можно добавить к существующим сертификатам, и устройству не нужно полностью перезапрашивать credentials. PlayReady 4.7 также мигрировал .NET Core Server SDK на .NET 8.0 (это long-term-support-релиз .NET через ноябрь 2026-го), добавил свойство LicenseResponse.ForceSignature, чтобы операторы могли force-sign не-persistent-лицензии для аудита, и зашил версию Server SDK в каждый response – клиентская телеметрия теперь может отслеживать, насколько оператор следует свежим релизам. Патч 4.7.8120 добавил Server Authorization Key history (сертификат сервера можно ротировать без рестарта сервиса) и закрыл проблему с Device Credentials Renewal после ротации TEE-ключа.

PlayReady 4.8 (апрель 2026) – текущий релиз на момент публикации. Каталог PlayReady Product Versions от Microsoft – авторитетный changelog; на верхнем уровне 4.8 инкрементален поверх 4.7 (продолжение шлифовки .NET Core Server SDK на .NET 8.0, обновление Device Porting Kit, без новых ломающих изменений wire-протокола). Команды, всё ещё сидящие на 4.5 или 4.6 в продакшене, должны запланировать апгрейд на 4.8, ориентируясь на LTS-milestone .NET 8.0 в ноябре 2026-го; те, кто на 4.7, могут переходить, когда удобно.

Типичные ошибки и продакшен-ловушки

Четыре продакшен-провала встречаются в PlayReady-интеграциях регулярно. Каждый из них хоть одну команду из тех, с кем я работал, обжигал.

Ловушка первая: поставлять стрим только с cenc на флот, в котором есть Smart TV. Smart TV несут PlayReady 4.0+ и нативно поддерживают cbcs; кодировать дважды (один раз в FairPlay-совместимый cbcs, один раз в PlayReady-совместимый cenc) – это удвоенная стоимость пакетирования без пользы. Фикс: кодировать один раз в cbcs, упаковать три манифеста (DASH для PlayReady, DASH для Widevine, HLS для FairPlay), направить каждый плеер на тот манифест, который понимает его DRM.

Ловушка вторая: использовать com.microsoft.playready вместо com.microsoft.playready.recommendation для EME-клиента, который хочет 4K на Chrome / Edge. Legacy key-system запирает вас в SL2000-эквивалентное поведение даже на SL3000-способном устройстве. Фикс: использовать com.microsoft.playready.recommendation и выставлять robustness в 3000 при согласовании capability в EME. Старые браузеры, не знающие .recommendation, мягко падают на legacy; новые открывают hardware-DRM. Issue dash.js #3852 – канонический трекинг для dash.js.

Ловушка третья: забыть проверять список отзыва клиентов на стороне сервера. Server SDK делает это автоматически, если вы ему даёте; некоторые команды отключают revocation-checks в dev и забывают включить обратно в проде. Итог – лицензионный сервер выдаёт ключи компрометированным устройствам, которые Microsoft уже отозвал, и это ровно тот режим отказа, на котором валится robustness-аудит. Фикс: никогда не отключать revocation-checks в проде; пусть SDK тянет ежемесячный список Microsoft и отклоняет challenges от отозванных сертификатов. (Статус revocation сертификата – одно из того, что голливудские аудиторы будут проверять по вашим логам доступа.)

Ловушка четвёртая: хардкодить SystemID и сломаться, когда спецификация съезжает. Почти – PlayReady SystemID не менялся с 2008-го и менять его никто не планирует. Но команды, которые жёстко зашивают его литералом в одном файле, потом перезашивают в другом (пакетизатор, парсер WRMHEADER на сервере, mock-плеер в тестах), в один прекрасный день обнаружат, что константа неправильна в одном месте и им приходится грепнуть три репозитория. Фикс: назвать константу один раз в общей библиотеке, импортировать везде. Полный PlayReady SystemID – 9A04F079-9840-4286-AB92-E65BE0885F95.

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

Фора Софт с 2015 года выпускает multi-DRM-стеки для OTT-, e-learning- и телемедицинских продуктов – на web, iOS, Android, Smart TV (Tizen, webOS, Vidaa), Roku и игровых консолях. PlayReady появляется практически в каждом запущенном нами продукте под Smart TV и Windows – в паре с FairPlay на Apple-устройствах и Widevine на Android. Мы прошли апгрейды SDK 3.0 → 4.0 → 4.5 → 4.7 на стороне сервера, консолидацию cenc → cbcs и миграцию на com.microsoft.playready.recommendation на стороне браузерных клиентов. В WebRTC- и видеоконференц-проектах PlayReady редко становится моделью защиты выбора (real-time-контент защищён DTLS-SRTP и контролем доступа на уровне сессии), но в OTT, обзорных VOD-разделах видеонаблюдения и broadcast-grade-вертикалях, где премиум-контент встречается с широким парком устройств, PlayReady – стандартная часть ответа.

PlayReady против Widevine против FairPlay: практическое сравнение

Pillar-статья DRM 101: почему три системы и почему вы ставите все три разбирает сравнение целиком. Таблица ниже – практический ориентир для решения.

Самая полезная строка таблицы – про схемы шифрования. Каждый современный DRM потребляет cbcs; как только вы это поняли, становится ясно, почему один CMAF-мастер и один выход пакетизатора обслуживают все три.

Главные выводы

• PlayReady – DRM, который нативно работает на Windows, Edge, Xbox и почти каждой Smart TV.
• Шифрование – ISO/IEC 23001-7 cenc (AES-CTR) или cbcs (AES-CBC, с 4.0).
• WRMHEADER 4.3.0.0 с AESCBC – дефолт 2026 для новых пакетных пайплайнов.
• SL3000 – аппаратный TEE-уровень, требуемый стандартным голливудским 4K-пунктом.
• PlayReady 4.7 добавил counter-signed-сертификаты и перевёл сервер на .NET 8.0.
• Один CMAF-актив в cbcs обслуживает PlayReady, Widevine и FairPlay вместе.

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

• DRM 101: почему три системы и почему вы ставите все три
• Common Encryption (CENC) подробно
• Widevine: L1, L2, L3 – что они значат на самом деле

CTA

• Поговорите со стриминг-инженером – 30-минутный звонок с нашим DRM-лидом.
• Посмотрите кейсы – multi-DRM OTT, телемедицина, Smart TV.
• Скачайте чек-лист по инсталляции PlayReady – однополосный ориентир по flow с сертификатами, политикам SL2000 / SL3000, выбору EME-key-system и четырём продакшен-ловушкам.