アカウント名:
パスワード:
「（マニアックな方々の興味を引きそうな）一部のデータについてはＲＯＭ上は簡単な暗号化を施して保持し、処理時にデコードしてＲＡＭ上に展開、処理が終わったら該当領域をクリアする」
WinDVDはまさにそんな仕様になっていて、それが突破口となってクラックされたのですが。
http://www.watch.impress.co.jp/av/docs/20070220/avt001.htm [impress.co.jp]
ちなみにWinDVDは128bitの鍵をメモリ上の連続したアドレスにそのまま配置していた上、鍵が不要になった時点でメモリ内容をクリアする処理を行なっていたそうだ。このため、メモリ内部のどこにProcessing Keyがあるか、メモリのモニタを行なっているだけで類推できるという、非常に単純なミスが原因での鍵流出劇だったそうだ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
毎度(なのか？)のパターン (スコア:1)
確かDVDのCSSも同じように間抜けな再生ソフトが原因でしたよね。
結局、機密を守るのにルールで何とかしようとしても無駄だということを改めて実感します。
BDの方も間抜けソフトが出るのは時間の問題？
こういうのの実装は難しい・・・ (スコア:5, 興味深い)
組込機器（DVD等ではない）開発をやってますが、規格やセキュリティ上必要なものについて仕様書を書いて実装をお願いしても、動作に影響しない場合、勝手に仕様から削除されていたり、簡略化されて骨抜きになっていたりすることが少なくありません。
特にブラックボックステストでの確認手段がない場合、実装が手抜きされていてもわからないので厄介です。チェックリスト等で実装していることを宣言させても、平然と嘘を報告してくる奴（末端だけではなく、マネージャレベルの確信犯も）もいるので危ないです。
ＰＣ用のプレーヤって狙われやすいから大変ね・・・。
Re:こういうのの実装は難しい・・・ (スコア:3, すばらしい洞察)
仕様書(特に表現)に問題があるか、仕様書からテストを作成する段階での
熟考が足りない(といっても仕様書の書き方がよくないためにそうなる
場合が多い)かですよ。ブラックボックステストで仕様の確認が不十分だ
というのはそういうことです。
組み込み系は短納期が多いですが、実装前の段階にもう少し時間を割く
ことをおすすめします。
Re:こういうのの実装は難しい・・・ (スコア:4, 興味深い)
例えば、クラックされたくない（組み込みですが、最近はJTAGポートが残っていたり、ファームウェアをアップデートできたりするので昔よりもリスクが高い）ので、製品としては、「（マニアックな方々の興味を引きそうな）一部のデータについてはＲＯＭ上は簡単な暗号化を施して保持し、処理時にデコードしてＲＡＭ上に展開、処理が終わったら該当領域をクリアする」という仕様を定義したのですが、実際の実装は「デコード済みのデータをＲＯＭに保持」してしまっているといった具合で
危険な仕様 (スコア:4, 参考になる)
WinDVDはまさにそんな仕様になっていて、それが突破口となってクラックされたのですが。
http://www.watch.impress.co.jp/av/docs/20070220/avt001.htm [impress.co.jp]
Re:危険な仕様 (スコア:0)
手法が判ってしまえば単純に見えるかもしれないけど、これってそんなに単純なミスかなぁ？
どこまで対策をしたとしても暗号化方式がわかっている（んだよね？）のであれば、処理内容は大筋では予測がつくわけで、仮に分散して配置したりクリアのタイミングをずらしたりしてもそれに対応したクラッキングに遭うだけのような気がします。（多少の時間稼ぎににはなるかもしれないけれど）
Re:危険な仕様 (スコア:0)
マルチタスク万歳な今の時代に使ったらだめだった、ということなのでは。