アカウント名:
パスワード:
「(マニアックな方々の興味を引きそうな)一部のデータについてはROM上は簡単な暗号化を施して保持し、処理時にデコードしてRAM上に展開、処理が終わったら該当領域をクリアする」
WinDVDはまさにそんな仕様になっていて、それが突破口となってクラックされたのですが。
http://www.watch.impress.co.jp/av/docs/20070220/avt001.htm [impress.co.jp]
ちなみにWinDVDは128bitの鍵をメモリ上の連続したアドレスにそのまま配置していた上、鍵が不要になった時点でメモリ内容をクリアする処理を行なっていたそうだ。このため、メモリ内部のどこにProcessing Keyがあるか、メモリのモニタを行なっているだけで類推できるという、非常に単純なミスが原因での鍵流出劇だったそうだ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
毎度(なのか?)のパターン (スコア:1)
確かDVDのCSSも同じように間抜けな再生ソフトが原因でしたよね。
結局、機密を守るのにルールで何とかしようとしても無駄だということを改めて実感します。
BDの方も間抜けソフトが出るのは時間の問題?
こういうのの実装は難しい・・・ (スコア:5, 興味深い)
組込機器(DVD等ではない)開発をやってますが、規格やセキュリティ上必要なものについて仕様書を書いて実装をお願いしても、動作に影響しない場合、勝手に仕様から削除されていたり、簡略化されて骨抜きになっていたりすることが少なくありません。
特にブラックボックステストでの確認手段がない場合、実装が手抜きされていてもわからないので厄介です。チェックリスト等で実装していることを宣言させても、平然と嘘を報告してくる奴(末端だけではなく、マネージャレベルの確信犯も)もいるので危ないです。
PC用のプレーヤって狙われやすいから大変ね・・・。
Re:こういうのの実装は難しい・・・ (スコア:3, すばらしい洞察)
仕様書(特に表現)に問題があるか、仕様書からテストを作成する段階での
熟考が足りない(といっても仕様書の書き方がよくないためにそうなる
場合が多い)かですよ。ブラックボックステストで仕様の確認が不十分だ
というのはそういうことです。
組み込み系は短納期が多いですが、実装前の段階にもう少し時間を割く
ことをおすすめします。
Re:こういうのの実装は難しい・・・ (スコア:4, 興味深い)
例えば、クラックされたくない(組み込みですが、最近はJTAGポートが残っていたり、ファームウェアをアップデートできたりするので昔よりもリスクが高い)ので、製品としては、「(マニアックな方々の興味を引きそうな)一部のデータについてはROM上は簡単な暗号化を施して保持し、処理時にデコードしてRAM上に展開、処理が終わったら該当領域をクリアする」という仕様を定義したのですが、実際の実装は「デコード済みのデータをROMに保持」してしまっているといった具合です。
この時は、ソフトウェアのリーダーが「わざわざそんなクラッキングをする奴はいないので、デコード済みのデータで問題ないと判断した」という理由で勝手に仕様を変更して、デバッグ用に用意した平文データをそのままROMに保持していました。そのため、なんとなくROMイメージの検索をかけたら平文のデータが見付かったのです。
まあ、テスト仕様書に平文のデータをROMイメージ内から検索して見付からないこと、と入れてもいいのですが、確信犯でやられたらテスト仕様書に入っているかどうかなんて関係なくなってしまいますし、処理後のメモリクリアはモジュール設計担当者でなければ確認のしようがありません。理想をいえば、全ての実装を詳細レベルまで疑ってかかって、第三者によるブラックボックステストを定義して実施すればいいのでしょうが、(法規制や製品安全などは別にして)一般の民生品で製品の機能として見えない部分までそんなことをやってるところってありますかね?
結局、うちのソフトウェア開発管理者が、ハッカー/クラッカーを甘く見ている、ということだと思いますが・・・。
#最近はこの手のリスクのある仕様は、わざと仕様書のごく一部を欠落させたり、誤りを混入させておいて、質問が無ければ実装できない(=手抜きしようとするとわかる)ようにしているのは秘密です。
危険な仕様 (スコア:4, 参考になる)
WinDVDはまさにそんな仕様になっていて、それが突破口となってクラックされたのですが。
http://www.watch.impress.co.jp/av/docs/20070220/avt001.htm [impress.co.jp]
Re:危険な仕様 (スコア:0)
手法が判ってしまえば単純に見えるかもしれないけど、これってそんなに単純なミスかなぁ?
どこまで対策をしたとしても暗号化方式がわかっている(んだよね?)のであれば、処理内容は大筋では予測がつくわけで、仮に分散して配置したりクリアのタイミングをずらしたりしてもそれに対応したクラッキングに遭うだけのような気がします。(多少の時間稼ぎににはなるかもしれないけれど)
Re:危険な仕様 (スコア:0)
マルチタスク万歳な今の時代に使ったらだめだった、ということなのでは。
今回の暗号漏洩は (スコア:2)
正にこういう動きをするメモリ領域を探索する事によって発見されたそうなので
これが安全とは言えなくなりましたよ?
Re:今回の暗号漏洩は (スコア:0)
元サイト見る限りだと128bitのデータをそのままメモリ上に保持しているから見つかったとの事で
暗号化された鍵を誰でも複合できるならどんなセキュリティも破り放題だよなぁ
Re:こういうのの実装は難しい・・・ (スコア:1)
もっと上流の枠組みで対処したいが自分のコントロール範囲外、
上は意識レベルが低いので動いてもらえない。
仕方がないので小手先でも良いので自己防衛していると言うこと
ですね。
この手の問題はどうしても技術論だけでは対処できない場合が
あるのが頭の痛いところですね。実際、この騒動の元のソフトウェア
メーカは強いペナルティを課せられたわけでもないですし、
そういう結果を見れば、あの程度で済むのだと危機感を持たない
企業や組織も減らないでしょう。ただでさえ人ってリスクがあるのは
わかっていても、降りかかるまでは自分は大丈夫と考えがちに
なる傾向があるのにね。
#オフトピだなぁorz
Re:こういうのの実装は難しい・・・ (スコア:0)
Re:こういうのの実装は難しい・・・ (スコア:0)
Re:こういうのの実装は難しい・・・ (スコア:0)
そんな開発部隊潰れちまえとは思いますが。
Re:こういうのの実装は難しい・・・ (スコア:0, すばらしい洞察)
そいつがテストを端折ってるんなら、自業自得だろ?
Re:こういうのの実装は難しい・・・ (スコア:1, すばらしい洞察)
仕様書を書いたヤツとテストをするヤツを別にしろ、なんて話、
この業界では当たり前のことだと思ってたんだが。
#自分で作って自分でテストしましたから大丈夫!
#なんて話を信じるバカは普通いないけどな。
Re:こういうのの実装は難しい・・・ (スコア:1, 興味深い)
作る人と仕様書通りに動くかテストする人は別にした方がいいというのは同意。
Re:こういうのの実装は難しい・・・ (スコア:0)
上には上が、下は底なしまでいろいろいるようだからね、この業界。
Re:こういうのの実装は難しい・・・ (スコア:0)
Re:こういうのの実装は難しい・・・ (スコア:0)