10ブロックに1つのブロックを暗号化 (CENC cbcs)

ビデオスライスのサイズと、暗号化せずに残すヘッダのバイト数を設定してください。ここでは、Common Encryptionの規格に従って暗号化をシミュレーションします。cbcsの10ブロックに1つ、またはcencの全バイトのどちらかを選べます。どのブロックが暗号文になるかを図示し、ストリーム全体や復号処理を行うデバイスにとって何を意味するのかを集計します。

インタラクティブシミュレーションを読み込んでいます...

レッスン

理論 — 10ブロックに1つのブロックを暗号化 (CENC cbcs)

Common Encryption (ISO/IEC 23001-7) は、1つの暗号化ファイルセットで複数のDRMシステムに対応するための規格です。メディアサンプルをAES-128で暗号化しつつ、その構造を読み取れる状態に保ちます。符号化された各ビデオスライスは、平文の部分(NALユニットの長さ、ヘッダ、スライスヘッダ)と、それに続く保護範囲に分割されます。cencスキームは、この保護範囲のすべてのバイトに対してカウンターモードでAESを実行します。一方、cbcsスキームはCBCモードを使用し、16バイトの完全なブロックのパターン(1つを暗号化し、9つを平文のまま残す)を範囲の最後まで繰り返します。末尾にある不完全なブロックは平文のまま残されます。

各記号の意味

L
スライス。符号化されたスライスのNALユニット1つ(バイト単位)
h
平文のヘッダ。長さプレフィックス、NALヘッダ、スライスヘッダ。サブサンプル暗号化によって読み取れる状態で残される
B
保護範囲 P = L − h に含まれる16バイトの完全なブロック。cbcsはそのうち⌈B/10⌉個を暗号化する
前提
ストリーム全体でスライスサイズが1つであると仮定しています。実際のエンコーダは、他の予測元になるピクチャには大きなスライスを、それ以外には小さなスライスを書き出します。そのため、スライスごとの数値は個々のスライスで成立しますが、ストリームに関する数値はすべてが等しいスライスで構成されたストリームを説明するものです。平文ヘッダのデフォルトを32バイトとしているのは、これが仕様で固定されている唯一の長さだからです。AppleのSAMPLE-AESは、NALタイプバイトとその後の31バイトを平文のまま残します。CENCパッケージャは正確にヘッダだけを平文にしますが、その長さはスライスごとに異なります。パラメータセット、SEIメッセージ、およびサンプルの周囲にあるMP4ボックスは平文であり、計算から除外しています。したがって、実際のファイルの暗号文の割合はもう少し低くなります。音声は48 kHzのAAC-LC、1フレーム1024サンプルで、暗号化されていると仮定しています。音声を暗号化せずに提供するサービスでは、その分の処理負荷もなくなります。
成り立たない場合
映像以外のものを隠す手段としては機能しません。平文のヘッダは読まれることを前提として存在しており、鍵の有無に関わらず、ファイルを持つ者にはすべてのスライスの種類、すべてのフレームのサイズ、そしてストリーム全体のタイミングが筒抜けになります。

10ブロックに1つは、10バイトに1つではない 🖖

48バイトのスライスを押してください。三分の一が暗号文です。配列は暗号化ブロックから始まるため、完全なブロックB個からなる保護範囲には⌈B/10⌉個の暗号化ブロックが入り、範囲が一ブロックだけなら一つ入ります。マクロブロック行ごとに一スライスを押すと、306バイトで10.46%です。ほかの値は階段図で確認できます。100バイトでは16.00%、200バイトでは8.00%。この32バイトのヘッダーなら、10 kB以上のどのサイズでも9.95%から10.11%の間に収まります。平文のヘッダーと末尾の不完全なブロックは比率を下げ、B/10の切り上げは比率を上げます。この方式に、両者を相殺させる仕組みはありません。下のパネルには全サイズが同時に描かれます。スライスが大きくなるほど歯の小さくなる、のこぎり波です。一ブロック程度の増減が効かなくなって初めて、一割に落ち着きます。

平文の10分の9が読めないのは、残りの10分の1の配置に理由がある 🖖

フレームの下に並ぶブロックを見てください。スライスの大きさにかかわらず、平文ヘッダーの後ろに完全なブロックが一つでもあれば、ヘッダー直後の先頭バイトは暗号文です。その先で平文バイトが連続する長さは最大144バイト。各区間の直前には、鍵を持たない者には読めない16バイトのブロックが置かれます。スライスにはエントロピー符号化が施されています。デコーダーはビットを順に読み、復号して初めて一つのマクロブロックの終端を知ります。したがって、読めないブロックを飛び越え、その後ろの平文区間から処理を再開することはできません。最初の暗号化ブロックで停止します。保護されたトラックでは、符号化されたスライスがすべて同じ扱いを受けます。ほかのピクチャの予測元になるピクチャも例外ではありません。そのため、鍵のないプレーヤーはヘッダーを解析できても、映像を描画できません。ヘッダーを読めるままにしてあるのは意図的です。ISO/IEC 23001-7では、サブサンプル暗号化の目的を「復号前の映像エレメンタリーストリームに対する通常の処理と編集を可能にするため」と定めています。

cbcsは映像の処理負荷を10分の9削減するが、音声には全く貢献しない 🖖

スマートフォンの360pを押してみてください。映像の暗号文はやはり9.98%です。しかし音声にはパターンを適用するためのNALユニットがないため、パターンなしですべてのフレームの完全なブロックが暗号化されます。つまり各AACフレームの98.53%です。1.5 Mbit/sのビットレートにおいて、128 kbit/sの音声トラックはバイト数で見れば7.86%に過ぎません。しかし、AES処理の45.69%を占めています。そのためストリーム全体で見ると、cbcsの復号処理はcencの10分の1ではなく、5.90分の1になるに留まります。次に1080p, 5 Mbit/sを押すと、同じ音声トラックが処理の20.15%を占め、削減効果は8.20倍になります。規格そのものがパターン暗号化の根拠として「デバイスがビデオトラックを復号するために必要な計算能力を削減する」と述べており、そこで選ばれた言葉は「ビデオ」なのです。

全プロセスの詳細解説

  1. 1:9のパターンが過剰暗号化を引き起こす最大値 3 ステップ

    スライスの暗号化率は10分の1をどこまで超えるのでしょうか? マクロブロック行ごとに1スライスを押してください。306バイトで、暗号文は10.46%になります。このページでは1回に1つのスライスを表示します。32バイトのヘッダを持ち、1,000バイト以上あるスライスのなかで、cbcsが暗号化する最大の割合を見つけてください。また、その最悪のケースがスライスの拡大とともにどのように縮小していくかを確認してください。

    この問題をツールで開く

    1. 割合は 16⌈B/10⌉/L になります。⌈B/10⌉ の値が維持される間は L が大きくなるにつれて割合が下がるだけなので、最悪のサイズとなるのは新しい暗号化ブロックがちょうど始まったタイミングです。つまり、保護範囲が正確に 10k + 1 個の完全なブロックを持ち、そのうち k + 1 個が暗号化されている状態です。

    2. そのサイズでは L = h + 16(10k + 1) となります。これを割り算し、10分の1の部分を切り離してみましょう。残った部分が10%の超過分であり、L に対する固定バイト数として表されます。

    3. h = 32 の場合、超過分は L に対して 11.2 バイトになります。1,000バイト以上で最初に最悪のサイズとなるのは k = 6 のときです。これは1,008バイトのスライス内に61個の完全なブロックがあり、そのうち7個が暗号化されるケースです。

    解答

    1,008バイト中の112バイトで、11.11%です。1,000バイト以上でこれより悪化するものはありません。超過分は 1/L として減少していくため、10,000バイト以上で最悪のスライスは10,128バイト時の10.11%となり、これが最初の解説で引用した範囲の上限にあたります。さらにこの数式は、どの長さのヘッダが過剰暗号化を終わらせるかも示しています。超過分は 16 − (h + 16)/10 バイトであり、これは h = 144 のときにゼロになります。つまり、平文ヘッダが144バイト以上あるスライスであれば、サイズがいくつであっても10分の1を超えて暗号化されることは決してありません。

参考文献 (3)