许可证策略的最佳做法

本部分介绍使用 PlayReady 技术时编程许可证策略的最佳做法。

将 BeginDate 与 EndDate 配合使用

PlayReady 支持的许多业务模型之一是内容租赁,内容只能用于有限的时间段 (,例如,内容可以使用到 2018 年 10 月 15 日下午 EST 5 点) 。 这可以通过向客户端颁发一个 PlayReady 许可证,并将 EndDate 设置为许可证过期的时间和日期。

EndDate 足以创建租赁许可证;但是,最好在许可证中包含 BeginDate。 BeginDate 指定在指定日期之前无法使用关联的内容。 BeginDate 与 EndDate 的组合是时钟回滚攻击的自然合成,用户可以备份和还原整个 PlayReady 数据存储以避免时钟回滚事件。

请看下面的示例:

  • 日期为 08/01/18 — 用户获取 Content1 的 License1。 License1 具有 EndDate=08/30/18。

  • 日期为 09/01/18 — 用户获取 Content2 的 License2。 License2 具有 EndDate=09/30/18。

  • 用户创建 PlayReady 数据存储的副本。

  • 在播放 Content1 或 Content2 之前,用户将时钟设置为 08/01/18,还原 PlayReady 数据存储的副本。 可以播放这两部分内容。

现在,请考虑相同的基本示例,但在许可证中使用 BeginDates:

  • 日期为 08/01/18 — 用户获取 Content1 的 License1。 License1 有 BeginDate=08/01/18,EndDate=08/30/18。

  • 日期为 09/01/18 — 用户获取 Content2 的 License2。 License2 有 BeginDate=09/01/18,EndDate=09/30/18。

  • 用户创建 PlayReady 数据存储的副本。

  • 在播放 Content1 或 Content2 之前,用户将时钟设置为 08/01/18 之前的日期,还原 PlayReady 数据存储的副本。 仅 Content1 将播放。

此示例演示 BeginDate 如何自然地帮助减少要还原以规避许可证策略的数据存储的可行性。 用户可以使数据存储的更多副本以处理 BeginDate,但随着内容文件的数量增大,处理许可证策略所需的所有数据存储的管理比例增加,使得攻击变得不那么可行。

总之,在 PlayReady 许可证中指定 EndDate 时,最佳做法是还包括 BeginDate。

设置适用于客户端的 BeginDate 值

将 BeginDate 添加到许可证时,最好在过去为 PlayReady 客户端版本 1 或 2 设置它。 原因是,生成此许可证的服务器与接收此许可证的客户端之间可能存在轻微的时钟差异,服务器的目的是客户端在收到许可证后立即使用该许可证。

对于 PlayReady 客户端 3 及更高版本,客户端会按照许可证请求将其时钟值发送到许可证服务器,并且服务器可以根据许可证服务器已知的时间值设置 BeginDate 和其他时间限制。

PlayReady 客户端版本 2 的典型示例是:

  1. 用户于 2018 年 1 月 5 日星期五下午 8 点左右在运行基于 PlayReady 2.5 的应用的Android手机上租用内容。

  2. Android应用向许可证服务器发起许可证请求。 电话时钟指示下午 7:56,许可证服务器时钟在晚上 8:00。

  3. 许可证服务器接收许可证请求,检测客户端是否为版本 2,并使用以下命令生成许可证:

    • 播放右侧

    • 开始时间 = 本地服务器时间减去 5 分钟 = 2018 年 1 月 5 日下午 7:55

    • 到期时间、首次播放后过期、输出保护等其他正确的限制

    1. 许可证服务器将许可证发送回客户端。

    2. 客户端开始播放。 电话时钟仍为 7:56PM,并且已超过许可证的 BeginDate,即下午 7:55,因此播放实际上可以立即启动。

PlayReady 客户端版本 3 的典型示例是:

  1. 用户于 2018 年 1 月 5 日星期五下午 8 点左右在运行 UWP 应用的Windows 10计算机上租用内容。

  2. UWP 应用向许可证服务器发起许可证请求。 电脑时钟指示下午 7:56,许可证服务器时钟在晚上 8:00。

  3. 许可证服务器接收许可证请求,检测 PlayReady 客户端是否为版本 3,并检查客户端时钟的值:

    • 如果客户端时钟值不低于许可证服务器时钟值 1 小时,请继续并生成许可证。

    • 否则,请拒绝许可证请求,并将消息发送到客户端应用,请求将时钟设置为正确的值。

  4. 许可证服务器使用以下命令生成许可证:

    • 播放右侧

    • 开始时间 = 许可证请求中包含的客户端时间 = 2018 年 1 月 5 日下午 7:56

    • 到期时间、首次播放后过期、输出保护等其他正确的限制

    1. 许可证服务器将许可证发送回客户端。

    2. 客户端开始播放。 电脑时钟仍为 7:56PM,并且等于或超过许可证的 BeginDate,即下午 7:56,因此播放实际上可以立即启动。

订阅许可证中的时间限制

PlayReady 支持订阅业务模型,用户可以按月支付费用,以换取访问服务提供的大型内容目录。

在此方案中,PlayReady 许可证服务器为每个内容文件颁发叶许可证,以及单个根许可证。 为了使 PlayReady 访问内容,需要其叶许可证和根许可证 (许可证链) 。 这两个许可证都必须包含对内容执行的操作 (,例如,播放) 并且两个许可证都必须有效, (未过期,依此类而) 。

由于任何特定内容目录只有一个根许可证,并且可能有数百或数千个叶许可证,因此,如果存在任何) 限制,则叶许可证应包含很少 (,根许可证应包含时间限制,并定期 ((例如每月) 刷新)。 当订阅即将过期时,许可证服务器只需要颁发一个许可证,所有内容都将使用新的有效到期日期进行更新。 如果叶许可证中的策略包含基于时间的策略,则需要重新颁发所有叶许可证,以防止内容过期,这是服务器的性能要求很大。

总之,如果内容应该使用许可证链过期,则只有根许可证应包含基于时间的策略。