SPEKE v2.0とAWS Elemental MediaPackageでコンテンツセキュリティを強化する

CPIXとSPEKEの歴史

2015年にDASH-IFのCPIX（Content Protection Information Exchange Format）仕様が発表されるまで、エンコーダーやパッケージャーがキーサーバーに暗号化キーを要求する際に利用できる標準的なペイロードフォーマットはありませんでした。CPIXはこのギャップを埋めるために、XMLをベースにしたハイレベルなフレームワークを提供し、保護するストリーム、関連する暗号化キーを記述し、マニフェストのシグナリング情報を伝えるものです。

CPIXは当時の業界にとってまさに革新的なものでしたが、その適用範囲は限られていました。CPIXは、実装者をサポートするための複数のオプションを持つ、幅広いフレームワークであり、XMLをやりとりするための標準的なAPIは含まれておらず、当時はDASHのユースケースのみをカバーしていました（HLSやSmooth Streamingのユースケースは含まれていませんでした）。

AWS Elementalは、CPIX v2.0をベースに、2017年末にSPEKE（Secure Packager and Encoder Key Exchange）仕様を作成しました。SPEKE v1.0は、CPIXエクステンション、CPIXプロファイル、CPIX APIを実装しました。CPIXエクステンションは、HLSおよびMSSシグナリングのユースケースをカバーするためのカスタムXML名前空間を追加しています。CPIXプロファイルは、サポートされるCPIX機能の数を特定のスコープに制限し、CPIX APIは、オンプレミスとクラウドの両方のデプロイメントトポロジーをカバーします。

業界ではこの統一されたアプローチに対するお客様の関心が高まり、複数のDRMサービスプロバイダーが、SPEKE v1.0とその基盤となるCPIX v2.0仕様を迅速に採用しました。パッケージャーの実装は、AWS Elementalのポートフォリオ以外にも登場し始めました。

SPEKE v1.0の仕様のいくつかはその後異議を唱えられています。DASH-IFがHLSとMSSのサポートを追加してCPIX仕様を改良していたため、カスタム名前空間でCPIXを拡張することは業界に断片化をもたらしてしまいました。SPEKEがCPIXプロファイルで採用している制限の一部、特にすべてのオーディオおよびビデオトラックに単一の暗号化キーを使用することが要求されていますが、脆弱なオーディオデコーダを使用してオーディオトラックからコンテンツキーを抽出し、それをビデオトラックの復号に使用することができるため、これも問題になっていました。

最後に、SPEKE APIでは特定のトランザクションで使用されているCPIX仕様のバージョンを記載することができず、後方および前方互換性を保証することが困難でした。2019年と2020年に、AWS ElementalはDASH-IF Content Protection Taskforceと協力してCPIX仕様をバージョニングで充実させ、SPEKE DRMパートナーと協力して前述の制限を取り除き、SPEKE仕様のバージョン2.0を完成させました。

SPEKE v2.0の利点

AWSはSPEKE v1.0でユーザーが直面した課題に対応し、CPIXの拡張機能を廃止し、複数の暗号化キーで異なるトラックを柔軟に保護できるようにしました。

バージョン2.0ではSPEKEはCPIXバージョン2.3の仕様に合わせています。CPIXドキュメントでは新しいCPIX@version属性を使用し、SPEKE APIコールでは新しいX-Speke-Version HTTPヘッダーを使用することで、明示的なクロスバージョニングを実現しています。パッケージャーとキーサーバーの両方が、使用されているドキュメントやAPIのバージョンを正確に知ることができ、使用されているXML構造やワークフロー内のコンポーネントの動作に関する曖昧さが排除されます。

SPEKE v2.0 仕様に含まれる新しい標準化されたエラーメッセージとエラー管理ガイドラインにより、デバッグ作業が容易になりました。カスタムXML名前空間の廃止により、CPIX v2.3の最新機能の恩恵を受けることができます。これは、HLSプレイリストにおける#EXT-X-KEYと#EXT-X-SESSION-KEYのデュアルシグナリングや、キーリクエストで使用されるAESスキームのシグナリングにおいて特に重要でした。

複数の暗号化キーのサポートは、SPEKE v2.0で導入されたもう一つの利点です。VideoFilter要素とAudioFilter要素、ContentKeyUsageRule@intendedTrackType属性を組み合わせて使用することで、要求された暗号化キーを特定のオーディオまたはビデオのトラックにマッピングできるようになりました。このマッピングは、オーディオトラックの場合はチャンネル数に基づいて、ビデオトラックの場合は解像度、フレームレート、HDR特性に基づいて行うことができます。オーディオトラックとビデオトラックに別々のキーを使用することで、脆弱なオーディオデコーダへの攻撃を緩和します。また、SD/HD/4K/8Kの解像度、高付加価値のHDR/HFRビデオトラック、マルチチャンネルのオーディオトラックに別々の暗号鍵が必要な場合、複雑で厳しいコンテンツ保護要件を満たすことができます。

AWS Elemental MediaPackageでSPEKE v2.0を利用する

SPEKE v2.0はLive DASHエンドポイント用のAWS Elemental MediaPackageですでに利用可能で、WidevineとPlayReadyをサポートしています。今回、同等の Live CMAF 実装（FairPlay、Widevine、PlayReady をサポート）が新しい SPEKE v2 仕様とともに利用可能になりました。

どちらの場合も使用できる暗号化キーの数は2つです。1つはすべてのオーディオトラックに、もう1つはすべてのビデオトラックに使用できます。お客様がCPIXの専門家でなくても、APIとAWSマネジメントコンソールでマネージドビデオ暗号化とオーディオ暗号化のプリセットを選択し、CMAFとDASHのエンドポイントで暗号化コントラクトの定義を可能にしました。

AWSマネジメントコンソールでのAWS Elemental MediaPackageのSPEKE設定

今後の予定としては、SPEKE v2.0のVideoFilterとAudioFilterエレメントのサポートによって提供される機能を活用した、追加の暗号化コントラクト、ライブキーローテーションなどがあります。これらの今後の機能は、広範囲にわたる自動および手動のテストを通じて DRM パートナーの実装を認証する、新しい SPEKE v2.0 Qualification Program によってカバーされます。認定された実装のリストは、更新されたSPEKE v2.0オンボーディングページでご覧いただけます。

SPEKE v1.0とSPEKE v2.0におけるMediaPackageの現在のDRMカバレッジに関する詳細は、コンテンツ暗号化のドキュメントページでご覧いただけます。また、SPEKE v2.0の設定オプションに関する詳細は、Live CMAFとLive DASHのページとLive APIのページでご覧いただけます。

End-to-end SPEKE v2.0 ワークフロー

独自のキーサーバーインフラを運用し、独自のSPEKEサーバーを開発したい場合は、更新されたSPEKEリファレンスサーバーフレームワークのGitHubリポジトリで利用可能なSPEKE v2.0 Test Suiteを使用して、実装を自己検証することができます。

参考リンク

AWS Media Services
AWS Media & Entertainment Blog　(日本語)
AWS Media & Entertainment Blog　(英語)

AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp
※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。

翻訳は BD山口、SA石井が担当しました。原文はこちらをご覧ください。