通常、Microsoft PlayReady はメディア ファイルのライセンスを提供することでコンテンツを保護します。 ファイルを非表示にしたり、アクセスできないようにしたり、ファイルがシステムからシステムに送信されるときに特別な保護を実施したりする必要はありません。 つまり、オペレーティング システムの要件や、高セキュリティのファイル トランスポート メカニズムは必要ありません。 ただし、ファイルをコピーしてフレンドに渡しても、PlayReady によって保護されている場合、そのフレンドはファイルを使用できなくなります。 メディア ファイルを使用するには、ユーザーにライセンスが必要です。 このライセンスは、コンテンツ (メディア ファイル) を制御するための主要な手段です。 ライセンスは、1 つのクライアント (メディア プレーヤーなど) またはドメインに付与されます。 ライセンスは、他のクライアントまたは他のドメインでは機能しません。
各ライセンスには権限と制限が含まれており、コンテンツの使用方法と条件を正確に定義します。 たとえば、音楽ファイル ライセンスでは"再生する権利" を有効にできますが、コンテンツを再生できるアプリケーションのセキュリティ レベルは制限されます。 ライセンスは、2017 年 10 月 1 日から 2017 年 11 月 1 日までの期間有効な場合があります。 1 つのファイルに対して複数のライセンスが存在する場合があります。 ユーザーは、いずれかのライセンスが適切な権限を付与し、制限によってアクセスが禁止されない限り、自分のコンテンツにアクセスして使用できます。
エンド ツー エンド ビデオ サービスの概要
次の図は、左側のサービスのバックエンドや右側のクライアントなど、エンド ツー エンドのビデオ サービスの概要を示しています。
図の左側には、サービスにビデオをストリーミングするためのサーバー (コンテンツ配布ネットワーク) があることがわかります。 ユーザーがコンテンツを参照し、再生するコンテンツを選択できるようにするサーバーもあります (ユーザー インターフェイス)。 さらに、ユーザーがログインして認証できるサーバーと、コンテンツの支払い (認証、支払い) が可能なサーバーもあります。 また、PlayReady ライセンス サーバーもあります。
図の右側にはクライアントがあります。 クライアントは、Windows アプリケーション、スマートフォン アプリケーション、またはセット トップ ボックス、ネットワーク レシーバーなどの特定のデバイスである可能性があります。 これらのクライアントの一部には、プレーヤーに PlayReady 統合クライアントが付属している場合があります。たとえば、OEM がオペレーティング システムまたはハードウェアに PlayReady を統合している場合があります。 他のユーザーには、アプリ ストアに公開されているアプリケーションに統合されたクライアントが付属している場合があります。 プレイヤーがクライアント側で PlayReady を統合するためのさまざまなオプションがあります。
このトピックでは、次の図に示すように、PlayReady がサービスに対して何を行うかに焦点を当てます。
PlayReady によって提供される方法は、クライアントがサーバーにライセンスを要求し、開いているネットワーク経由で保護された形式でコンテンツを保護するキーを配信する方法です。 PlayReady が 2 つ目に行うことは、権限と適切な制限をクライアントに提供することです。 PlayReady を使用すると、サービスはコンテンツ再生のキーを提供できますが、たとえば、レンタル シナリオでクライアントがそのキーを 2 日間だけ使用することを許可します。 そのため、PlayReady には、キーで権限と適切な制限を宣言する方法が用意されています。
PlayReady には、クライアント側にコンテンツ キーをより安全に格納する方法も用意されているため、クライアントはそのクライアント キーを使用してレンダリング用のコンテンツを復号化できますが、コンテンツをクリアに保存して他のユーザーと共有することはできません。
PlayReady クライアントが正しい方法で動作するように、PlayReady では、コンプライアンスと堅牢性の規則に従うハードウェアとソフトウェアの実装が必要です。 これらのルールは、クライアントが PlayReady コンテンツの暗号化を解除または処理する場合の動作を制御します。 また、クライアントがライセンスで見つかった制限を正しく処理することも必要です。 そのため、クライアントがコンテンツ キーを使用する手順を 48 時間以内に受け取った場合、クライアントはそれらの手順に従う必要があります。 これらの規則は 、コンプライアンスと堅牢性の規則で Microsoft によって提供され、クライアントの開発者がクライアントでこれらの規則を適用する必要があります。
基本的な暗号化とライセンス プロセス
次の手順は、コンテンツのエンドツーエンドの暗号化とライセンス プロセスと、PlayReady がプロセスにどのように関与するかを示しています。
次の図には、暗号化されていない 1 つの資産 (オーディオ/ビデオ ファイル) が含まれています。 コンテンツの暗号化に使用されるメソッドは完全にコンテンツ プロバイダーにかかっており、PlayReady の一部として提供されません。
このファイルを暗号化するには、サービスがコンテンツ暗号化機能でキー ジェネレーターを使用し、コンテンツの暗号化に使用される新しいコンテンツ キーを生成する必要があります。 このコンテンツ キーは、後で PlayReady ライセンス サーバーからクライアントに配信され、ユーザーのコンテンツとレンダリングの復号化が可能になります。 暗号化サービスは、秘密値であるコンテンツ キーと共に、キー識別子 (KEYID) (GUID) をコンテンツ キーに関連付けます。 KeyID はパブリック値です。
キーと KeyID は暗号化時に設計され、キー管理システム (通常はデータベースの種類) に格納されます。 PlayReady はキー管理システムを提供しないため、キー管理システムは、放送局と共にサービスを構築するサービスプロバイダーやパートナーが提供することが求められます。
キーと KeyID をキー管理システムに格納するだけでなく、KeyID をパッケージャーに合わせる必要もあります。これにより、ヘッダーが生成されます。 このヘッダーは、 PlayReady ヘッダー仕様に従ってサービスまたはパートナーによって書式設定され、コンテンツ ファイル ヘッダーのクリアに取り付けられます。
この時点で、オーディオとビデオは KeyID を使用して暗号化され、暗号化されたコンテンツ ファイルがクライアントに配信される準備が整います。
これで、クライアントはコンテンツの使用を開始できます。 クライアントが最初に行うことは、通常はログイン名とパスワードを指定してサービスに対してユーザーを認証することですが、ユーザーとデバイスを認証するためのその他のメカニズムは問題ありません。 通常、ユーザーが検証されると、セッション トークンがクライアントに返されます。 ユーザー認証に使用されるメカニズムは何であれ、ユーザーの認証方法はサービスに完全にかかっていることに注意してください。PlayReady はこのテクノロジを提供していません。
次に、コンテンツがクライアントに配信されます (たとえば、クライアントはコンテンツを構成するデータ ストリームの一部のダウンロードを開始しました)。 その後、クライアントはこのコンテンツの解析を開始し、暗号化されていることを検出し、不明だが KeyID を含むキーを使用します。
その時点で、クライアントはライセンス取得要求をライセンス サーバーに送信します。
その後、ライセンス サーバーは認証サービスとインターフェイスを使用してユーザーを確認します。 通常、ライセンス サーバーが最初に行うことは、クライアント/ユーザーがその特定のライセンスに対する権利を持っていることを確認することです。 また、PlayReady はそのレイアウト (認証) を提供せず、ライセンス サーバーのみを提供します。 認証サービスは通常、"はい" または "いいえ" で応答するか、または制限付きで "はい" と応答します (たとえば、このユーザーは、この特定の映画に対する権利を持ちますが、ユーザーが 1 か月に支払う金額に基づいて、最も質の高いサブスクリプション レベルを持っていないため、ビデオの品質が低い場合などです)。
次に、ライセンス サーバーはキーを格納するキー管理システムから KeyID に基づいてキーの値を要求し、キー管理システムはその要求に応答します。 繰り返しになりますが、PlayReady はキー管理システムのコンポーネントを提供しないため、PlayReady ライセンス サーバーから、キーを格納するためにサービスが構築したコンポーネントに要求が送信されます。
キーはライセンス サーバーによって受け取られ、ライセンス サーバーはライセンスを配信できます。 保護された PlayReady ライセンス応答には、キーの値と、クライアントが適用する権限と権限の制限の一覧が含まれます。
このデモでは、PlayReady ライセンス サーバーが 1 つのキーのみを配信していることを示していますが、ライセンス サーバーが 1 つのライセンス応答でライセンスのスタックを配信する可能性があります。 コンテンツが複数のキーで保護されている場合、またはサービスが複数のキーを事前に配信する必要がある場合は、ユーザーが 8 つのトラックを連続してリッスンすることをサービスが認識するため、1 つのトランザクションに複数のライセンスを含め、各ライセンスで 1 つのキーを提供できます。
PlayReady が提供するもう 1 つのテクノロジは、ライセンス ストアと呼ばれるキーと権限をクライアントに格納する方法です。
The License Store is typically called the HDS because the structure of the License Store is a *hashed data store*. There can be multiple types of License Stores on a device — one application could contain its own HDS just to ensure that one company's HDS is not in the same file as another company's HDS. It is entirely up to the client developer to make this design choice. For example, using PlayReady on Windows, Microsoft chose to have one HDS for Internet Explorer and another for Microsoft Edge per site, as well as one for each Windows Universal App.
The HDS can be stored in a persistent way, such as on the hard drive or persistent memory of the device, or it can be stored in a non-persistent way, such as in non-persistent memory. Therefore, when the License Server issues a license, it could set a property of the license indicating that the license should not be stored on the hard drive of the client, or in the case of a set top box or phone, that it should not be stored in persistent memory because, as a service, you don't want to have your licenses stored in persistent memory. In that case, just store the HDS in memory in the context of the player application, so as soon as the user closes the player application, the license and its rights will vanish.