Рекомендации по политикам лицензий

В этом разделе описаны рекомендации по программированию политик лицензий при использовании технологий PlayReady.

Использование BeginDate с EndDate

Одна из многих бизнес-моделей PlayReady поддерживает аренду содержимого — содержимое, которое можно использовать только в течение ограниченного периода (например, содержимое может использоваться до 15:00 15 октября 2018 г.). Это достигается путем выдачи клиентам лицензии PlayReady с указанием EndDate времени и даты истечения срока действия лицензии.

EndDate достаточно для создания лицензии на аренду; однако рекомендуется также включить BeginDate в лицензию. BeginDate указывает, что связанное содержимое не может использоваться до указанной даты. Сочетание BeginDate с EndDate является естественным импередированием для атак отката часов, где пользователи резервируют и восстанавливают все хранилище данных PlayReady, чтобы избежать событий отката часов.

Рассмотрим следующий пример.

• Дата — 08.01.18. Пользователь получает лицензию License1 для Content1. License1 имеет EndDate=08/30/18.

• Дата — 09.01.18. Пользователь получает лицензию 2 для Content2. License2 имеет EndDate=09/30/18.

• Пользователь создает копию хранилища данных PlayReady.

• Перед воспроизведением Content1 или Content2 пользователь возвращает часы 08.01.01.18, восстанавливает копию хранилища данных PlayReady. Можно воспроизводить оба фрагмента содержимого.

Теперь рассмотрим тот же базовый пример, но с BeginDates в лицензиях:

• Дата — 08.01.18. Пользователь получает лицензию License1 для Content1. License1 имеет BeginDate=08/01/18, EndDate=08/30/18.

• Дата — 09.01.18. Пользователь получает лицензию License2 для Content2. License2 имеет BeginDate=09/01/18, EndDate=09/30/18.

• Пользователь создает копию хранилища данных PlayReady.

• Перед воспроизведением Content1 или Content2 пользователь возвращает часы до даты до 08.01.18, восстанавливает копию хранилища данных PlayReady. Будет воспроизводиться только Content1.

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

В итоге при указании EndDate в лицензии PlayReady рекомендуется также включить BeginDate.

Задание значения BeginDate, которое работает для клиента

При добавлении BeginDate в лицензию рекомендуется задать его немного в прошлом для клиентов PlayReady версии 1 или 2. Причина заключается в том, что между сервером, создающим эту лицензию, и клиентом, получающим лицензию, может возникнуть небольшая разница в часах, а цель сервера заключается в том, что клиент может использовать лицензию, как только клиент получит его.

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

Типичным примером с клиентом PlayReady версии 2 может быть следующее:

1. Пользователь арендует содержимое в пятницу, 5 января 2018 года около 8 вечера, на Android телефоне под управлением приложения, построенного на PlayReady 2.5.

2. Приложение Android инициирует запрос лицензии на сервер лицензирования. Телефонные часы указывают 7:56, а часы сервера лицензирования — 8:00.

3. Сервер лицензирования получает запрос на лицензию, обнаруживает, что клиент является версией 2, и создает лицензию с помощью:

   • Воспроизведение вправо

   • Время начала = время локального сервера минус 5 минут = 5 января 2018 г. в 17:55

   • Время окончания срока действия, истечение срока действия после первого воспроизведения, другие правильные ограничения, такие как защита выходных данных

   4. Сервер лицензирования отправляет лицензию обратно клиенту.

   5. Клиент запускает воспроизведение. Телефонные часы по-прежнему 7:56pm и прошло дата начала лицензии, которая составляет 7:55 вечера, поэтому воспроизведение может начаться немедленно.

Типичным примером с клиентом PlayReady версии 3 может быть следующее:

1. Пользователь арендует содержимое в пятницу, 5 января 2018 года около 8 вечера, на компьютере Windows 10 под управлением приложения UWP.

2. Приложение UWP инициирует запрос лицензии на сервер лицензирования. Часы ПК указывают 7:56, а часы сервера лицензирования — 8:00.

3. Сервер лицензирования получает запрос на лицензию, обнаруживает, что клиент PlayReady версии 3 и проверяет значение часов клиента:

   • Если значение часов клиента не превышает значения часов сервера лицензий, превышающее 1 час, продолжайте и создайте лицензию.

   • Если нет, отклоните запрос лицензии и отправьте клиенту сообщение, чтобы запросить, чтобы часы были заданы в нужное значение.

4. Сервер лицензирования создает лицензию с помощью следующих компонентов:

   • Воспроизведение вправо

   • Время начала = время клиента, содержащееся в запросе лицензии = 5 января 2018 г. в 17:56

   • Время окончания срока действия, истечение срока действия после первого воспроизведения, другие правильные ограничения, такие как защита выходных данных

   4. Сервер лицензирования отправляет лицензию обратно клиенту.

   5. Клиент запускает воспроизведение. Часы пк по-прежнему 7:56pm и равны или мимо beginDate лицензии, которая составляет 7:56 вечера, поэтому воспроизведение может начаться немедленно.

Ограничения времени в лицензиях на подписку

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

В этом сценарии серверы лицензий PlayReady выдают конечные лицензии для каждого файла содержимого и одну корневую лицензию. Для доступа к содержимому PlayReady требуется как конечная лицензия, так и корневая лицензия (цепочка лицензий). Обе лицензии должны содержать действие, выполняеме для содержимого (например, воспроизведение), и обе лицензии должны быть действительными (не истекает и т. д.).

Так как существует только одна корневая лицензия, и, возможно, сотни или тысячи конечных лицензий для любого конкретного каталога контента, конечные лицензии должны включать очень мало ограничений (если таковые имеются), а корневая лицензия должна содержать ограничения времени и периодически обновляться (например, ежемесячно). Когда подписка завершится, сервер лицензирования должен выдавать только одну лицензию, и все содержимое будет обновлено с новой датой истечения срока действия. Если политика в конечных лицензиях содержит политику на основе времени, все конечные лицензии должны быть повторно выданы, чтобы предотвратить истечение срока действия содержимого, что будет большим требованием к производительности для серверов.

Вкратце, если срок действия содержимого должен истекать с помощью цепочек лицензий, то только корневая лицензия должна содержать политику на основе времени.