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回限りのプロジェクトではなく、進化する標準やテクノロジーに対応するための継続的なプログラムが必要です。

Proprietary DRM(目標DRM)

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

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

  • Apple FairPlay Streaming (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パッケージを使用します。 CBCは、一部の新しいDASH再生デバイスでもサポートされています。 市場は一般的な暗号化のためにCBCSに集中しているようですが、他の暗号化は長期的にサポートする必要があります。

マルチDRMの課題

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

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

これらすべてのファイルセットをエンコードすることは、大規模な場合にははるかに大きな問題になります。 クラウドのスケーラビリティを活用することで、この問題を解決しました。 Slicerが最高のビットレートでファイルをアップロードすると、各スライスを巨大なエンコーディングクラスターにファームアウトするブローカーに送信します。 エンコード処理を並行して実行することで、ビットレート、コンテナフォーマット、暗号化アルゴリズムの組み合わせごとに必要なすべてのファイルを最小限のレイテンシで迅速に作成できます。

暗号化のエンコード、パッケージング、ストレージと処理の要件の克服のニュアンスを理解することは、マルチ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の使用を楽しんでいないことを理解しています。そのため、チェックリストの他の項目と同様に、この重要なセキュリティタスクを作成できれば、より良いものになります。