Home 技術記事 大規模OTTスタックにDRMを展開するためのベストプラクティス
Applications

大規模OTTスタックにDRMを展開するためのベストプラクティス

About The Author

Outline

デジタル著作権管理(DRM)は、コンテンツ所有者にプレミアムコンテンツを保護するためのオプションを提供する業界標準である。 効果的なDRMソリューションは、ほとんどの再生デバイスで動作し、ワークフローに簡単に統合でき、ユーザーに透過的に見える必要がある。 オフライン再生などの高度な機能をサポートできれば、はるかに優れている。 DRMは多くのストリーミングサービス事業者にとって最優先事項ではないかもしれないが、視聴者の再生体験への影響は後回しにすることはできない。

DRMシステムの目標は、ビデオコンテンツが暗号化された形式で保存および送信されるようにすることであり、許可されたユーザーとデバイスのみがコンテンツを再生できるようにすることである。 DRMは、ストリーミングプラットフォーム上に階層化されたAES (Advanced Encryption Standard) 128ビット暗号化に過ぎないと誤解されることが多い。 実際には、DRMはコンテンツアクセスを管理するための完全なシステムである。 DRMは、暗号化および復号化キーの安全な配布と、不正なハードウェアでの再生を防止するポリシー制御やオフライン再生制御などの機能を追加するバックエンドライセンスサーバーを提供する。

DRMは3つの方法のいずれかで展開できる。 1つ目は、開発と統合をすべて自分で行うこと。 これは時間がかかるが、最大限の制御と柔軟性を可能にする。 2つ目はハイブリッドアプローチで、プロバイダのパッケージ済みDRMソリューションをワークフローに統合する。 3番目のオプションは、マネージドストリーミングサービスの一部としてDRMソリューションを利用する。 Verizon Media Platformは、このタイプのDRMソリューションを提供する。 ビデオワークフローに統合され、シンプルなサービスオーダーで実現。 開発と統合の負担を担う。 最初の2つのオプションでは、DRMは1回限りのプロジェクトではなく、進化する標準と技術に対応するための継続的なプログラムが必要であることを忘れないでください。

原始的DRM

今日の主要なビデオストリーミングフォーマットは、独自のDRMシステム統合を備えている。 DRM技術はプロプライエタリなので、例外が増えているにもかかわらず、通常はOEM固有の製品でのみサポートされる。 例えば、Apple FairPlayは主にウェブブラウザのApple Safariやその他のAppleのハードウェアやソフトウェア製品と互換性がある。 ストリーミングサービスの観点からは、クロスプラットフォーム互換性がないため、包括的なデバイス範囲をカバーしたい場合は、マルチDRM戦略を採用し、複数のフォーマットでパッケージ化され、暗号化されたコンテンツを提供する必要がある。

市場には多くのDRMシステムがあるが、実用的な観点からは、ストリーミングサービスは、実質的にすべてのWebブラウザ、デバイス、テレビをサポートするために、ビッグ3に関係するだけでよい。

  • Apple FairPlayストリーミング(FPS)–FairPlayコンテンツは主にSafari、iOS、Apple TVプラットフォームを含むAppleデバイスで再生できる。
  • Google Widevine–このDRMソリューションは、すべてのChromeおよびFirefox WebブラウザとAndroidおよびChromecastデバイスに対応。
  • Microsoft PlayReady–このDRMソリューションによって保護されたコンテンツは、Roku、Xbox、
  • Microsoft Edgeブラウザ、およびSDKを介した他のさまざまなプラットフォームとスマートテレビ。

この状況は、DRM市場の断片化を簡素化するための標準化の努力が進行中の基盤となる暗号化を見ると多少改善される。 WidevineとPlayReadyの両方がCommon Encryption (CENC)とMPEG-DASHをサポートしているため、コンテンツを一度暗号化してパッケージ化し、DRMシステムを使用してそれらのアセットを復号化できる。 FairPlayは128-AES CBCS(または暗号ブロックチェーンサンプルモード)暗号化とHLSパッケージングを使用する。 CBCSはいくつかの新しいDASH再生デバイスでもサポートされている。 市場は一般的な暗号化のためにCBCSに集中するように思われるが、他の暗号化は長い間サポートされる必要がある。

マルチDRMの課題

私たちのプラットフォームの場合、私たちは複数のフォーマットで取り込んだコンテンツを即座に暗号化する。 デフォルトのDASHパッケージと暗号化では、デバイス間で最も互換性があるため、AES-CTR完全暗号化が使用されている(新しいデバイスはCBCSをサポートする場合もある)。 さらに、FairplayではトランスポートストリームパッケージングとCBCS暗号化をデフォルトで使用している。これは、デバイスの全範囲で最も互換性があるためである。 これらは世界中のほとんどのデバイスやプレイヤーをカバーしているが、複雑さを増し、ストレージコストを増加させる。 アダプティブビットレート(ABR)では、手元に2つまたは3つの異なるファイルがあり、すべてのビットレートを考慮すると、4秒または2秒の再生時間のブロックごとに15以上の異なるセグメントになる可能性がある。

この状況はゆっくりと改善している。 業界は、単一のDRM対応ファイルセットでほとんどの消費者の画面に到達できるCommon Media Application Format (CMAF)と呼ばれる仕様の広範な採用に向かっている。 現在、CMAFはすでに多くのDASHやHLSデバイスやプレイヤーで動作している。 それが理にかなっているところでは、動的マニフェスト生成ロジックを使用して、CMAF準拠の暗号化とCBCSを使用してHLSマニフェストを作成し、追加のデバイスをサポートできる。

これら全てのファイルセットをエンコードすることは、大規模な問題となる。 クラウドの拡張性を活かして解決した。 私たちのスライサーが最高ビットレートでファイルをアップロードすると、各スライスをブローカーに送り、そのブローカーが作業を巨大なエンコーディングクラスターに仕上げる。 符号化操作を並列に行うことにより、ビットレート、コンテナフォーマット、暗号化アルゴリズムの組み合わせごとに必要なすべてのファイルを最小限のレイテンシで迅速に作成できる。

暗号化のエンコーディング、パッケージング、ストレージと処理の要件の克服のニュアンスを理解することは、マルチDRM実装に伴う複雑さに関する氷山の一角にすぎない。 その他の課題:

  • DRMサーバーからの遅延のないキー取得により、すべてのデバイスで一貫したユーザー体験を実現
  • 絶えず変化するクライアントデバイスと関連するSDK、およびオペレーティングシステムのバリエーションを常に把握
  • MovieLabsなどが定義するEnhanced Content Protection(ECP)パラメータに準拠し、プレミアムコンテンツやUHDコンテンツに対応
  • タイムシフト、キャッチアップ視聴、クラウドベースのDVRの使用、オフライン再生など、複雑なライセンス契約と保護契約の監視と遵守

この要件をすべて満たし、ワークフロー全体でコンテンツを確実に保護するには、キー管理ソリューションの開発、ライセンスサーバーの設定、コンテンツの再生条件を決定するセキュリティポリシーの定義と管理が必要である。 例えば、私たちのプラットフォームには、ほとんどの状況に適したデフォルトのポリシーセットがある。 Studio DRMポリシー構成ツールは、ユーザーごとにこれらのポリシーを簡単に構成できる。 ポリシーはライセンスサーバーに実装され、セキュリティレベルの強制や出力制限、キーの持続時間、再生時間、オフラインレンタルが許可されているかどうかなどのさまざまな変数をカバーできる。 ポリシーオプションはDRMによってもかなり異なる場合がある。

鍵管理が鍵

ポリシー管理と同様に、プラットフォームはキー管理とライセンスのすべての側面を処理して、キーがワークフロー全体にわたって保護されるようにする必要がある。 セキュリティはVerizon Mediaの完全統合プラットフォームで簡単に実現できるが、別のサービスを使用する場合は、エンコーダからサードパーティのDRMソリューションにキーを安全に送信する方法が必要になる。 これにはSecure PackagerやEncoder Key Exchange (SPEKE)などの標準を実装するためのかなりの作業が必要であり、鍵は外部からコンテンツをエンコードしてライセンスサーバーに渡すことができる。 すべてを同じネットワーク上に維持することで、この手順を回避し、実装を簡素化することができる。

DRMインフラストラクチャをワークフローに組み込むと、次の大きな課題はプレイヤーの統合である。 ここでは、各プレイヤーのSDKを調べて、しゃっくりがないことを確認するためにかなりの時間を費やした。 一つの課題はサーバーサイド広告挿入(SSAI)であることが判明した。 ライブイベントやライブチャンネルにステッチするために、個別にエンコードされた広告の大規模なライブラリを保持しているため、これらの広告すべてがプラットフォーム上のすべてのライブイベントやチャンネルと同じキー暗号化キーを共有することはできない。 この問題を解決するには、広告を挿入するストリームとは異なる個別のキーで暗号化するか、一意のストリームごとにオンザフライで再パッケージ化するか、暗号化せずにストリームに挿入する必要がある。

これらのバリエーションはライブストリームの再生を複雑にする。 例えば、一部のプレイヤーは途中でDRMキーを切り替えることをサポートしていない。 そのサポートがあっても、切り替えは再生体験に顕著な効果をもたらす可能性がある。 フレームバッファを完全に空にする必要があり、新しいキーを持つフレームをキューに入れる前に、新しいキーの初期化を実行する。 これを行うと、一部のプラットフォームで目に見える不具合が発生する可能性がある。

これらの課題により、プレイヤーのパフォーマンスを向上させ、新しい広告が表示されるたびに重要な変更を実行する必要性を回避するために、広告を暗号化しないままにしておくことにした。 暗号化されていない広告は、必要なストリームキーのすべての組み合わせで各広告を再パッケージする必要がないため、オンザフライで広告を再暗号化するよりもサーバーパフォーマンスが向上する。 暗号化されていない広告を使用することは、プレイヤーにとって同じキーを使用するよりも少し複雑になる。 それでも、多くのプレイヤープロジェクトは、これがここ数年の間サポートされている再生シナリオであることを保証している。

また、ライセンスURLの仕組みを簡素化し、特定のプレイヤーにとってより便利なものにした。 これは、まずライセンスサーバーのURLをマニフェストに入れることで実現したので、プレイヤーがURLを読むことをサポートしている場合は、別途提供する必要はない。 次に、すべてのセッション固有データをマニフェストのProtection Scheme Specific Header (PSSH)ボックスにエンコードする。 これにより、プレイヤーは追加のヘッダーデータやURLパラメータなしで、非常に単純なライセンスサーバーURLをライセンス要求に使用することができる。 プレイヤーとストリームに同じライセンスURLを使用することで、DASH再生の統合が非常に簡単になる。

Toward DRMの統合が容易

私たちのプラットフォームの包括的な目標の1つは、サービスプロバイダーにとってストリーミングをより簡単かつ簡単にすることである。 ABR再生用のオープンソースJavaScriptライブラリであるShaka Playerなど、オープンソースプレーヤーの利用を拡大し続けている。 また、人気のユニバーサルビデオプレーヤーソリューションであるTHEOplayerとも提携している。 暗号化規格やDRM技術の変化に対応するために、プラットフォームを継続的に進化させている。 多くの企業がDRMを使用することを楽しんでいないことを理解しているため、この重要なセキュリティタスクをチェックリストの他の項目と同様にすることができれば、より良い。