90% を越えてもまだ鍵が見つからない。まだ最上位 4 bit が F の部分が手付かずで残っているとはいえ……覚悟だけはしておくことにしよう。
現実逃避として TMTO のテーブルサイズ分析。先週から動かしている乱数列生成関数の結果がたまってきたので、開始鍵数 v.s. ユニーク鍵数のプロットを書こうとプログラム作成。
とりあえず 10000 個の開始鍵に対してノード検出してツリーを書いてと考えていたのだけれども、それにはもう少し時間がかかるようなので、1000 個の開始鍵に対しての分析結果。果てしなく楽観的に 800 - 1000 までに増加したユニーク鍵（ノード間距離）と同じ割合でリニアにユニーク鍵が増えていくものと想定した場合、2^31 個の開始鍵 (テーブルサイズ約 40G) でどれだけの鍵空間を占有できるか。
結果は 19.7% で、目標としている 46% にはさっぱり届いてくれない。現実の鍵空間占有率はもっと低い数字になるだろうから、テーブルサイズ 40G では無理という結論になりそう。
近所のスーパーが 3/7 で閉店。不便になるな〜。
後 2・3 時間で 100% 到達しそうだけれども、鍵は発見されないまま。このまま見つからない場合は自動的にエラーチェック導入前の領域を未処理扱いにして再割り当て開始の予定。
初期調査領域リセット後も現在のスピードが維持できるようなら、今週末までには完了しそう。
以下、ありそうな可能性。
一応エラーチェック導入前の領域調査が終わるまでは完全敗北は決定しないとはいえ、既に気分は敗戦処理状態。
今日中に完全敗北が確定するかと思うと……正直逃げ出したい。
AVHDD クラックの失敗確定。何がいけなかったのだろう。一番可能性が高いのは C2 暗号では CPPM とか CPRM とか AVHDD とか用途別に S-Box を変更しているとかだけど…… DVD Audio / CPRM DVD-RAM 両対応の DVD レコーダとかもあるのにそんな面倒なことを果たして実行するのだろうか。
まあ DVD Video は CSS で暗号化されてるから、どのみち複数の暗号に対応しなきゃいけないので、もう１種類増えてもたいした問題ではないといえるのかもしれないけど。後は、AVHDD の場合だとチップ内で暗号化と復号が完結してるから、C2 暗号の標準とは違う実装でも問題にならないという可能性もあるんだけど、確かにあるんだけど、でも DVD Audio 対応プレイヤーとか CPRM DVD-RAM レコーダを製品として出荷してる松下がわざわざそんなことをするだろうか。（普通その辺は使いまわさないか？ 社内連絡が悪かったり、事業部間の確執とかがあるなら別だけど）
えーと、S-Box まで含めた総当りはやりません。以前 も書きましたが、256 の組み合わせだと正解の確率は 1/(256!) になるので。参加者の年齢が読めないので一応書いておくと ! は階乗という計算記号で、高校の数学（確率・統計）で教わります。256! は 256×255×254×……×1 という計算になりますが、試しに計算してみるとこりゃ駄目だと誰でも納得できると思います。
さらに S-Box に加えて松下の実装変更の可能性まで考慮してという話だと可能性はさらに爆発的に広がるので、手の付けようがなくなってしまいます。
今回の総当りに使用した S-Box および C2 のアルゴリズムは DVD Audio との一致という意味であればそれなりに自信の持てるものでしたので、まったくのガセだったとは思っていません。判断の根拠は明かせないのですが。
1/9 それでいいの？ の続報。どーやら こーゆー対策 をしてあげる必要があるらしい。
VirtualAlloc を使って、最初に R/W で領域を確保して、コード生成が済んだら ReadOnly に属性を書き換えてやればいいらしい。
対策を施さなければいけない側的には「さいってー」で、リバースエンジニアリング側には「さいっこー」といったところ。わたしゃそこまでマニアックなコードは（仕事でも）書いていないのでどーでもいー話ではあるのだが。
先週末の絶望から徐々に復活中。とりあえずエラーチェックに引っかかった ID からの報告ブロックを再調査開始する程度には元気が出てきた。エラーチェックに引っかかった ID 自体は 60 件程度とそれほど多くは無かったのだけど、報告ブロックを足し合わせると 17 万を越えてしまったので……手持ちの PC だけでやるべきかどうか迷っていたり。
どーせ鍵は見つからないのだから、一人で調べてた方が希望が続いていいかもという悪魔のささやきが聞こえてくるのも悲しいところ。それでも真・完全敗北までの猶予期間は５ヶ月にしかならないのだが。
暗号解読ができていれば手を付けないつもりだった面倒な手順に挑戦中。COPY FREE の暗号化データが保存されている HDD 領域に 1 COPY の暗号化データを上書きという手順を試してみる。
AVHDD の管理するコピー保護情報がテーブル領域にしかなく、HDD 内で使用する暗号鍵が一つのみの場合はこれで IEEE 1394 経由 PC 取り込みができそうな気がするのだけど果たして結果はどうなってくれることやら……。
昨日書いた暗号化コンテンツのみコピーを試してみたのだけれども、試行１回目は「i.Link 再生エラー」で一枚たりとも絵は出てくれなかった。今週末にかけてもう少し条件を変えて試してみるけど、結局駄目という結論になるかも。
ブラックリスト ID からの報告ブロック再調査は 水面下 で実行中。約 1500 block/day のペースでちびちびと進んでいたり。
将来の暗号技術に関する安全性要件調査 [IPA] 経由で Triple DES を巡る最近の標準化動向について [日本銀行金融研究会] へ。バースディパラドックスを読んだ直後「64 bit ブロック暗号では 2^34 の暗号文をサンプリングしておけば、高確率で任意の鍵とのマッチングが発生する」と誤解して狂喜したのだけれども、後から少し考えてみて「どれか一つは重複してる」の勘違いだと気がついた。
ちょっと考えれば納得できるし、全然パラドックスじゃないじゃーんと八つ当たり。Rec-POT から暗号文を 2^34 個取り出してやっと成功確率が 50% じゃ意味がないよなー。そもそも 2^34 個も暗号文取り出せないし。それはさておき、IPA の資料は PC ベースの分散 Brute Force を実行した人間としてはなかなか面白かったです。特に 34 ページの鍵探索価格性能表とか。
"Meet-in-the-Middle" の解説を探して「中間一致攻撃」で検索しても、引っかかるのは何故か誤訳の "Men-in-the-Middle" の解説のみ。えーごの解説探すしかないのかなー。
反省会スレッド 46 の「IV」が何を意味してるのかが判らなかったのだけど。DES の CBC なんかで使われる Initialisation Vector の略のつもりだったのかなぁ。つーか Spec を読めば判るとおり、C2 暗号の CBC にはそんなものはないのだが。アルゴリズムぐらい理解してから批判してほしい。
それと、エラーチェックすり抜ける不正クライアント（作ることは可能）で実効的な妨害をするのはかなーり大変なんだけど、その辺を理解した上で 237 はソース公開を否定してるのかなぁ。1/26 AVHDD crack[33] とかにチェック方法は書いてあるんで、試しに不正クライアントの作り方でも考えてみてください。正解は明日書きます。
240&242 - 0 点、241 - 100 点、249 - 0 点。やっぱり批判してる人は判ってない人だったのね。つーかさ、どんなロケット作って月に行こうかという話してる脇で、西に向かってずっと行けば月が沈む場所で月に行けるのに、ロケット作るなんてバカみてーとかわめき続ける人がいたら、邪魔だなーとか思ってバカにしたくなっても仕方ないと思いません？
もう一度、今度は詳細に、エラーチェック方法を書きます。クライアントからのブロック要求があった場合、サーバ側は次のようにエラーチェックデータを作ります。
クライアント側の動作は次のようになります。
クライアントからの結果報告を受け取ったサーバ側のエラーチェック手順は次のとおりです。
上記方法を回避するためにエラーチェック部分だけ計算する方法があれば、是非教えて欲しい。平文と暗号文だけから探索なしで鍵を見つける方法があるというのならだけど。
てなわけで、241 の方法のように、正規クライアントと同じ割り当てブロックの全探索を行って、ただし正解鍵だけは絶対に報告しないというタイプの不正クライアントは作れる。でも、それを実行する気になるか？
200 〜 500 秒かけてやっと１ブロック妨害（しかもそのブロックに正解が含まれてる確率は非常に低い）できるだけなんだが。
バカにされたと思わせずに、相手に間違いを認識させ、欠点指摘・改善提案をするならせめて説明＆ソース公開済み現行手法の理解はしておくべきだった、と気づかせるなどという技術はあいにく身に付けていないのですよ。てーか方法を理解せずに欠点指摘だの改善提案することが軽蔑されても仕方がないことだという覚悟を求めるのは間違ってるのでしょうか？
あー、バカにされたとだけ思わせて、欠点指摘・改善提案をするならせめて説明＆ソース公開済み現行手法の理解はしておくべきだった、と気づかせることには失敗してるわけだから、私もまだまだだな。
なんでこの説明でも理解してくれないのだろう……。270 へ、Uncheatable Distributed Computations が検証アルゴリズムの考案元です。
反省会 スレッドが明後日の方向に突き進んでしまっているけれども、アレはアレで面白いから、あのままでもいいのかもと思ったり。
さて本題。デジタル放送でのコピー保護の概要とか C2 クラックの位置づけとかの解説。その辺判らないままに参加していた人もいるようなので。
上の図はデジタル放送の機器構成例の中で、同じコピー保護の仕組みが使われている範囲を色分けしてみたもの。放送波からチューナまでの間は MULTI2 暗号が使われていて、チューナと D-VHS 等の間での i-Link 接続では M6 暗号が、D-VHS 等の録画機器の中ではそれぞれに独自の保護技術が使われている。
この３段階のどれか一つでもクラックできれば、デジタルコピー保護をすり抜けることができる。C2 クラックはこの中の Rec-POT で使われているという触れ込みだった C2 暗号の鍵発見を目指したものだったのだけど、結果は残念なことに失敗に終わってしまった。
私以外にも、この手のものに挑戦しているひとは居るけれども、今のところ成功例らしきものが聞こえているのは、チューナ内部で MULTI2 のデコードチップと MPEG-2 CODEC の間の配線から TS を盗聴するというアプローチと、MULTI2 と M6 暗号の開発元である某 H 社の D-VHS ファームウェアバグを突いて D-VHS テープ内のコピー保護情報を読まなくしてしまうアプローチだけとなっている。
昨日の続き。３段階ある各種保護技術のうちクラックによるメリットが一番大きいのは放送波の暗号化 (MULTI2) を解読してしまうこと。これが可能ならば、有料放送の無料視聴や NEVER COPY コンテンツの記録すらできるようになる。DTCP のクラックや、記録デバイスのクラックでは、無料放送や正規購入済み有料放送であるにもかかわらずアクセス制限がかけられているコンテンツの制限解除しかできない。
その次にメリットが大きいのは DTCP のクラック。これが可能であれば、i-Link 接続機器全てでアクセス制限を無視した自由な利用ができるようになる。記録デバイスのクラックは同じ機器を所有していない場合に意味がなくなってしまう。
C2 クラックは一番メリットの低い、無料放送か正規購入済み有料放送のアクセス制限解除しかできず、その機器を所有していない人には意味のない、記録デバイスのクラックに位置している。
一昨日からの続きで今回はクラックの難易度について。MULTI2 はブロック長 64 bit 鍵長 64 bit のブロック暗号なので、総当りにかかる時間は C2 クラックの約 256 倍。M6 はブロック長 64 bit で鍵長 40〜64 bit (暗号アルゴリズム的には可変) なので、総当りにかかる時間は鍵長に依存するのだけれども、DTCP 上では 56 bit 鍵で運用されているらしいので、その場合は C2 クラックと同程度の時間で完了する。
実際 MULTI2 に関しては ARIB STD-B.25 や特許・ISO 規格などでアルゴリズムが公開されていて C でサンプル実装を作っている方もいるのだけど……、問題となるのは MULTI2 の暗号文をどうやって入手するかという点。MULTI2 で暗号化されたストリームを入手するだけでもハードウェア改造が必要になるので、私には無理という話になる。暗号文を入手できない以上、それを解読することも不可能。
M6/DTCP の方だと多少現実的になり、1394 バスアナライザ等でパケットキャプチャを行えば暗号文と通信パラメータの入手はできる。ただし、対応平文を入手することができない。もちろん MPEG-2 TS はかなり特徴的なフォーマットなので、暗号文単独でもアルゴリズムさえ判っていれば鍵推定は不可能ではないのだけれども、平文・暗号文ペアが入手できる場合と比較すると 100 倍から 1000 倍程度の計算量が必要になってしまう。また、DTCP では 1 セッション毎にランダムな個別の鍵が使用される (鍵交換には Diffie-Hellman が使われる) ので総当りでの鍵推定を行ったとしても、別のコンテンツではやり直しという話になってしまう。
AVHDD の場合、暗号文は ATA 経由フルダンプで当然入手可能なのに加えて、11/30 AVHDD crack [5] のような手段で平文の入手も可能なため、アルゴリズムさえ判明していれば総当りが実行できる。また、暗号文を改変しての選択暗号文攻撃などのアクティブな攻撃が可能なので、クラッカー側にとってはもっとも有利な立場に立てるデバイスと言える。（それでも敗北した訳なのだが）
SmartVision BS は確保済みなので、TS 線引き出しへの挑戦資格は一応満たしている。一応満たしているのだが……AVHDD 方面でもう少し頑張ってみる予定。
全 CBC ユニットの終端 64 bit ブロックを all 1 で埋めてみて、バースデイパラドックスが確認できるかとか、望み薄だけれども、統計的な偏りが出てないかとかの調査予定。暗号アルゴリズム推定ができればラッキーぐらいの気持ちで。
メモ： Mod n Cryptanalysis, with Applications Against RC5P and M6。google 経由で M6 暗号を調べているときに発見。DTCP の M6 暗号にアルゴリズム的攻撃をかけてみたという論文っぽいのだけど、眺めてみただけなので詳細は不明。
２週間ほど更新が止まります。