まずは、例え話から始めたいと思う。
あくまで例え話であり、第二の謎「Intel® TXT」とは異なるのでご注意を。
当然、皆さんはウィルス対策ソフトを使っていると思う。
ウィルス対策ソフトをインストールして、ウィルス定義ファイルのアップデートアップデートをしていれば絶対安心だろうか？
結論から言えば「NO」である。
まず、定義ファイルの提供されていない未知のウィルスに関しては防ぎようがない。
そして、ウィルス対策ソフトはソフトウェアというものの特性上、書き換えが簡単に行える。
例えば、ウィルス対策ソフトを掻い潜ったウィルスが、ウィルス対策ソフトを改ざんして、見た目は正常に動いているように繕っていても、実際には何もしないソフトに書き換えられてしまったとしたら。
ウィルスに感染したアプリケーションをダウンロードしてきても、ウィルス対策ソフトは何も言わない。ユーザーはそれを信じてウィルス感染したアプリケーションをインストールする。
まさに、負の連鎖である。
感染しているのかしていないのかも分からない。もう何を信じていいのかわからなくなってしまうのである。
こういった状況に陥らないように支援するのが Intel® Trusted Execution Technology (Intel® TXT) である。
この機構をどう実現しているのかが気になってきている頃だと思う。
先ほどの例え話は OS 上での話であったが、Intel® TXT はずっとローレベルで行われていて、仮想マシン動作の信頼性に一役買っている。
ハードウェア上に独立した信頼出来る管理局を用意し、そこから連鎖的に信頼できるものかどうか確かめていけばいい。
まず、Intel® TXT を使用するには CPU やチップセットの対応以外に条件として
TPM (Trusted Platform Module) と呼ばれるチップが搭載されている
ということがある。
TPM とは、セキュリティ関連の演算を行う LSI のことである。(LSI とは大規模集積回路のこと)
耐タンパー性(ハードウェアの解析の困難さのこと)をもっており、内部のデータを解析するのは困難なものになっている。
この TPM を管理局の中枢とし、 Intel® TXT と合わさって管理局の役目を果たすのである。
Intel® TXT の動作は次のような形をとる。
- システムを起動する際に、Intel® TXT がシステムの BIOS やファームウェアに改ざんがないかをチェックする。
- その信頼が確認されたハードウェア上で、仮想マシンモニタ (≒ Intel® VT) の改ざんがないかチェックした上で起動させる。
- そして信頼された仮想マシンモニタの上で仮想マシンが動作する。
当然、改ざんが発見されれば、動作を停止する。
これにより、信頼できる環境で仮想マシンを動作させることができるのである。
つまり、Intel® TXT とは「ソフトウェアの改竄をチェックすることで信頼されたシステムを提供する仕組み」なのである。
tboot (+ KVM) で使ってみる。
Intel Trusted Execution Technology が本当にシステムのチェックをしているのか検証するのはなかなか難しいので、この技術を使うことを検証のメインとしました。
試行錯誤の連続で、実際にやったことと一致していない可能性が十分にあります(汗)
うまく行っているのかどうか、今ひとつわからない。納得の行かない内容であることは私自身が一番感じています。
せっかく環境を構築したのに、何もしないのは検証としては物足りない気がしたので、実験的に TXT に対して悪戯を少々。それは最後の方を見ていただければと。
【 主に使用したアプリケーションなど 】
- tboot
Trusted Boot。今回の主役。Intel® TXT を使うためのオープンソースのカーネル/VMMモジュール。
標準でインストール済みのはずですが、Fedora 16 だと色々と問題が… - Fedora 16
RPM 系 Linux ディストリビューション。
最新は18。自分の知識ではどうしていいのかわからなくなり仕方なく 16 を使用。 - KVM
Kernel-based Virtual Machine。カーネル仮想化基盤。Linuxカーネル 2.6.20 以降に標準搭載。これ単体では仮想マシンを走らせることはできない。Xen が同様なものとして挙げられる。 - SINIT AC モジュール
プラットフォームの設定状況を確認するためのファイル。
ハードウェアの環境に応じて配布されています。
【 Trusted Boot 環境の構築 】
【 Step 1 】
BIOS上でTPM、Intel® TXT、Intel® VTを有効化します。
DQ77MK だと、Intel® TXT を有効化すると VT も有効化されます。
TPM の項目は [Configuration] > [On-Board Devices] > [Trusted Platform Module] にあったはずです。TXT を有効化した時点で、勝手に有効化されているかもしれません。
【 Step 2 】
さくっと、Fedora をインストールします。
とりあえず今回は Fedora 16 を使用しました。
インストール画面はカットで…(汗)
…あっという間に Fedora のインストールが終了しました！(笑)
【 Step 3 】
tboot をインストールします。
ターミナル上で下記コマンドを実行。
# yum install tboot
同時に trousers もインストールされるはずです。
通常はこれで問題ないはずなのですが、/etc/grub.d/20_linux_tboot (ブートメニューへのエントリを自動生成してくれるシェルスクリプト) が tboot インストール時に配置されなかったので、仕方なくパッケージをダウンロードしてきて、インストールしました。Fedora 18 だと問題なくインストールされます。
【 Step 4 】
SINIT AC モジュール をダウンロード＆解凍して /boot 直下に配置します。
今回は環境(Q77)に併せて「3rd_gen_i5_i7_SINIT_51.BIN」を使用しました。
一般ユーザだと権限がなく作業が進まないので、管理者権限で移動をしました。
# mv ~/Downloads/3rd_gen_i5_i7_SINIT_51.BIN /boot/
【 Step 5 】
TPM の設定を行います。が、うまくいきません(笑)
まず、tpm-tools をインストールします。
# yum install tpm-tools
いろんな情報があってどうしたらいいのかそもそも不明なのですが、設定を行なっていきます。それぞれが何をしているのはよく知りません←オイコラ
# /etc/init.d/tcsd start
# modprobe tpm_bios
# modprobe tpm
# modprobe tpm_tis
とか、適当に実行した後
# tpm_takeownership
とやると、
Tspi_TPM_TakeOwnership failed: 0x00000008 - layer=tpm, code=0008 (8), The TPM target command has been disabled
と出ます。
コマンドが無効化されているようです。謎です。他のコマンドも同じようなエラーが出てできません。
こうなると TPM のリセットと再設定が必要らしいのですが、既に使用中のためになるっていう話も…
リセットして、再設定してもまたなってしまい、私の手に負えない。既に設定済みと信じて華麗にスルー。
【 Step 6 】
仮想マシン環境の準備をします。
ターミナル上で下記コマンドを実行。
# yum install qemu-kvm libvirt virt-manager
ちなみに、qemu-kvm は KVM コアパッケージ、libvirt は仮想環境向け共通 API、virt-manager は仮想マシンマネージャ(VMM)。
【 Step 7 】
grub2-mkconfig コマンドで、ブートメニューを再構築します。
ターミナル上で下記コマンドを実行。
# grub2-mkconfig -o /boot/grub2/grub.cfg
PC を再起動すると GRUB2 のブートメニューに tboot のメニューが現れるはずです！
テスト中に Xen も入れてしまったので、一緒に出てちゃっています(汗)
【 Step 8 】
せっかくなので、仮想マシンマネージャを使って、仮想マシンを構築していきます。
ウィンドウ左上のディスプレイのようなマークをクリックして進めていけば全く無問題。
簡単に、ゲストOSインストール完了！
【 起動画面 】
今ひとつ、正常に動作しているのかわからないので、Intel® TXT を BIOS 上でEnable/Disable して、試してみた。その時の動画である。
【 Intel® TXT is Enabled 】
【 Intel® TXT is Disabled 】
一応、動作が変わるので、動作している模様…
ログが流れるのが早すぎて追えない><
【 カーネルを無理やり変更してみる 】
別PCに繋いで、/boot にあるLinuxカーネルをリネームして、別のものを読みこませようと考えました。
Windows PC に繋いでやろうとしたのですが、うまくパーティションを読み込めず…
仕方なく、GRUB2 から旧バージョンのカーネルで起動し、旧バージョンカーネルの
「Linux カーネル 3.1.0-7」のファイルを現在使っているカーネルである「Linux カーネル 3.6.11-4」のファイル名に書き換えるという超シンプル検証。
これくらいの技術がないっていうのが事実(笑)
こういうことして、TXT の動作を確認できるのか謎ですが、実験。
その時の起動画面をどうぞ！
…うん、普通に動いてる。
これ以外どうしたらいいのか、そもそも tboot (Intel® TXT) がどんなふうに動いているのかもよくわかっていないので、これ以上の深追いはせず(できず)にここで終了です。
TXT が動いている(ような気がする)のは拝めたので一応…
これが私の技術の全てを投じた結果なので仕方がない><
ここからは、筆者がこの検証を行ったときにあったことに関するどうでもいい話です。
無理に読むことはないです。
そもそも、「TXTとは何者？」ってところから始まり、実証環境を VMware vSphere (ESXi) にしようかと思ったりもした(というか1度インストールした)のですが、Linux でやってみるのもスキルアップになるかななんて軽い気持ちで始めました(変えました)。
「Xen + tboot か KVM + tboot で何とかなりそうだ！」とわかり、調べていくうちに Xen は時代遅れである風潮と、KVM は Linux カーネル内蔵で、何ともスマートじゃんと思って KVM + tboot での構築を始めました。
Xen + tboot の情報はいくつかあるものの、KVM + tboot での情報はほとんど見当たらず、手探り状態でいろいろと試しました。
* * * * *
Intel® TXT もですが、 Linux 関連の知識がなさすぎたので調べまくりました。
文章として書きようもないのでがっつり割愛。
ちょっとずつ構造がわかってきたあたりから話を再開しましょう。
* * * * *
Fedora 18 で試していたのですが、何故か grub2 のブートメニューに tboot の項目が表示されず… (/boot/grub2/grub.cfg の内容が全く反映されない。ここにたどり着くのにかなりロス。)
そのあともいろいろと試したんですが、自分の手には負えず Fedora 18 ではあきらめました(笑)
* * * * *
「ちょっとバージョンを落としてみよう」 と Fedora 16 をインストール。
インストールが終了したらすぐに、/boot/grub2/grub.cfg の内容がブートメニューに反映されることを確認して、「これはキタ！」と確信。
しかし、Fedora 18 では存在していたはずの /etc/grub.d/20_linux_tboot がいない。
自分で /etc/grub.d/40_custom に書き込む方法もある(どこのサイトでもそれで説明)が、どう書いていいのかわからないので、tboot をアップデートしようと。
yum でインストールしても、インストールされず…
仕方なくパッケージをDLしてインストールをすることに。
それでも、Fedora 16 も何故か gcc が入ってなくて(パスが通ってなくて？) make できなかったりと、全く関係ない所で躓いたり。
Intel® TXT、なかなかの強敵でした。←倒せてない
ZIGSOWにログインするとコメントやこのアイテムを持っているユーザー全員に質問できます。