ライセンス ポリシーのベスト プラクティス
このセクションでは、PlayReady テクノロジを使用する場合のプログラミング ライセンス ポリシーのベスト プラクティスについて説明します。
EndDate での BeginDate の使用
PlayReady がサポートする多くのビジネス モデルの 1 つは、コンテンツのレンタルです。一定期間のみ使用できるコンテンツ (たとえば、コンテンツは 2018 年 10 月 15 日午後 5 時まで使用できます)。 これは、EndDate がライセンスの有効期限が切れる日時に設定された PlayReady ライセンスをクライアントに発行することによって実現されます。
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 Clients バージョン 1 または 2 用に、過去に少し設定することをお勧めします。 その理由は、このライセンスを生成するサーバーとそれを受け取るクライアントの間にわずかなクロックの違いがある可能性があり、サーバーの目的は、クライアントがライセンスを受け取るとすぐに使用できることです。
PlayReady クライアント 3 以降の場合、クライアントはライセンス要求に沿ってそのクロック値をライセンス サーバーに送信します。サーバーは、ライセンス サーバーに認識されている時間値に近い状態で、その値に対して BeginDate やその他の時間制限を設定できます。
PlayReady クライアント バージョン 2 の一般的な例は次のとおりです。
ユーザーは、2018 年 1 月 5 日金曜日の午後 8 時頃、PlayReady 2.5 上に構築されたアプリを実行しているAndroid電話でコンテンツをレンタルします。
Android アプリは、ライセンス サーバーへのライセンス要求を開始します。 電話クロックは午後 7 時 56 分を示し、ライセンス サーバークロックは午後 8:00 に設定されています。
ライセンス サーバーはライセンス要求を受け取り、クライアントがバージョン 2 であることを検出し、次を使用してライセンスを生成します。
右に再生
開始時刻 = ローカル サーバー時間 - 5 分 = 2018 年 1 月 5 日午後 7 時 55 分
有効期限、初回プレイ後の有効期限、出力保護などのその他の適切な制限
ライセンス サーバーは、ライセンスをクライアントに返送します。
クライアントが再生を開始します。 電話時計はまだ午後 7:56 で、ライセンスの BeginDate (午後 7:55) を過ぎているので、実際にはすぐに再生を開始できます。
PlayReady クライアント バージョン 3 の一般的な例は次のとおりです。
ユーザーは、2018 年 1 月 5 日金曜日の午後 8 時頃、UWP アプリを実行しているWindows 10 コンピューターでコンテンツをレンタルします。
UWP アプリは、ライセンス サーバーへのライセンス要求を開始します。 PC クロックは午後 7 時 56 分を示し、ライセンス サーバークロックは午後 8:00 に設定されています。
ライセンス サーバーは、ライセンス要求を受信し、PlayReady クライアントがバージョン 3 であることを検出し、クライアント クロックの値を確認します。
クライアント クロックの値が 1 時間を超えてライセンス サーバーのクロック値を下回っていない場合は、続行してライセンスを生成します。
そうでない場合は、ライセンス要求を拒否し、クライアント アプリにメッセージを送信して、クロックを適切な値に設定するように要求します。
ライセンス サーバーは、次の方法でライセンスを生成します。
右に再生
開始時刻 = ライセンス要求に含まれるクライアント時間 = 2018 年 1 月 5 日午後 7 時 56 分
有効期限、初回プレイ後の有効期限、出力保護などのその他の適切な制限
ライセンス サーバーは、ライセンスをクライアントに返送します。
クライアントが再生を開始します。 PC クロックは、まだ午後 7:56 で、ライセンスの BeginDate (7:56PM) と等しいか過去であるため、実際にはすぐに再生を開始できます。
サブスクリプション ライセンスの時間制限
PlayReady では、サービスによって提供される大規模なコンテンツ カタログにアクセスする代わりに、ユーザーが月額料金を支払うサブスクリプション ビジネス モデルがサポートされています。
このシナリオでは、PlayReady ライセンス サーバーは、コンテンツ ファイルごとにリーフ ライセンスと 1 つのルート ライセンスを発行します。 PlayReady がコンテンツにアクセスするには、リーフ ライセンスとルート ライセンス (ライセンス チェーン) の両方が必要です。 両方のライセンスに、コンテンツに対して実行されているアクション (再生など) が含まれている必要があり、両方のライセンスが有効である (有効期限切れではないなど) 必要があります。
ルート ライセンスは 1 つだけであり、特定のコンテンツ カタログに対して数百または数千のリーフ ライセンスが存在する可能性があるため、リーフ ライセンスには非常に少数の (存在する場合) 制限が含まれている必要があり、ルート ライセンスには時間制限が含まれており、定期的に更新する必要があります (たとえば、毎月)。 サブスクリプションが失効しようとしている場合、ライセンス サーバーは 1 つのライセンスのみを発行する必要があり、すべてのコンテンツは新しい有効有効期限日で更新されます。 リーフ ライセンスのポリシーに時間ベースのポリシーが含まれている場合は、コンテンツの期限切れを防ぐために、すべてのリーフ ライセンスを再発行する必要があります。これは、サーバーのパフォーマンス要件が大きくなります。
要約すると、ライセンス チェーンを使用してコンテンツの有効期限が切れるはずの場合、ルート ライセンスにのみ時間ベースのポリシーを含める必要があります。