AACS都市伝説を追う:BDAV編

11/06/11初稿

 なにせよく解らないAACS(特にBDAVの)。これまでいろいろ調べたり実験したりしてきましたが、やっとひと区切りつきそうなのでまとめておきます。
 ちなみに、「BDAV編」と銘打っていますが、それは誤解なきようにするためでして、おそらく「BDMV編」を書くことはないと思います。

 「=PCを使った新世代AV(AudioVisual)をすちゃらかに楽しむ!=」とか言っておきながら初めてのVisualネタ(笑)。


■BDAVとBDMV

 まず、世の中のAACSに関する情報はほとんど前置きなく「BDMV」のことを語ってるようですが、「BDMV」と「BDAV」では若干事情が異なるという点に注意する必要があると思います。だってBDAVではレコーダがコンテンツ作るワケですから。

 本稿では、特記なき限り「BDAV」のこととして記します(AACSディスクとして)。
 また、確認などに用いたBDAVディスクは「BD-RE」だけです。「BD-R」は所有していませんので…
 加えて、「P-MKB」が書かれたBDAVディスクを使ったことはありません。

 さて、まずは本田雅一氏の記事をとっかかりに。
http://www.watch.impress.co.jp/av/docs/20070220/avt001.htm

 上記記事を簡素化すると、BDMVでは

・タイトル ・・・コンテンツホルダーが設定する「Title Key」で暗号化されている。

・Title Key・・・AACSが発行する「Media Key」によって暗号化されてディスクに格納されている。

・Media Key・・・「MKB(Media Key Block)」という形でディスクに格納されている。
         MKBを「Device Key」によってProcessingすることで得られる。

・Device Key・・・AACSがデバイスベンダに発行する。再生装置側に内蔵されている。
         家電はさておきPCのソフトプレーヤなどでは漏れる危険性があるので、
         定期的に変更することが義務付けられている。

という仕組みのようです。

 それを参考に、BDAVの場合についてAACSのDocumentなどひもときながら…
http://www.aacsla.com/specifications/specs091/AACS_Spec_Recordable_0.91.pdf

AACSレコーダ動作
 出典:AACS_Spec_Recordable_0.91.pdf


■レコーダの暗号化プロセス

・「Title Key」を決めているのは誰か
 上にも記したように、BDMV(セルBD)と異なりBDAVではレコーダがディスクメディアを作成します。
 レコーダ自体がコンテンツホルダーの位置づけになってしまうので、暗号化もレコーダが実施しているハズです。放送波のスクランブルそのままとは思いがたいですので。
 ということは、レコーダが「Title Key」をタイトルごとに設定していると推定されます(レコーダごとに全部同じ、などの簡易運用はAACSルール上考えにくい)。

・「Media Key」を発行しているのは誰か
 BDAVにおいては、上記と同じく、ディスクごとにAACSから「Media Key」が発行されることはないハズです。
 また、「感染源と被感染機の生成するMKB_RW.infがバイナリ一致する」といういわゆる“AACS感染”現象の特徴から、(AACSバージョンが変わらなければ)あるレコーダが利用する「Media Key」はずっと同一のものになるようです。

・プロセスまとめ
 上記推定と各種実験を行ったところ、以下のような仕組みになっているようです。
 実験機は主にSONY製BDZ-AT700です(ファームウェアは「18.1.010」と「18.3.012」が混在していますがご了承ください)。

・タイトルごとにレコーダ自らユニークな「Title Key」を設定する。

・「Title Key」を用いてタイトルを暗号化する(ダビング10で同じタイトルを同じディスクにダビングしても違う「Title Key」で暗号化されている。つまり同じタイトルでも記録されたデータはバイナリレベルで異なる)。

・本体内の「Media Key」および「Binding Nonce」を用いて「Title Key」を暗号化(Encrypt)する。

・「Encrypted Title Key」をディスクに書き込む。\AACS\AACS_av\Unit_Key_RW.infに書かれている。
 ディスク上に複数のタイトルがある場合は複数のKeyが書かれている。
 HDD側で編集するなどして1タイトルだが複数ファイルある場合も、それぞれ別のKeyで暗号化されている。

・「Binding Nonce」をディスクのProtected Areaに書き込む。

・本体内の「Media Key」を格納したMKB(Media Key Block)を「MKB_RW.inf」としてディスクに書き込む。

・「暗号化タイトル」をディスクに書き込む。

 ただし、ディスク上にすでに「MKB_RW.inf」が存在する場合の挙動は後述します。

*「Binding Nonce」とは乱数データで、あるディスクのある状態に固有の数値です。
 実際の格納場所は「Unit_Key_RW.inf」の先頭領域らしいです。
 PCドライブでここを読む時はアクセス要求するソフトウェアと(たぶんソフト=Hostが持つ「Host ID」を用いた)認証が成立する必要があります。PCドライブ内のHRL(Host Revocation List)によって認証拒否される現象がいわゆる“Revoke”(の一種)。


■プレーヤの再生プロセス

・ディスク内の「MKB_RW.inf」を自ら持つ「Device Key」を用いてProcessingして「Media Key」を得る。

・「Media Key」および「Binding Nonce」を用いてディスク内の「Encrypted Title Key」を解いて「Title Key」を得る。

・「暗号化タイトル」を復号する。

*さらに「ディスク固有のID=Media ID」を用いて、再生時に“このファイル群はこのディスクに記録されたもの”であることを確認しているようです。DVDの時代からディスクまるごとコピーしてもダメなプロテクト技術として、ファイルシステムでは読めずかつ書き換えできないディスクユニークIDが使われているので、その一例かと思います。

*家電レコーダやプレーヤの個体「Device Key」は変更されることはありません(ソフトウェアプレーヤは逆に変更が義務付けられている。ちなみにPS3もソフトウェアプレーヤの位置づけらしい)。
 市場には複数の「Device Key」が存在し、増え続けます。「MKB」も新旧入り乱れて数多あり、増え続けます。
 AACSの仕組みはここがミソで、

  ・AACSから発行される「あるMedia key」を格納した「MKB」は、数多ある「Device Key」のどれで
   Processingしても同じMedia Keyが得られる。
  ・逆に、ある「Device Key」では解けない「MKB」を作ることができる(Revoke)。
  ・この仕組みは既発行・未発行の「MKB」「Device Key」の組み合わせで矛盾ないように運用できる。

 これがAACSバージョンアップであり、これによって、漏洩した「Device Key」を使う再生機器では再生できないメディアを作ることができると理解しているのですが、暗号化理論の仕組みは難しくって、はっきりイメージできていません。本田雅一氏の記事にある通り、実際にはもっと複雑なプロセスなハズですが、素人にはついて行けないのでこのくらいで…


■ディスクのAACSバージョンが上がるとなにが起きているか

 ディスクが上位AACSにいわゆる“感染”すると、ディスク内の「MKB_RW.inf」が書き換えられます。つまり、復号に必要な「Media Key」が変わっちゃうワケです。とすると、「旧Media Key」で暗号化されたタイトルはどうやって再生できるようにしているのか? が、いままでよく解らなかったのですが、やっと解った気が。

 AACSバージョンを上げる前と後のディスクの中身をHDDにコピーしてマジマジ比較してみました。
 MKB_RW.infは、ひとつであることに変わりはありませんが当然中身が変わっています。そして、よく見るとさらに「Unit_key_RW.inf」の中身が変わっていました。旧AACSバージョンで暗号化されたタイトルには、「新しいEncrypted Title Key」が設定されているようです。
 つまり、「新Media Key」でも(「旧Media Key」で解けていた「Title Key」に)解ける「新Encrypted Title Key」を新たに生成し、書き換えているようです。

 AACSバージョンが上がる際、もともとディスク上にあったタイトルのm2tsファイル本体は再暗号化などはされませんので、つまりそのタイトルの「Title Key」も変わっていないことになります。変わったのは「新Media Key」でも解けるように“再暗号化”した「新Encrypted Tilte Key」だけ、ということだったのですね。


■レコーダはAACSバージョンをどう操作しているか

 本体オリジナルAACSバージョンがV16のSONY製BDZ-AT700の挙動確認結果です。

・フォーマットすると以下のようなフォルダと1ファイルが書かれる。
 対象がヴァージンメディアではなく書き込み使ったディスクでも、フォルダの中にはMKB_RW.infも含めファイルはない(隠しファイル・フォルダを表示する設定で確認)。
   AACS
    AACS_av
   BDAV
    CLIPINF
    PLAYLIST
    STREAM
    info.bdav

・フォーマットではなくタイトル全削除でも「MKB_RW.inf」を削除する。つまりタイトルがない状態のディスクには「MKB_RW.inf」を存在させない。

・V16未満のディスクを再生しても、ディスクのAACSバージョンは書き換えない。

・V16未満のディスクの操作=追記・削除・編集(チャプタ削除)すると当然オリジナルV16化する。

・オリジナルとは異なるV16ディスクを操作(追記・編集・削除・ムーブバック)すると、暗号化は本体内オリジナルではなくディスク上の「MKB_RW.inf」を使って行い、オリジナルV16には書き換えない。また、本体の「Media Key(MKB)」も書き換えない(ムーブバックしても書き換えない)。

 最後のは興味深い挙動ですね。本体とディスクの「MKB」が“Media Keyは異なるがAACS世代としては同一バージョン”だった場合、本体側もディスク側もAACS操作は行われないようです。
 Windows7なら、エクスプローラでドラッグ&ドロップするだけでAT700でフォーマットしたディスク(BD-RE)に「MKB_RW.inf」を書き込みできます。そうやって作成したディスクで、AT700のこの挙動を確認しました。すでに存在する「MKB_RW.inf」を上書きしてもOKです(上書き前のMKB_RW.infで暗号化されてるタイトルはもちろん再生不能になりますけど)。skuは「HomePremium SP1 64bit」です。
 ムーブバックを含め、オリジナルV16と異なる挙動は確認できていません。

 ちなみに、ファイルフォーマットはBD-REがUDF2.5、BD-RはUDF2.6です。WindowsVistaではUDF2.5までのサポート、Windows7でUDF2.6もサポートされたようです(R/Wとも。ただBD-Rは持ってないので未確認)。BD-REをライタに入れるとUDF2.5でのフォーマットが選択できます。というかそれしか選べないけど。

 さて、以下は本体オリジナルAACSがV1だったSONY製BDZ-V7での経験からです。

・より新しいAACSバージョンのBDMVを読むと、その「MKB_RW.inf」で本体内「Media Key(MKB)」を書き換える。
 あるV3のBDMVを再生したことでV1→V3になった。
 BDMVの「MKB_RW.inf」のファイルサイズは1024KBだが、13KB程度以降はゼロ詰めされている。感染後のレコーダが書き込む「MKB_RW.inf」は、感染源の「MKB_RW.inf」のゼロ詰め前部分とバイナリ一致する。

・より新しいAACSバージョンの「MKB_RW.inf」を持つBDAVディスクを操作(編集・追記・削除で確認)すると、その「MKB_RW.inf」で本体内「Media Key(MKB)」を書き換える。具体的には、それ以降は感染源とバイナリ一致する「MKB_RW.inf」を用いるようになる(ディスクに書き込まれる「MKB_RW.inf」が同バイナリになる)。
 V4のBDAVに追記を行った際にV3→V4になった事象にて確認。

・12/01/03追記:BDZ-AT700で焼いたV16のディスクをマウントしたらV4→V16になった(MKB_RW.infはAT700作成のものとバイナリ一致)。つまり「より新しいAACSバージョンの~」はBDMVだけでなくBDAVでも同様の模様。

・より古いAACSバージョンのディスクにAACS暗号化されていないタイトルを追記してもAACSバージョンを上げる。

・12/01/09追記:これだけBDZ-V9の動作。AT700で記録に用いて一度V16になったことのあるディスクをAT700でフォーマット。そのディスクをV9でフォーマットせずにタイトル書き込みした結果、本体MKBはV4→V4のままだった。


■改めてBDMVとBDAV

・BDMVではAACSがコンテンツホルダーに「MKB」を供給するが、BDAVではコンテンツを作るのはレコーダであるので、出荷当初こそ同じくAACSから供給されたオリジナルの「MKB」を持っているかも知れないが、“感染”によって市場に流通している「MKB」に書き換わっていく。それは感染源がBDAVかBDMVかに関わらずバイナリレベルで同一のMKBである。

・AACSバージョンが変わらない限り、あるレコーダで用いられる「Media Key」は同じである。

・BDMVではコンテンツホルダーが「Title Key」を設定しているが、BDAVではレコーダがタイトルごとに違う「Title Key」を設定している。

  ←BDZ-AT700    ←こちらAT500


■おまけ:BDZ-AT700の挙動いろいろ

・「P-MKB」を書きません(BDZ-V7もV9も書きませんでしたが)。
 AACS文書でも「Option」になってますので書かなくてもいいんですね。

・ムーブバック対応の放送波アップデート(末尾「012」が該当)後もオリジナルV16を維持しています。BDZ-V7やV9もアップデートでAACSバージョンが上がったことはありませんので、少なくともSONYはそういうコンセプトのようです。
 次モデルはV20くらいになるのでしょうか…
 アナログHD出力もできなくなりますしね。
 11/12/31追記:その後の「18.3.015」アップデート後もV16維持を確認しました(MKB_RW.infはバイナリ一致)。

・BDZ-V7/V9世代ではHDD上でチャプタ削除などするとひとつのタイトルでもディスク上では複数のファイルに分割されていました。ディスク上での編集では割れなかったのですが。その点、BDZ-AT700ではディスク上編集はもとよりHDD上編集でも分割されなくなっています。ある意味らっき~
 12/02/05追記:なんとなんと、V7/V9世代でファイル分割されちゃったタイトルをAT700にムーブバックしてBDに書き戻すと、1タイトル1ファイルに結合してくれるぢゃありませんか。期待してなかったのでちょっと驚きました。ある意味らっき~
 15/01/05追記:逆にAT700で「タイトル分割」したタイトルは、ファイルとしては割れていませんでした(苦笑)。

・ディスクにダビングした時間順にタイトルを連続再生します。BDZ-V7/V9世代ではタイトルごとに停止していました。
 この機能、「ダビングした時間順」というところがミソで、HDDへの録画時間順ではありません。なので、例えば第1話より先に第2話をダビングしちゃうとタイトルの連続再生順は逆になってしまいます。同時ダビングでなくても同じ動作のようです。また、念のためBDZ-V7/V9で作ったディスクでも確認したところ連続再生しましたので、ディスク作成仕様ではなくプレーヤとしての挙動と考えてよいと思います。よしあしあるのでON/OFFできるようにして欲しかったですね。

・11/12/31:実はもう1台買ってあったAT700を設置しました。初期ファームは「18.1.012」末尾3桁はムーブバック対応バージョンでした。シリアル13,000ほど違うのですが、その間に出荷時バージョン変わったようです。気になるAACSは1号機と同じくV16でした(MKB_RW.infはバイナリ一致)。
 12/01/01の昼にはまだ放送波Updateされていませんでしたが、12/01/02昼に確認したら「18.3.015」になってました。1号機でも初期ファームは「18.1.010」でしたが最初の放送波Updateで「18.3.012」になってましたので、「1」と「3」はデフォか出荷後のUpdateかの違いかも知れません。

 なかなかいい子です。

・11/12/31追記:BDZ-V7での動作ですが、BCASカードなしでもHDD上の録画は再生できました。HDD→BDへのダビングもできました。

・12/09/01追記:AT700、何故かXMBなどの「放送局アイコン(ロゴ?)」が表示されなくなってしまったので(2台のうち1台だけ)どうしたものかと思っていたのですが、本体前面のリセットスイッチ押したら直りました。電源OFFでHDDも回っていない状態で押したら「PLEASE WAIT」表示になって2分ほどがっこんがっこんやって電源OFF状態に戻りました。HDD上の録画や留守録設定などが消えたりはしておらず問題なさそうです。

・12/06/17追記:AT700、2機とも12/05/30付けで「18.3.017」にUpdateされました。AACSはV16のままです。
・13/03/02追記:AT700、2機とも12/10/24付けで「18.3.018」にUpdateされました。AACSはV16のままです。
・13/03/25追記:AT700、2機とも13/03/13付けで「18.3.019」にUpdateされました。AACSはV16のままです。
・13/10/26追記:AT700、2機とも13/09/11付けで「18.3.021」にUpdateされました。AACSはV16のままです。
・16/05/04追記:AT700、2機とも15/04/13付けで「18.3.022」にUpdateされました。AACSはV16のままです。


■ディスク相性問題

 本項14/12/07追記。
 同時に購入した5枚組Verbatim(三菱化学)製BD-RE DL、AT700と相性問題? があるようです。
 購入当時、27GBくらいのタイトルを書き込み、とある事情でムーブバックしてさらに書き戻したら2層目がエラーで読めなくなりました(途中停止してハングしたようになる)。
 人生最初の25GB超タイトルのディスク処理であえなく玉砕(苦笑)。もちろんメディアもおろしたてでした。
 何度か同じような確認を行って問題出なかったので“たまたま”なのか、またはファームが対応できてなかったのかなと思い2枚目以降はおっかなびっくりながら使ってました。
 といってもHDD容量削減のための一時的待避が主目的です。昨日、そろそろ1層メディアに保存しなおす作業しようかと思い立ち、ムーブバックしようとしたらエラーで停止してしまいました。何事もなかったように終了(HDDには何もなくディスクから削除はされていない)していて、最初は何が起きたか判りませんでした。最初の1枚は封印してましたので、それ以外の3枚で、です。ちなみに特筆するような回数の繰り返し使用はしていません。

 2枚目は複数タイトル記録していたのですが、全選択ムーブバックは新しい順に行われるようで、エラーした時点で終了しちゃうようです。問題タイトルを選択しなければムーブバックできました。
 3枚目と4枚目は25GB超のワンタイトルです。3枚目はPCで再生しようとしても半ハングのような状態になりましたが、4枚目は映像が乱れて再生されました。発生するのはバイト読みで22GBあたりですので、明らかに2層目への切り替わりポイント周辺です。

 どうしてくれようかと悩みましたが、試しに別のAT700でムーブバックしてみたところ、3枚目はやっぱりダメでしたが4枚目は成功しました。ならばと3枚目もやり直してみたら、2回目で成功。あきらめなくてよかった(笑)。
 3枚目は、PCでもBDR-S05Jだと映像止まるほどでしたがSW-5583だと乱れはするものの再生可能でしたので、ドライブ性能差や同じドライブでも“暖まり具合”などによって読み取り能力は変動するようです。

 試しに複数タイトルを記録している5枚目もムーブバックしてみましたが、やっぱり層切り替えを含むであろう位置にあるタイトルで失敗しました。リトライ5回目くらいで読めましたが… CDのリッピングかよ!(苦笑)
 多層メディアやっぱアブナイなぁ… レコーダとメディアどっちの問題なのか、どっちも問題なくて相性的なハナシなのかは解りませんが。
 BD-RE DLはPanasonic製しか流通していないと勘違いしていてVerbatimブランドを買っちゃったんですけど、ID読んでみたらVerbatim製でした。
 層切り替えのあたりに敢えてダミータイトルを記録して使う…なんてメンドクサイですよね(笑)。

 さて、ということもありXLには手を出していなかったのですが、この経験で、ふと「1層33GBの大容量メディア」と見なせるのでは? と思い付きました。33GB超の“連続再生しないと価値がないコンテンツ”を録画することはあまりないでしょうから(WOWOWの映画などでも30GBくらいかと)、たまにある25GB超(33GB以下)のコンテンツ録画用に使うっていうのはアリかも知れません。



 まあ、素直にDR諦めてAVCモード使えばいいんでしょうけれど。


■アナログ出力のコピー制御

 本項16/08/04追記。
 AT700にはまだアナログ出力がありますが、どんな制御されているのでしょうか。

アナログ映像出力にはCGMS-A(Copy Generation Management System - Analog)と呼ばれるコピー制御信号が付加されています。対応する録画機を接続してダビング10対応番組の映像をコピーした場合、一世代までに限定されます。二世代目、いわゆる孫コピーはできません。
出典:https://www.apab.or.jp/receiver/pdf/dubbing10_qanda_0903.pdf

 ダビング10状態のコンテンツのアナログ出力(事実上コンポジットかS端子のSD出力)はダビング回数にカウントされないので何度でも録画できますが、そのビデオ信号には「コピーワンス(その出力はコピー不可)」情報が付加される仕組みのようです。なのでそのアナログ出力はもう録画できません。走査線ブランク期間にマーク埋め込んでるようですね。
 BDなどに一度でもダビングしたコンテンツはコピーワンス状態になりますので、そのアナログ出力は録画はできません。
 ただし、録画機がCGMS-Aに対応していないと機能しないのは言うまでもありません。対応してないとCGMA-A信号を無視しちゃうでしょうけれど、かなり昔から搭載されてるような気がします。

 「SDアナログ」のレベルまで徹底してますこと。今はもうアナログ出力自体が禁止されてますけど(苦笑)。


 「PC編」に続く!


メインメニューへ

テーマ : オーディオ・ビジュアル
ジャンル : 趣味・実用

ERIへようこそ

Author:らかせ
 「最新記事」または「メインメニュー」からどうぞ

・ファイルへの直接リンク以外はリンクフリー(連絡不要)です
・一応、拍手にコメント(非公開)付けられるようにしてあります
・DB的に利用しており、過去記事もガシガシ書き換えています。特に「最新記事」は初稿から一週間くらいは直してることが多く、大幅に変わっちゃうことも。ご了承ください
・ということもありますし、記すまでもないですが無断転載(ファイル含む)はご遠慮ください
・引用の考え方については「007:諸事」をご参照ください
・アフィリエイトはAmazonのみです
・ハイパーリンクは当Blog記事のみです(054:節電記事のみ例外)

最新記事
カテゴリ
検索フォーム
FC2カウンター