日記β

ところで、メールくださいってコメントが何件かあるけど、
正直なところ、

だったら最初からメールしろよ！！！

と思っていたのですが、
このblogってTOPへのリンクもないし、メールアドレスの記載もないんですね・・・。

そりゃわざわざ手打ちでTOPに戻ってメールするとか面倒なことしないわ。
ってかTOPの存在すら気づかないわ。

あー、そのうち修正しますそのうち。
あと、フォームに入力されたリンクに正しく飛べないってのもそのうちなんとかします。

なんというかNuに限った話では全然ないのだが、この辺興味ある人が多いようで。

基本的にはコールドブートアタックといわれる技法。
既にセキュリティホールとして報告も上がっている話。


https://www.itmedia.co.jp/enterprise/articles/0802/22/news094.html
ディスク暗号化技術にセキュリティホール、研究者が指摘
さらに詳細はリンク先の論文読むべし。英語わかんないからちらっとしか読んでないけど。

結局のところ、稼働している状態のメモリの中身を覗ければ、そこからFVEKは導き出せるという話。
※というのが脆弱性。この脆弱性って回避できんの？って話は後で。

じゃあどうやって稼働してる状態のメモリの中身を見ようかというところ。

MSX2とか酷使したことある人なら(っていきなりそこか)、メインRAMにROMイメージを読み込んで、ハードリセットしてもイメージが起動するとか、電源を切っても数分は残ってるとか経験はあるはず。
ほら、そういう経験が役に立つわけですよ。


まあつまりリセットしただけではメモリ内容はほとんど失われない訳ですよ。
起動シーケンスで使われる部分は上書きされるけど、それはごく一部。

なので、起動中にSSDを差し替えてリセットすると、メモリ内にFVEKが残った状態で、メモリダンプツールとか起動できる。
この時点でSSDの変更が検出されてTPMのデータが消えて、次回以降正規のSSDは起動出来なくなるので一発勝負。

ちなみに、世の中にそんなツールがあるのかは知らない。
ただ、一つ言えることは、再起動後にOS(特にWindows)を起動した場合、デバイスドライバが読み込まれるメモリ上の場所というのは、ほぼ毎回変わらない。よって、OSを起動してしまうと高確率でFVEKは上書きされて消えてしまう。
なので、MBRにダンプツールを仕組むとかしないとまず無理。

あとはメモリダンプからどうやってFVEKを探し当てるかという話。
この辺も論文にわりと書いてあるけど、仮に実装メモリが1ギガだとすると、総当たりしても(FVEKは全バイト連続して格納されてると仮定して)たったの1ギガ個＝10億個のキーを試すだけ。256bit鍵=2の256乗(10進数で78桁)個とは比較にならないくらい少ない。

さらに、検証機で事前にBitLockerの動きとかを解析しておけば、どのあたりが怪しいかってのも見当を付けられるから、実際に試行するキーの数はもっと絞れる。たとえば00が連続してる場所とか明らかにキーじゃないでしょ。
ただこれはおそらく経験と勘。バイナリデータを眺めてなんか目印になりそうなものが見つけられるかどうか。
昔のROMカセット時代とかのファイルシステムの無いゲーム機とかのダンプを見て、ここはプログラムっぽいとかここはデータっぽいとか、そういうのを見分けられる経験と勘。
ほら、やっぱそういうどうでもよさそうな経験って役に立つわけですよ。

とまあ、そんな感じで稼働機からFVEKは取得できます。はい、論文から情報が1㍉も増えてない気もしますがわざとです。
FVEKの取得に関してはこれ以上深いことを書くつもりはありませんし、ツール公開もしません。



さて、ではこれを踏まえた上で、どうすることで安全にセキュリティを確保することができるか。

まず、現状のようにメモリ上に平文でキーが置かれること、これは確実にNGです。
少し難易度を上げると、メモリ上にも平文でキーを置かないこと、もしくは連続で置かないことです。
ただ、これもデバイスドライバの解析でアルゴリズムが解ってしまうので、手間増えるくらいで解析不可能ではありません。
きちんと対応するなら、ハードウェア対応でしょう。
鍵の生成自体をTPMチップで行って、SATA制御チップに暗号解除アルゴリズムを搭載するとか。
もしくは、SSD自体に高度な暗号機能を搭載するとか。
ちなみに、現状でもSSDに暗号化機能はATAの仕様としてありますが(RINGEDGEで採用されている奴です)、バス上にキーが平文で流れるので、ATAのプロトコルアナライザを使うと簡単に解除できます。
これをDH鍵交換みたいな手順でホストと交換したりするようになるとどうしようもないですね。
ハードウェアとしては仕様が決まればそんなにコストがかかる物では無いでしょうから、いずれはこんな感じになるんでしょうか。
もしかしたら最新に仕様を知らないだけで、すでにそういう物があるのかもしれませんが。




ところで仕事先のノートPCが最近Windows10にリプレイスされたときに、TPM+BitLocker(PIN無し)になったんですが、盗まれたりすると全然安心できないってことですね！！！
Windows7のときはサードパーティーの暗号化ソフトでかつ解除キーは毎回手入力だったんですが・・・。
いいのかこれ？

さてさて、文鎮化したとおもわれたNuですが、FVEKは取得できてますね。
OSパーティションの他にBitlockerがかかっているパーティションは2つ(つまり計3つ)あるんですが、
オートアンロック機能でブート時にOS以外も自動で解除されるんですね。
というわけで、必要な分のFVEKはすべて入手できました。
とすると、別に文鎮化したわけでは無く、起動しないだけで必要なデータはすべて残っていてアクセス可能なわけですね。
なので、特に新たなNuを仕入れてくる必要なないわけでした。

が、まあしかし、キーチップが消されるってのは怖いので。。。

なんか大量に出回ってるキー付きのNu SXを仕入れてみました。
まあこれもたぶんセキュリティ的には同じ構成のようで、SX用のキーチップをNuに刺しても普通に認識しますね。当然ゲームは起動しませんが。

で、Nuのセキュリティ関連の構造なんですが、
OSと一部データがBitLockerで暗号化されています。
ゲーム自体はBitLockerが掛かってないパーティションに、HDDイメージとして独自暗号化されたファイルがおいてあります。
NuのインストールDVDに入ってるアレです。
なので、NuSXから暗号化されてるゲームイメージを引き抜いてくることは誰でも簡単にできます。

そうなると、これをNu(SXではないほう)で起動できないかって話ですよ。
これが出来ればキーチップから解除キーを読み出して、ゲームイメージを復号する一連の流れに安心してデバッガとかかけれるわけですね。

・・・・がんばりました。



NuSXのゲームイメージの展開までは成功しました。
日本語のコメントがあるっていいですよね・・・。

まだ解析できてない部分が多々あるので、本命キーチップでやろうという気はまだしませんが、
これでキーチップのダンプとHDDイメージの復号処理の解析はかなり進みそうです。