パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

HD-DVD暗号解除キーをめぐって大騒ぎ、Diggは炎上」記事へのコメント

  • > ちなみにクラックされた原因は、とあるメディアプレーヤの間抜けな実装にあったようだ。

    確かDVDのCSSも同じように間抜けな再生ソフトが原因でしたよね。
    結局、機密を守るのにルールで何とかしようとしても無駄だということを改めて実感します。

    BDの方も間抜けソフトが出るのは時間の問題?
    • by Anonymous Coward on 2007年05月06日 12時02分 (#1153103)
      こういうのを見ると思うのは、一見すると動作に支障のない機能はなかなかまともに実装されない、という法則です。
      組込機器(DVD等ではない)開発をやってますが、規格やセキュリティ上必要なものについて仕様書を書いて実装をお願いしても、動作に影響しない場合、勝手に仕様から削除されていたり、簡略化されて骨抜きになっていたりすることが少なくありません。
      特にブラックボックステストでの確認手段がない場合、実装が手抜きされていてもわからないので厄介です。チェックリスト等で実装していることを宣言させても、平然と嘘を報告してくる奴(末端だけではなく、マネージャレベルの確信犯も)もいるので危ないです。

      PC用のプレーヤって狙われやすいから大変ね・・・。
      親コメント
      • by heika (271) on 2007年05月06日 12時21分 (#1153112)
        それは……仕様書からテストをうまく作れていませんね。

        仕様書(特に表現)に問題があるか、仕様書からテストを作成する段階での
        熟考が足りない(といっても仕様書の書き方がよくないためにそうなる
        場合が多い)かですよ。ブラックボックステストで仕様の確認が不十分だ
        というのはそういうことです。

        組み込み系は短納期が多いですが、実装前の段階にもう少し時間を割く
        ことをおすすめします。
        親コメント
        • by Anonymous Coward on 2007年05月06日 15時06分 (#1153181)
          いくら仕様書を充実させても、それを無視されてはどうにもならないのですよ。
          例えば、クラックされたくない(組み込みですが、最近はJTAGポートが残っていたり、ファームウェアをアップデートできたりするので昔よりもリスクが高い)ので、製品としては、「(マニアックな方々の興味を引きそうな)一部のデータについてはROM上は簡単な暗号化を施して保持し、処理時にデコードしてRAM上に展開、処理が終わったら該当領域をクリアする」という仕様を定義したのですが、実際の実装は「デコード済みのデータをROMに保持」してしまっているといった具合です。
          この時は、ソフトウェアのリーダーが「わざわざそんなクラッキングをする奴はいないので、デコード済みのデータで問題ないと判断した」という理由で勝手に仕様を変更して、デバッグ用に用意した平文データをそのままROMに保持していました。そのため、なんとなくROMイメージの検索をかけたら平文のデータが見付かったのです。
          まあ、テスト仕様書に平文のデータをROMイメージ内から検索して見付からないこと、と入れてもいいのですが、確信犯でやられたらテスト仕様書に入っているかどうかなんて関係なくなってしまいますし、処理後のメモリクリアはモジュール設計担当者でなければ確認のしようがありません。理想をいえば、全ての実装を詳細レベルまで疑ってかかって、第三者によるブラックボックステストを定義して実施すればいいのでしょうが、(法規制や製品安全などは別にして)一般の民生品で製品の機能として見えない部分までそんなことをやってるところってありますかね?
          結局、うちのソフトウェア開発管理者が、ハッカー/クラッカーを甘く見ている、ということだと思いますが・・・。

          #最近はこの手のリスクのある仕様は、わざと仕様書のごく一部を欠落させたり、誤りを混入させておいて、質問が無ければ実装できない(=手抜きしようとするとわかる)ようにしているのは秘密です。
          親コメント
          • 危険な仕様 (スコア:4, 参考になる)

            by Anonymous Coward on 2007年05月06日 17時50分 (#1153249)
            「(マニアックな方々の興味を引きそうな)一部のデータについてはROM上は簡単な暗号化を施して保持し、処理時にデコードしてRAM上に展開、処理が終わったら該当領域をクリアする」

            WinDVDはまさにそんな仕様になっていて、それが突破口となってクラックされたのですが。

            http://www.watch.impress.co.jp/av/docs/20070220/avt001.htm [impress.co.jp]

            ちなみにWinDVDは128bitの鍵をメモリ上の連続したアドレスにそのまま配置していた上、鍵が不要になった時点でメモリ内容をクリアする処理を行なっていたそうだ。このため、メモリ内部のどこにProcessing Keyがあるか、メモリのモニタを行なっているだけで類推できるという、非常に単純なミスが原因での鍵流出劇だったそうだ。
            親コメント
            • by Anonymous Coward
              > 非常に単純なミスが原因での鍵流出劇だったそうだ。

              手法が判ってしまえば単純に見えるかもしれないけど、これってそんなに単純なミスかなぁ?
              どこまで対策をしたとしても暗号化方式がわかっている(んだよね?)のであれば、処理内容は大筋では予測がつくわけで、仮に分散して配置したりクリアのタイミングをずらしたりしてもそれに対応したクラッキングに遭うだけのような気がします。(多少の時間稼ぎににはなるかもしれないけれど)
              • by Anonymous Coward
                昔は、プロテクトがらみの領域は、使ったら消すのが当たり前だったような。
                マルチタスク万歳な今の時代に使ったらだめだった、ということなのでは。
          • by ko-ji.t (21285) on 2007年05月07日 19時02分 (#1153688)
            >「(マニアックな方々の興味を引きそうな)一部のデータについてはROM上は簡単な暗号化を施して保持し、処理時にデコードしてRAM上に展開、処理が終わったら該当領域をクリアする」

            正にこういう動きをするメモリ領域を探索する事によって発見されたそうなので
            これが安全とは言えなくなりましたよ?
            親コメント
            • ”平文で保持するのが問題”っていうのが話題の基本では無いのか?

              元サイト見る限りだと128bitのデータをそのままメモリ上に保持しているから見つかったとの事で
              暗号化された鍵を誰でも複合できるならどんなセキュリティも破り放題だよなぁ
          • なるほど防ぐために開発プロセスを見直すにはコストが掛かりすぎる。
            もっと上流の枠組みで対処したいが自分のコントロール範囲外、
            上は意識レベルが低いので動いてもらえない。
            仕方がないので小手先でも良いので自己防衛していると言うこと
            ですね。

            この手の問題はどうしても技術論だけでは対処できない場合が
            あるのが頭の痛いところですね。実際、この騒動の元のソフトウェア
            メーカは強いペナルティを課せられたわけでもないですし、
            そういう結果を見れば、あの程度で済むのだと危機感を持たない
            企業や組織も減らないでしょう。ただでさえ人ってリスクがあるのは
            わかっていても、降りかかるまでは自分は大丈夫と考えがちに
            なる傾向があるのにね。

            #オフトピだなぁorz
            親コメント
        • そうじゃなくて実装でもテストでも勝手に端折られて難儀しているのでは?
      • 実はオシロ等を使って直接信号取り込んじゃえば組込み系の方が狙い易かったりして
        • by Anonymous Coward on 2007年05月07日 1時39分 (#1153387)
          うーん、組み込み系でもセキュア性が要求される用途においては、
          「オシロ等を使って直接信号取り込む」ようなことはやりにくくなってますね、
          私の知っている範囲では。
          バス上に鍵などのデータが出ないように鍵などはOCM上で処理したり、
          製品用の基板ではテストピン立てられないように削減したり。

          また、SoCの方もそれをサポートするような仕掛けがいろいろ入ってきてます。
          OMAPあたり(だっけ?)だとセキュアフューズを焼ききることで、
          一部の処理が(SoCとして)セキュアな状態で実行されるようになりますし。

          まあ、私の知ってる範囲っていっても一部のメーカの
          3G携帯電話と、デジタルTV対応レコーダの類くらいなんで、
          開発の現場によってもピンキリだとは思いますが。

          悪名高い :-) ARIBのデジタルTV規格書でも一定の基準を満たすように
          規定されていますし、それがB-CASカードの発行条件にもなってるわけですが、
          認定の際の評価方法がうまく機能していないと今回のAACSのような
          状況になってしまうんでしょうね...

          親コメント
      • ソフトメーカーじゃなくて実体のあるものを作っている
        メーカーなので門外漢ですが…

        仕様書を無視されたってそれだとQA監査で弾かれませんか?
        #QA監査で弾かれたら製造移管できなくなります。

        仕様書から削除するのも「契約内容の見直し」で
        それなりの人が決裁者になってると思うのですが。

        最悪、生産移管直前までに実現できなくても
        生産移管決裁時に一応OK/NGの判断はされます。
        #しょうがないからOKっていうのばっかりですが。

        ソフトって生産までのプロセスが全然違うのかもしれないので素人考えです。

        #ソフト込みのハードでも同じことはやってます。
    • by Anonymous Coward on 2007年05月06日 13時22分 (#1153132)
      BDは、AACSだけだといずれ破られるだろうというのを既に見越していて、BD+という全く別のレイヤーで保護できるようになっています。現在出てるBDのコンテンツでは使われてはいなかったと思うけど、多分これをいい宣伝材料にされて、コンテンツ企業側もBD+の導入を真面目に考えるようになったんじゃないかな?
      親コメント
    • だからAACSは漏れることを前提としたシステムを作ってるんでしょう?
      追いかけっこにはなるだろうけどCSSほど致命的じゃない。
    • DRMに金払っても結局破られるんじゃ、、、、

      提供側の心配が延々と的中。
    • 前回(?)の流出元になったXing TechnologyはRealNetworksに買収されちゃいましたね。InterVideoもどっかに身売りするのかなぁ?

ソースを見ろ -- ある4桁UID

処理中...