レッスン
理論 — ライブ配信のキーローテーション
コンテンツキーとは、メディアを暗号化するAESキーのことです。プレイヤーは、そのデバイス専用に発行されたライセンスの中にキーを含めてライセンスサーバーから受け取ります。ライブ配信中、暗号化期間ごとにコンテンツキーを入れ替える仕組みをキーローテーションと呼び、プレイヤーはその都度新しいキーを必要とします。一方、キー階層ではライセンス内にルートキーが含まれます。このときコンテンツキーはリーフキーと呼ばれ、ストリーム自体の中に埋め込まれて届き、ルートキーと組み合わせた場合のみ使用できます。
各記号の意味
T- 暗号化期間。一つのコンテンツキーが使用される時間(秒)
N- 同時に視聴している人数
w- 再生位置がライブエッジからどの程度分散しているか。全員がキーの境界を越える時間の幅を意味する
R- キー階層において、一つのルートキーが有効な時間(時間)
- 前提
- 境界ごとに視聴者一人あたり1回のライセンス要求が行われ、その中に期間中のすべてのキーが含まれていること、そして全員が配信の最初から最後まで視聴し続けることを前提としています。変更時に要求する場合、要求は境界後のw秒間に均等に分散し、事前取得する場合は期間全体に均均に分散すると仮定します。実際のアクセスはこれらの平均値の前後で波打ち、サーバーはそれを吸収する余裕を持たせて設計されます。したがって、ここでのピーク値はサーバーが耐えるべき最低限の基準となります。なお、視聴者の途中参加や退出、要求失敗時の再試行、および各プレイヤーが再生開始時に取得する最初のライセンスについては除外しています。
- 成り立たない場合
- 流出したキーがデバイス自身のキーである場合、話は変わります。ローテーションは一つのコンテンツキーの被害を限定し、階層は一つのルートキーの被害を限定します。しかし、デバイスキーが抽出されてしまったプレイヤーは、サービスが発行するすべてのキーを要求し、解読し続けることができます。こうなると暗号化期間は意味をなしません。そのデバイスへのライセンス発行を拒否するか、拒否すべきライセンスサーバーが存在しない場合は、デバイスを取り消す(無効化する)必要があります。デバイス失効のページで計算しているのはまさにこの点です。
全プロセスの詳細解説
-
1台のライセンスサーバーで決勝戦を捌けるか? 4 ステップ
暗号化期間はどこまで短くできるか? カップ戦の決勝を押してください。視聴者は3,000,000人。2分間隔のキーローテーションと事前取得方式により、毎秒25,000の要求が発生します。ここでライセンスサーバーの処理能力は20,000であるとします。事前取得方式でこのサーバーが耐え得る最短の暗号化期間、変更時に要求した場合にサーバーにかかる負荷、そして1日有効なルートキーを事前取得した場合の代償を求めてください。
-
事前取得の場合、すべての視聴者が1期間に1回要求し、その要求は期間全体に均等に分散します。そのため負荷はN/Tとなり、これがサーバーの処理能力である20,000以下に収まらなければなりません。
-
2分間隔の場合、負荷は処理能力の1.25倍に達します。代わりにTについて解くと、150秒以上である必要があるとわかります。
-
変更時に要求する場合、再生位置が分散している10秒間に全視聴者が要求を行います。つまりすべての境界において毎秒300,000となり、処理能力の15倍に達します。N/wの式にTは含まれないため、暗号化期間をどう調整しても解決しません。解決策はただ一つ、再生位置を150秒間に分散させることだけです。
-
1日有効なルートライセンスを前日のランダムなタイミングで事前取得する階層構造の場合、発生するのはルートキーの要求のみです。つまり、1日(86,400秒)の間にN回の要求となります。
解答
事前取得で最低150秒、変更時の要求で毎秒300,000、1日有効なルートの事前取得で毎秒34.72。 コンテンツキーを一つずつ配布する方式では、どちらを選んでも2分間隔のローテーションをこのサーバーで処理することはできず、2分半であっても全く余裕がありません。階層構造にすれば576倍の余裕が生まれますが、その代償は3つ目の洞察で述べた通りです。一つのルートキーが流出しただけで、決勝戦の1日分が丸ごと解読されてしまいます。
-
参考文献 (2)
- The three delivery modes the page compares, and its three quotations: key rotation signalled in-band so every player asks at once (§9.3), the key hierarchy with a root licence once a day (§9.4), and rotation's purpose stated as re-authorisation rather than security (§9.2): DASH Industry Forum, DASH-IF Interoperability Points, Part 6: Content Protection. DASH-IF IOP-6 V5.0.0, January 2022, clause 9 Key rotation.
- How a packager is handed one content key per crypto period, why a stream carries several keys at once, and the two-level root and leaf hierarchy: DASH Industry Forum, DASH-IF Implementation Guidelines: Content Protection Information Exchange Format (CPIX), version 2.2, §6.2 Key Rotation Support and §6.3 Hierarchical Keys.