Упаковка и доставка содержимого
Базовая возможность PlayReady заключается в защите содержимого от несанкционированного использования. Для этого сначала необходимо зашифровать содержимое, а связанный заголовок PlayReady вставить в содержимое. Система, выполняющая эту операцию, является упаковщиком, также известным как шифратор, который иногда интегрируется с кодировщиком.
В этом разделе описываются различные способы шифрования и доставки содержимого с помощью PlayReady.
Упаковка содержимого PlayReady — шифрование и вставка заголовка DRM
Процесс шифрования ясного содержимого состоит из определения одного или нескольких ключей шифрования, используя эти ключи для шифрования байтов, составляющих само содержимое, и вставки заголовка DRM в содержимое (в файлах содержимого или в манифесте, если содержимое имеет одно).
Все зашифрованное содержимое, защищенное с помощью PlayReady, должно содержать заголовок PlayReady, вставленный в зашифрованный файл. Этот заголовок PlayReady используется клиентом PlayReady для поиска или получения лицензии на определенный фрагмент содержимого. Заголовок PlayReady состоит из XML- кода, закодированного в UTF-16. Он содержит идентификаторы ключей (KID), которые используются для шифрования содержимого, URL-адрес по умолчанию, который клиент будет использовать для получения лицензии, если другие не предоставлены, и любые пользовательские атрибуты.
Любой упаковщик, который упаковывает очищаемое содержимое, должен реализовать генератор заголовков PlayReady для создания заголовка и внедрения его в зашифрованное содержимое. Заголовок PlayReady должен быть реализован в соответствии со спецификацией заголовка PlayReady. Существует несколько способов создания генератора заголовков PlayReady в упаковщике:
- Разрабатывайте его самостоятельно на основе спецификации заголовка PlayReady.
- Используйте API пакета SDK для сервера PlayReady, который создает заголовок PlayReady.
- Используйте API Windows 10, создающий заголовок PlayReady.
Зашифрованное содержимое может содержать несколько заголовков DRM, включая заголовки PlayReady, а также сторонние заголовки DRM. Дополнительные сведения о том, как это работает, см. в разделе "Использование средств шифрования".
Тип содержимого
PlayReady можно использовать для защиты аудио- и видеосодержимого. Наиболее распространенными типами кодирования, используемыми с PlayReady, являются MPEG-4 AVC (H.264), стандарты H.265 H.265 с высокой эффективностью видеокодирования (HEVC) и стандарт AV1. PlayReady не ограничивается этими стандартами и может использоваться с любым форматом аудио и видео, поддерживаемым на клиентском устройстве.
PlayReady версии 1 и 2 позволяет создать защищенный пакет, содержащий содержимое, которое не ограничивается полезными данными аудио или видео. Эти пакеты, называемые конвертами, могут содержать такие файлы, как коллекция файлов данных и исполняемых файлов (например, приложение, распределенное по хранилищу приложений), рисунки (например, обои на экране) или электронные книги. Это содержимое упаковывается путем инкапсулирования файлов в конвертный файл, который можно расшифровать так же, как и аудио- и видеосодержимое.
Эти типы контента, отличные от аудио и видео, больше не поддерживаются в PlayReady 3.0 и более поздних версиях.
Средства шифрования
Корпорация Майкрософт не включает упаковщик в состав конечных результатов PlayReady. Вместо этого PlayReady предоставляет спецификации на основе общих стандартов шифрования для использования кодировщиками. Поэтому формат шифрования не является конкретным для PlayReady, а является функцией формата файла. Наиболее широко используемым сегодня форматом шифрования является стандартный формат ISO для шифрования ISO, ISO/IEC 23001-7.
По сути, можно создать собственный упаковщик или работать с любым типом шифрования открытый код (например, ffmpeg). Кроме того, вы можете работать с профессиональной компанией кодировщика, если вы хотите зашифровать содержимое с помощью PlayReady (например, Harmonic, Elemental, Ericsson, Wowza, Allegro). Службы мультимедиа Azure также предоставляет функциональность упаковки для четкого содержимого.
Использование средств шифрования
PlayReady поддерживает стандартный стандарт шифрования ISO IEC. Этот процесс такой же, как описано в разделе "Базовый процесс шифрования и лицензирования", за исключением заголовков, которые будут включены для других DRM, каждый из которых содержит полезные данные поля "Заголовок для конкретной системы защиты" (pssh), определенный с помощью SystemID этого DRM. Все эти заголовки будут иметь собственный синтаксис, указывающий KID или сведения, необходимые для доступа к ключам содержимого. И ключи содержимого для этого ресурса будут одинаковыми для всех DRM.
Использование ключей шифрования
Существует множество различных способов шифрования ресурсов. Самый простой из них зависит от сложности, которую вы хотите разработать в системе, и от потребностей службы.
Рассмотрим, например, ресурс адаптивной потоковой передачи, как показано на рисунке ниже. Он имеет четыре различных качества видео, одну звуковую дорожку и один подзаголовок. Он закодирован в сегментированных MP4-файлах с сегментами в 2,0 секунды. Это один ресурс, обслуживающийся в нескольких форматах в зависимости от того, что клиент предпочел бы воспроизвести. Smooth Streaming, HLS и DASH являются наиболее распространенными вариантами. Во время воспроизведения клиент (видеопроигрыватель) последовательно скачивает сегменты ресурса по сети, выбирая для каждого времени воспроизведения сегмент видео из адекватной видеодорожки, чтобы обеспечить максимально высокое качество воспроизведения, учитывая ограничения пропускной способности сети, скорость воспроизведения и другие ограниченные ресурсы, такие как возможности проигрывателя. Эта логика называется адаптивным потоковым воспроизведением, управляемым некоторыми эвристические правила, реализованными в проигрывателе.
Шифрование ресурса только одним ключом
Самый простой способ шифрования этих ресурсов — использовать один ключ содержимого для шифрования всего (обычно субтитры не шифруются — это не против какого-либо правила, но они обычно хранятся в ясном виде). Использование одного ключа содержимого упрощает жизнь для сервера лицензирования, так как сервер лицензирования должен доставлять один ключ {KID, CK}. Этот ключ обычно получается клиентом до воспроизведения.
Примечание
Клиенты PlayReady могут получать лицензии заранее или реактивно. Описание этих двух режимов см. на странице приобретения лицензий .
Шифрование ресурса с двумя ключами, присвоив одно самому высокому качеству
В последние годы было несколько усовершенствований, чтобы использовать несколько ключей для каждого ресурса, в основном обусловлено требованием разрешить только определенным клиентам с наивысшей надежностью использовать высокое качество содержимого. С появлением содержимого Ultra HD (4K) и с добавлением высокого динамического диапазона (HDR) для более высокого цветового содержимого было необходимо студии и службы, чтобы обеспечить наивысшее качество только на определенных клиентах, которые обычно имеют аппаратный DRM встроенный. В этом сценарии ресурс шифруется с помощью одного ключа содержимого {kid1, ck1} для всех дорожек, за исключением трека 4K, зашифрованного с помощью другого ключа содержимого {kid2, ck2}. Это означает следующее:
- Клиент, который может воспроизводиться только до full HD (а не 4K-трека), будет доставлена лицензия PlayReady, включая только {kid1, ck1}.
- Клиент, которому разрешено играть до 4K, будет доставлена лицензия PlayReady, включая {kid1, ck1} и {kid2, ck2}.
Используя эту дополнительную сложность, служба может гарантировать, что некоторые клиенты не смогут расшифровать 4K-дорожку, и что 4K-дорожка может быть зарезервирована только для клиентов, которым больше всего доверяет служба.
Шифрование ресурса с одним ключом на дорожку
Служба может иметь более сложную карту прав для принудительного применения. Некоторым клиентам, в зависимости от размера экрана, их надежности, выходных данных и их расположения, может быть разрешен доступ только к некоторым видеодорожкам, некоторым качествам видео и некоторым звуковым дорожкам. Чтобы обеспечить полную гибкость службы при применении произвольного набора ограничений в будущем, он может зашифровать ресурс с ключом содержимого, характерным для каждой дорожки. Например:
- Клиент, которому разрешено играть только 720p, будет доставлена лицензия PlayReady, включая {kid1, ck1}, {kid2, ck2} и {kidA, ckA}.
- Клиент, которому разрешено играть до 4K, будет доставлена лицензия PlayReady, включая {kid1, ck1}, {kid2, ck2}, {kid3, ck3}, {kid4, ck4} и {kidA, ckA}.
- Клиент, играющий в автономном режиме 4K версии ресурса (ранее скачанный), будет доставлена лицензия PlayReady, включая {kid4, ck4} и {kidA, ckA}.
Периодическое изменение ключей шифрования (ресурс с несколькими периодами) — смена лицензий
В некоторых сценариях служба хочет иногда изменять ключи шифрования, как правило, в границах программы. Например, линейная потоковая трансляция имеет несколько периодов с бесплатным доступом к содержимому, к которому должны иметь доступ все пользователи, за которым следует некоторое содержимое, ограниченное подписчиками. Изменение ключей шифрования на границах программы позволяет службе доставлять бесплатные ключи в воздух {KIDi1, CKi1} всем пользователям без каких-либо ограничений и доставлять ключи содержимого {kidi2, cki2} только подписчикам, которые успешно вошли в службу.
Обратите внимание, что эта смена лицензий не очень масштабируема: каждый раз при изменении ключей шифрования все клиенты запрашивают новые ключи шифрования с помощью собственного запроса лицензии. Это может привести к высокому пику запросов лицензий в системах с большим количеством клиентов.
Частое изменение ключей шифрования — смена масштабируемых ключей
В PlayReady существует расширенный механизм, называемый масштабируемым поворотом ключей (в отличие от смены лицензий). Этот метод сохраняет внедренное хранилище лицензий (ELS) в потоке фактического содержимого. В этом механизме ключ, используемый для шифрования самого сегмента A2, называется конечным ключом {kidA2, ckA2}, и доставляется в ELS сегмента A2, будучи зашифрованным с помощью отдельного ключа, который одинаков для всех сегментов track A, называемых корневым ключом {kidRA, ckRA}. Если вы знакомы с MPEG-2 TS и шифрованием Control Word, это аналогичный механизм, за исключением шифрования гораздо сильнее, а также более гибкий.
Предположим, что этот ресурс является линейным телевизором в прямом эфире. При попытке воспроизведения клиент находит kidRA в заголовке PlayReady манифеста потока и запрашивает лицензию на kidRA. Сервер лицензирования возвращает корневую лицензию для корневого ключа {kidRA, ckRA}. Затем клиент анализирует сегмент A1 и обнаруживает ELS в заголовке сегмента. Анализ этого ELS, он находит конечную лицензию {kidA1, ckA1} в этом ELS. Используя корневой ключ {kidRA, ckRA} и конечную лицензию {kidA1, ckA1}, он может получить значение ckA1, расшифровать и отобразить сегмент A1.
Функция смены масштабируемых ключей PlayReady чрезвычайно масштабируема, так как клиентам не требуется обращаться к серверу лицензий при каждом изменении ключей шифрования. При этом объем запросов лицензий остается наименьшим, так как клиенту требуется только одна корневая лицензия с сервера лицензий на поток или отслеживание. При необходимости ключи шифрования могут поворачиваться так же часто, как и каждый сегмент, обычно каждые две секунды.
