アカウント名:
パスワード:
「(マニアックな方々の興味を引きそうな)一部のデータについてはROM上は簡単な暗号化を施して保持し、処理時にデコードしてRAM上に展開、処理が終わったら該当領域をクリアする」
WinDVDはまさにそんな仕様になっていて、それが突破口となってクラックされたのですが。
http://www.watch.impress.co.jp/av/docs/20070220/avt001.htm [impress.co.jp]
ちなみにWinDVDは128bitの鍵をメモリ上の連続したアドレスにそのまま配置していた上、鍵が不要になった時点でメモリ内容をクリアする処理を行なっていたそうだ。このため、メモリ内部のどこにProcessing Keyがあるか、メモリのモニタを行なっているだけで類推できるという、非常に単純なミスが原因での鍵流出劇だったそうだ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
毎度(なのか?)のパターン (スコア: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)
Re:こういうのの実装は難しい・・・ (スコア:0)
Re:こういうのの実装は難しい・・・ (スコア:1, 参考になる)
「オシロ等を使って直接信号取り込む」ようなことはやりにくくなってますね、
私の知っている範囲では。
バス上に鍵などのデータが出ないように鍵などはOCM上で処理したり、
製品用の基板ではテストピン立てられないように削減したり。
また、SoCの方もそれをサポートするような仕掛けがいろいろ入ってきてます。
OMAPあたり(だっけ?)だとセキュアフューズを焼ききることで、
一部の処理が(SoCとして)セキュアな状態で実行されるようになりますし。
まあ、私の知ってる範囲っていっても一部のメーカの
3G携帯電話と、デジタルTV対応レコーダの類くらいなんで、
開発の現場によってもピンキリだとは思いますが。
悪名高い :-) ARIBのデジタルTV規格書でも一定の基準を満たすように
規定されていますし、それがB-CASカードの発行条件にもなってるわけですが、
認定の際の評価方法がうまく機能していないと今回のAACSのような
状況になってしまうんでしょうね...
Re:こういうのの実装は難しい・・・ (スコア:0)
メーカーなので門外漢ですが…
仕様書を無視されたってそれだとQA監査で弾かれませんか?
#QA監査で弾かれたら製造移管できなくなります。
仕様書から削除するのも「契約内容の見直し」で
それなりの人が決裁者になってると思うのですが。
最悪、生産移管直前までに実現できなくても
生産移管決裁時に一応OK/NGの判断はされます。
#しょうがないからOKっていうのばっかりですが。
ソフトって生産までのプロセスが全然違うのかもしれないので素人考えです。
#ソフト込みのハードでも同じことはやってます。
Re:こういうのの実装は難しい・・・ (スコア:0)
Re:毎度(なのか?)のパターン (スコア:2, 参考になる)
Re:毎度(なのか?)のパターン (スコア:0)
Re:毎度(なのか?)のパターン (スコア:0)
? そんなことは別に… セキュアなVM(BD-Javaとは別)を実装すればいい話 途中のデータを外部プロセスから見られないようにするため
Vista以降のみ対応、ということになるかもしれないけど,まあそれはそういうものということで。
Re:毎度(なのか?)のパターン (スコア:0)
Re:毎度(なのか?)のパターン (スコア:0)
Re:毎度(なのか?)のパターン (スコア:0)
追いかけっこにはなるだろうけどCSSほど致命的じゃない。
Re:毎度(なのか?)のパターン (スコア:1)
それなりに影響があるってことじゃないですかね。
まぁ、将来再び漏れた場合のことを考えてだとは思いますが。
Re:毎度(なのか?)のパターン (スコア:1)
http://japan.cnet.com/news/ent/story/0,2000056022,20346867,00.htm [cnet.com]
将来的にこのキーは無効にされるんだろうな。
もち、アップデートを受け取ったら、動作確認のため 旧バージョンと diff を取るのは常識なんで、この問題でしばらく楽しめそう。
Re:毎度(なのか?)のパターン (スコア:0)
提供側の心配が延々と的中。
Re:毎度(なのか?)のパターン (スコア:0)
Re:毎度(なのか?)のパターン (スコア:0)