BitLockerのお話
2019.03.30
なんというか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のときはサードパーティーの暗号化ソフトでかつ解除キーは毎回手入力だったんですが・・・。
いいのかこれ？
基本的にはコールドブートアタックといわれる技法。
既にセキュリティホールとして報告も上がっている話。
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のときはサードパーティーの暗号化ソフトでかつ解除キーは毎回手入力だったんですが・・・。
いいのかこれ？
2019.03.30 01:47
| 
コメント一覧
wchdsk - 2019年04月19日 02:48
ありがとうございます。
おかげさまで無事に三つのFVEKを吸い出し出来ました。
Memory mapの問題で先日失敗してしまいましたが、
裕之さんの言う通り、LINUX自体がその部分を使うので無理です。ブート上何かしないと多分上書きされます。
何とか出来ました、本当にありがとうございました。
おかげさまで無事に三つのFVEKを吸い出し出来ました。
Memory mapの問題で先日失敗してしまいましたが、
裕之さんの言う通り、LINUX自体がその部分を使うので無理です。ブート上何かしないと多分上書きされます。
何とか出来ました、本当にありがとうございました。
裕之 - 2019年04月17日 22:20
少なくとも、初代Nu(1.1ではないほう)ではそのような挙動は見られませんでした。
1.1は持っていないので解りません。
Linuxを起動したり、UEFIブートすると、32bitモードで起動するので、MBR等でダンプするのが良いと思います。
1.1は持っていないので解りません。
Linuxを起動したり、UEFIブートすると、32bitモードで起動するので、MBR等でダンプするのが良いと思います。
wchdsk - 2019年04月17日 21:50
こんにちは
情報をご提供いただきありがとうございます。
一応NU1.1上、TPMを破れなく、リセットし、別のOSかUEFIプログラムをブートする方法が見つかりました、が
不思議なことに、できるだけ最小化のLinuxのkernelを使っても、最小限のメモリーを使うUEFIプログラムを使っても、FVEKが入ったはずのPAGEの内容がすべてリセットされている(0x00になている)ようです。
ゲームイメージのKey、SSLのKeyのようなものとか何回もキャッチしたが、一回もFVEKを見つけることができませんでした。
考えたうえ、リセットまたはリブートすると、BIOSが何かのメモリーリセット、チェックすることがありますか？これに関してヒントを教えていただければ幸せです。
よろしくお願いします。
情報をご提供いただきありがとうございます。
一応NU1.1上、TPMを破れなく、リセットし、別のOSかUEFIプログラムをブートする方法が見つかりました、が
不思議なことに、できるだけ最小化のLinuxのkernelを使っても、最小限のメモリーを使うUEFIプログラムを使っても、FVEKが入ったはずのPAGEの内容がすべてリセットされている(0x00になている)ようです。
ゲームイメージのKey、SSLのKeyのようなものとか何回もキャッチしたが、一回もFVEKを見つけることができませんでした。
考えたうえ、リセットまたはリブートすると、BIOSが何かのメモリーリセット、チェックすることがありますか？これに関してヒントを教えていただければ幸せです。
よろしくお願いします。
コメント投稿