FC2ブログ

AACS都市伝説を追う:BDAV編

11/06/11初稿

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

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


■BDAVとBDMV

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

 本稿では、特記なき限り「BDAV」のこととして記します(AACSディスクとして)。
 また、確認などに用いたBDAVディスクは「BD-RE」だけです。「BD-R」は所有していませんので…

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

・「Media Key」を発行しているのは誰か
 BDAVにおいては、「Title Key」と同じく、ディスクごとにAACSから「Media Key」が発行されることはないハズです。
 また、「ディスクのやりとりによって上位AACS機のAACSで書き換えられた元下位AACS機」が生成する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が持つ「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程度以降はゼロ詰めされている。上位AACS化後のレコーダが書き込む「MKB_RW.inf」は13KB程度だが、そのAACSを持っていたディスクの「MKB_RW.inf」のゼロ詰め前部分(13KB分)とバイナリ一致する。

・より新しいAACSバージョンの「MKB_RW.inf」を持つBDAVディスクを操作(編集・追記・削除で確認)すると、その「MKB_RW.inf」で本体内「Media Key(MKB)」を書き換える。具体的には、それ以降はその機体は操作したBDAVディスクの「MKB_RW.inf」とバイナリ一致する「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を持っているかも知れないが、“上位AACSへの自動書き換え機能”によってディスクの読み書き時に市場に流通しているより新しいMKBに書き換わっていく。新しいMKBは、運んでくるディスクがBDAVかBDMVかに関わらずバイナリレベルで同一である。

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

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


■BDZ-AT700の挙動いろいろ

・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追記:BDZ-V7での動作ですが、B-CASカードなしでもHDD上の録画は再生できました。HDD→BDへのダビングもできました。

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


■BDZ-AT700のF/Wまとめ

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

・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かの違いかも知れません。

・16/05/04追記:2機とも15/04/13付けで「18.3.022」にUpdate。V16のままです。


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

 本項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アナログ」のレベルまで徹底してますこと。今はもうアナログ出力自体が禁止されてますけど(苦笑)。


メインメニューへ

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

最新記事
ERIへようこそ

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

・ファイルへの直接リンク以外はリンクフリー(連絡不要)です

・一応、拍手にコメント(非公開)付けられるようにしてあります

・DB的に利用しており、過去記事もガシガシ書き換えています。特に「最新記事」は初稿から一週間くらいは直してることが多く、大幅に変わっちゃうことも。ご了承ください

・ということもありますし、記すまでもないですが無断転載(ファイル含む)はご遠慮ください

・引用の考え方については「007:諸事」をご参照ください

・アフィリエイトは「Amazon.co.jpアソシエイト」のみです

・ハイパーリンクは当Blog記事のみです(054:節電記事のみ例外)

カテゴリ
検索フォーム
FC2カウンター