日本ソフトウェア科学会第 34 回大会 (2017 年度) 講演論文集

クラウドにおける VM リダイレクト攻撃を防ぐためのリモート管理機構
猪口 恵介

光来 健一

近年，IaaS 型クラウドの利用が広まってきており，ユーザは IaaS 型クラウドによって提供される仮想マシン（VM）に管理サーバ経由でアクセスする．しかし，管理サーバを管理するクラウド管理者は必ずしも信頼できるとは限らず，VM に対して様々な攻撃を行う恐れがある．考えられる攻撃の一つとして，ユーザのアクセス先 VM を変更する VM リダイレクト攻撃が考えられる．本稿では，このような VM リダイレクト攻撃を防止する UVBond を提案する．UVBond は VM の暗号化ディスクを利用することでユーザと VM を強く結びつけ，セキュアな VM 識別子を発行する．そして，ユーザによって指定された管理コマンドがその VM 識別子に対応する VM に対して実行されることを保証する．我々は UVBond を Xen に実装し，正しい VM 識別子を指定し，かつ，指定された管理コマン
ドを正しく実行した場合のみ VM を操作可能であることを確認した．

ぶ．VM リダイレクト攻撃によって悪意ある管理者が1 はじめに用意した VM にアクセスさせられた場合，VM 内部

近年，クラウドコンピューティングの利用が広まっにインストールされたマルウェアなどによってユーザてきており，その利用形態の一つである IaaS 型クラの機密情報を盗まれる恐れがある．

ウドでは，ユーザに仮想マシン（VM）の提供を行う．

本稿では，VM の暗号化ディスクを介してユーザ

ユーザは VM の管理を行う場合，まずネットワークと VM を強く結びつけることにより VM リダイレク

を介してクラウドの管理サーバに接続を行い，そこト攻撃を防ぐ UVBond を提案する．UVBond はディから VM へアクセスを行う．例えば，ユーザは管理

スク暗号化を利用してユーザの VM を安全に起動し，サーバを通して VM の起動や終了，マイグレーショ

VM が正しく起動されたことをユーザ自身が確認するンなどの操作，VNC や SSH などのリモート管理シことを可能にする．VM が起動されると，UVBond は

ステムを用いた帯域外リモート管理などを行う．

ユーザにセキュアな VM 識別子の発行を行い，ユーザ

管理サーバは VM の管理者とは異なるクラウドのはこの VM 識別子と管理コマンドを指定してリモー

システム管理者によって管理されているが，クラウド

ト管理を行う．その際に，UVBond は指定された管管理者は必ずしも信頼できるとは限らない．そのた理コマンドが VM 識別子に対応する VM に対して実め，信頼できないクラウド管理者が管理サーバの権行されることを保証する．これらの処理を VM を動限を悪用し，VM に対して様々な攻撃を行うことが作させる基盤ソフトウェアであるハイパーバイザ内で考えられる．考えられる攻撃の一つとして，ユーザが実行することでその安全性を担保する．

アクセスする先の VM を意図的に変更し，クラウド

我々は UVBond を Xen 4.4.0 [2] に 実 装 し た ．

管理者によって用意された悪意ある VM に接続させ

UVBond ではハイパーバイザに VM の暗号化ディる攻撃が考えられる．本稿では，このような接続先のスクの暗号鍵を登録し，準仮想化ドライバを用いる

VM を変更させる攻撃を VM リダイレクト攻撃と呼OS に対してハイパーバイザ内部でディスクの暗号

Keisuke Inokuchi, Kenichi Kourai, 九 州 工 業 大 学,
Kyushu Institute of Technology.

化・復号化を実行する．管理コマンドの識別には，管理コマンドがハイパーバイザに対して発行するハイᅗ 䠖䝸䝎䜲䝺䜽䝖ᨷᧁ

パーコールの列を利用する．正しいハイパーコール列
IaaSᆺ䜽䝷䜴䝗が実行されている間だけ，VM 識別子によって指定された VM へのアクセスを許可する．実験により，ク

⟶⌮
䝃䞊䝞

䝴䞊䝄

ᝏព䛒䜛VM
VM

ラウド管理者がアクセス先の VM や実行する管理コ䝬䝹䜴䜵䜰

マンドを意図的に変更することができないことを確認した．また，VM の起動時間とディスク I/O 性能を測定し，UVBond では VM の起動時間が 5.7 秒長く

図1

VM リダイレクト攻撃

なり，読み込み性能が 9.5%，書き込み性能が 3.2%低下することが分かった．

能性がある．例えば，クラウド管理者は VM のメモ

以下，2 章でクラウドにおける管理サーバの信頼性

リ内の情報や帯域外リモート管理の入出力の情報をと VM リダイレクト攻撃について述べ，3 章で提案

盗み見ることができる．このような情報漏洩を防ぐたするシステムである UVBond について述べる．4 章

めに，クラウド管理者に対して VM のメモリや入出で実装の詳細について述べ，5 章で行った実験につい力を暗号化する手法が提案されてきた [5] [7] [8] [9] [15]．

て述べる．6 章で関連研究に触れ，7 章でまとめと今

これらの手法では，管理サーバや VM の下で動作す

後の課題について述べる．

るハイパーバイザと呼ばれるソフトウェアを信頼することにより，クラウド管理者に対して VM の情報を

2 VM リダイレクト攻撃

隠蔽する．

クラウドにおいて，ユーザはクラウド内の管理サー

本稿では，信頼できないクラウド管理者によって行

バを経由して VM を管理する．管理サーバは VM にわれる新たな攻撃として VM リダイレクト攻撃を考対して起動や停止，バックアップの作成，他のホスト

える．VM リダイレクト攻撃は図 1 のように，管理へのマイグレーションなどの様々な操作を行うことがサーバにおいてユーザがアクセスする VM を変更すできる．また，VM の仮想デバイスに直接アクセスする攻撃である．クラウド管理者はマルウェアなどをイることにより，VM の帯域外リモート管理を行うこと

ンストールした悪意ある VM を作成しておき，ユーもできる．帯域外リモート管理は VM のネットワー

ザをその VM にアクセスさせることによって様々なクに依存せず，SSH や VNC などを用いて VM 内の攻撃を行うことができる．例えば，システムのログイシステムにログインしてアクセスすることを可能に

ンプログラムを改ざんしたり，キーロガーを仕掛ける

する．

ことによってユーザがシステムにログインする際のパ管理サーバはクラウド管理者によって管理される

スワードを盗むことができる．この攻撃はアクセス先

が，クラウド管理者は必ずしも信頼できるとは限らの VM 内部で行われるため，VM の帯域外リモートない．例えば，Google の管理者がユーザの機密情報管理における入出力を暗号化したとしても防ぐことを無断で閲覧し，ユーザのプライバシを侵害するとはできない．

いう事件 [16] が発生している．また，サイバー犯罪の28%は内部犯行であり [11]，管理者の 35%は機密情報

3 UVBondに無断でアクセスしたことがある [4] という報告もあ3. 1 脅威モデル

る．このように，クラウドプロバイダ自体は信頼する

本稿では，クラウド内に信頼できない管理者が存ことができるとしても，クラウド内にその管理権限を在する可能性があり，クラウド全体が信頼できるとは悪用する管理者が存在しないことを保証するのは難限らない状況を想定する．信頼できない管理者は管しい．

理サーバの権限を悪用してクラウド内の VM に自由

信頼できないクラウド管理者は管理サーバの権限をにアクセスすることができる．本稿では特に，従来手悪用し，ユーザの VM に対して様々な攻撃を行う可法では対処が難しかった VM リダイレクト攻撃を考ᅗᬯྕ໬䝕䜱䝇䜽䜢⏝䛔䛯
ື

䛾㉳

える．
一方で，仮想化システムの根幹となるハイパーバ䝴䞊䝄イザおよびその下のハードウェアは信頼できるもの

ᬯྕ㘽

VM㉳ື
⟶⌮䝃䞊䝞

VM

とする．このような仮定は様々な研究において行われている [3] [19] [13] [8] [15] [9]．信頼できるハイパーバ᚟ྕイザは様々な手法によって実現可能である．例えば，ᬯྕ㘽䝝䜲䝟䞊䝞䜲䝄

TPM を用いたセキュアブートによってハイパーバイ
ザが正常に起動したことを保証することができる．ま図2

暗号化ディスクを用いた VM の起動

た，ハードウェアを用いた監視手法により，実行時の改ざんを検出することもできる [12] [10] [17] [1]．
䝴䞊䝄

3. 2 ユーザと VM の結び付け
本稿では，VM の暗号化ディスクを介してユーザ

⟶⌮䝃䞊䝞

᚟ྕ
䝕䞊䝍

VM

ᬯྕ㘽

と VM を強く結びつけることで VM リダイレクト攻撃を防ぐ UVBond を提案する．UVBond は従来行わ

ᬯྕ໬
䝕䞊䝍

れていた仮想デバイスレベルや VM 内でのディスク暗号化ではなく，クラウド管理者が干渉できないハイ
パーバイザレベルでのディスク暗号化を用いる．クラウドにおいて情報漏洩を防ぐためには従来でもディスᬯྕ㘽䝝䜲䝟䞊䝞䜲䝄ᅗ 䠖
図3㆑ูᏊ䜢⏝䛔䛯䝸䝰䞊䝖⟶⌮登録されたディスク暗号鍵の確認

クを暗号化する必要があったため，UVBond においてディスク暗号化を用いてもオーバヘッドが大きく増大することはない．

UVBond では，VM の起動時にユーザとハイパー

䝴䞊䝄

VM㆑ูᏊ

䝴䞊䝄VM䜈
䜰䜽䝉䝇

⟶⌮
䝃䞊䝞

ᝏព䛒䜛VM

VM

バイザの間でディスク暗号鍵を共有し，ハイパーバ
イザ内で VM とディスク暗号鍵を結び付ける．このVM㆑ูᏊ

時，ディスク暗号鍵はハイパーバイザの公開鍵によっ䝝䜲䝟䞊䝞䜲䝄

て暗号化して送られるためクラウド管理者には漏洩せず，ハイパーバイザ内の秘密鍵でのみ復号できる．

図4

VM 識別子を用いたリモート管理

UVBond は登録されたディスク暗号鍵を用いて図 2のようにハイパーバイザ内でディスクの暗号化・復号動される危険性がある．ハイパーバイザは VM 起動化を行いながら VM を起動する．登録されたディスの際に，図 3 のように確認用のデータを登録された

ク暗号鍵に対応する暗号化ディスク以外では VM を

ディスク暗号鍵で暗号化してユーザに返送する．この起動できないため，ユーザの VM が起動されることデータを受け取ったユーザが正しく復号できれば，登を保証することができる．

録されたディスク暗号鍵はユーザのものであることがさらに，UVBond は登録されたディスク暗号鍵が確認できる．

ユーザのものであるかの確認を行う．これは，クラウ

VM が起動された時に，ハイパーバイザは VM にド管理者がディスク暗号鍵をハイパーバイザへの登結び付けられたセキュアな VM 識別子をユーザに対録の際にすり替えることが可能なためである．信頼

して発行する．VM 識別子は登録されたディスク暗できない管理者が不正な暗号化ディスクを作成し，そ号鍵によって暗号化され，ユーザに返送される．VMのディスク暗号鍵を登録することで不正な VM を起識別子は図 4 のようにユーザが VM にアクセスする䝝䜲䝟䞊䝁䞊䝹ิ䛾౛

xen_version
1

8

memory_op memory_op

sysctlsysctl910sysctlmemory_op
13

図5

12

domctldomctl
x8

11

14

15

VM のメモリ設定コマンドのハイパーコール列際に使用され，ユーザが指定した VM 以外にアクセ

コマンドは初回と 2 回目以降の実行で呼び出される

スすることを防ぐ．そのため，信頼できない管理者がハイパーコールが異なる．そのため，ハイパーコール

VM リダイレクト攻撃を行おうとしても，リダイレ

列は管理コマンドによって呼び出される可能性がある

クト先の VM へのアクセスはハイパーバイザによっ

すべてのハイパーコール呼び出しを含む．

て拒否される．

ハイパーコールの呼び出し順が同じであったとしても，ユーザが意図した管理コマンドが実行されている

3. 3 VM の安全なリモート管理とは限らない．信頼できないクラウド管理者はユーザ起動した VM を操作するために，ユーザは管理サー

がハイパーバイザに登録したハイパーコール列に受バ経由で管理コマンドを実行する．その際に VM 識

理されるようにハイパーコールを呼び出す別の管理

別子を指定することで，UVBond は対応する VM にコマンドを実行することが可能である．しかし，VM

対して指定した管理コマンドが実行されることを保への操作は必ずハイパーコール経由で行われるため，証する．しかし，VM 識別子を用いたアクセス制御はハイパーコールの呼び出し順が同じであれば VM に

ハイパーバイザが行う一方で，ハイパーバイザは管理

対して本質的に同じ操作しか行うことができない．そコマンドを認識することができない．管理コマンドはのため，ユーザが意図した管理コマンドとは異なると管理サーバにおいて実行され，ハイパーバイザに対しても，ハイパーコール列が同じであれば同じ管理コ

してハイパーコールを発行しながら VM の操作を行

マンドとみなすことができる．ただし，登録されるハう．ハイパーバイザはハイパーコールしか認識できな

イパーコール列が複雑になればなるほど，元の管理コ

いため，管理コマンドの実行に直接 VM 識別子を結マンドとは異なる挙動をする管理コマンドの実行がびつけることは難しい．

容易になる．また，VM のメモリへのアクセスのよう

そこで UVBond では，ハイパーコールの呼び出しに，ハイパーコールでアクセスできるようにした後，を入力とする図 5 のようなオートマトンを用いて管そのメモリへのアクセスをハイパーバイザがチェック

理コマンドを識別する．本稿ではこのオートマトン

できない場合には，ユーザが意図しない操作が行われをハイパーコール列と呼ぶ．ユーザは VM 識別子とる可能性がある．

ともに，指定した管理コマンドに対応するハイパー

UVBond はクラウド管理者にも VM への一部の操コール列を暗号化してハイパーバイザに送信する．ハ

作を許可することができる．これは，クラウド管理者

イパーバイザは送られてきたハイパーコール列に沿っが VM をまったく管理できなくなると不便なためでて管理コマンドが実行されている間だけ，VM 識別子

ある．例えば，VM の終了やマイグレーションだけをに対応する VM へのアクセスを許可する．それぞれ許可することが考えられる．VM 識別子を持たないの管理コマンドによって呼び出されるハイパーコール

クラウド管理者が VM を操作できるようにするためは必ずしも固定ではなく，状況によって変化する場合に，実行を許可する管理コマンドのハイパーコール

もある．例えば，VM のメモリサイズを設定する管理

列をあらかじめハイパーバイザに登録しておく．クラウド管理者であっても，この管理コマンドが実行されている間は特定の VM への操作が許可される．許可

䝗䝯䜲䞁0

䝴䞊䝄
2.䜰䝑䝥䝻䞊䝗

1.ᬯྕ໬

する管理コマンドはユーザが自由に決定可能であり，管理者にどの程度の操作を許可するかによって管理と

5.㏦ಙ
ᬯྕ㘽

セキュリティのトレードオフをとることができる．

ᬯྕ㘽
6.䝝䜲䝟䞊䝁䞊䝹

3.බ㛤㘽䛾ྲྀᚓ
4.බ㛤㘽䛷ᬯྕ໬
7.᚟ྕ

4 実装

බ㛤㘽

我々は UVBond を Xen 4.4.0 [2] に実装した．Xen

㘽䝃䞊䝞

ᬯྕ㘽

⛎ᐦ㘽
䝝䜲䝟䞊䝞䜲䝄

では管理サーバはドメイン 0 と呼ばれる VM 内で動作し，管理者もドメイン 0 を用いて VM の管理を行

図6

ディスクのアップロードと暗号鍵の登録

う．ユーザの VM はドメイン U と呼ばれる．ハイパーバイザ内での暗号化・復号化のために WolfSSLで述べる．VM の起動と並行して，クライアントはハ[18] の AES と RSA を移植し，ユーザ端末のクライイパーバイザに登録されたディスク暗号鍵の正しさをアントでは OpenSSL を使用した．

確認する．この詳細については 4.4 節で述べる．

VM が起動すると，ドメイン 0 はハイパーコール
4. 1 VM のライフサイクル

を発行してハイパーバイザからセキュアな VM 識別

UVBond を用いた場合の VM のライフサイクルは子を取得する．この VM 識別子はハイパーバイザに

以下のようになる．ユーザは VM の作成時に AES 方

よって生成され，VM に登録されているディスク暗式のディスク暗号鍵を生成し，この暗号鍵を用いて号鍵を用いて暗号化される．ドメイン 0 が VM 識別

VM のディスクイメージを暗号化する．暗号化され子をクライアントに送信すると，クライアントはディたディスクイメージはクラウドにアップロードされ，

スク暗号鍵を用いてそれを復号する．クライアント

従来通りドメイン 0 内に格納される．

が VM に対して管理コマンドを実行する際にはこのVM を起動する際に，クライアントは VM の起動

VM 識別子と管理コマンドのハイパーコール列の組

コマンドとともにハイパーバイザの RSA 公開鍵にを暗号化して送信する．この詳細については 4.5 節でよって暗号化されたディスク暗号鍵をドメイン 0 に送述べる．

信する．ハイパーバイザの公開鍵は信頼できる鍵サー
バから取得するが，現在はあらかじめクライアント

4. 2 準仮想化ディスク I/O の暗号化に登録している．暗号化されたディスク暗号鍵を受け

VM のディスクアクセスには準仮想化ディスクドラ

取ったドメイン 0 はハイパーコールを発行して受信イバが用いられることが多い．完全仮想化ディスクド

したデータをハイパーバイザに渡す．ハイパーバイザ

ライバを用いる場合と比べて，ディスク入出力の性能

は自身の秘密鍵でこのデータを復号し，起動しようとを向上させることができるためである．Xen は準仮している VM にディスク暗号鍵を登録する．ディス

想化と完全仮想化の両方のゲスト OS をサポートしてクイメージの暗号化から暗号鍵の復号までのプロセ

いるが，完全仮想化の場合でも Linux では準仮想化

スを図 6 に示す．

ディスクドライバが用いられる．

ドメイン 0 は起動コマンドに基づき，ユーザが指定

4. 2. 1 従来のディスク入出力

した暗号化ディスクを用いて VM の起動を行う．VM

Xen の準仮想化ディスクドライバは，図 7 のようがディスクにアクセスする際に，ハイパーバイザがにドメイン U で動作する blkfront ドライバとドメイ

ディスクアクセスを横取りし，読み込もうとしている

ン 0 で動作する blkback ドライバからなる．これら

データの復号化，書き込もうとしているデータの暗号のドライバは I/O リングと呼ばれるリングバッファ化を行う．この処理の詳細については 4.2 節，4.3 節が格納されたメモリ領域を共有し，イベントチャネル

䝗䝯䜲䞁U

䝗䝯䜲䞁0
䝕䞊䝍

䝕䞊䝍

䜾䝷䞁䝖
䝨䞊䝆

blkback
䝗䝷䜲䝞
せồ䞉ᛂ⟅

I/O
䝸䞁䜾

blkfront
䝗䝷䜲䝞
せồ䞉ᛂ⟅

䝗䝯䜲䞁U

䝗䝯䜲䞁0

blkback
䝗䝷䜲䝞

ᬯྕ໬/
᚟ྕ໬

䝅䝱䝗䞊
䜾䝷䞁䝖
䝨䞊䝆

ྠᮇ

䝅䝱䝗䞊
I/O
䝸䞁䜾

䜲䝧䞁䝖

䝀䝇䝖
䜾䝷䞁䝖
䝨䞊䝆
䝀䝇䝖
I/O
䝸䞁䜾

䜲䝧䞁䝖
䝝䜲䝟䞊䝞䜲䝄

図7

blkfront䝗䝷䜲䝞

従来のディスク入出力䝝䜲䝟䞊䝞䜲䝄

図8

共有ページの二重化と呼ばれる機構を用いて通信を行う．VM がディスクを二重化する．ドメイン U には従来通り，暗号化さの入出力を行う際には，blkfront ドライバが I/O リ

れていないページを提供するが，ドメイン 0 には暗ングに要求を書き込み，イベントを送信する．イベン

号化されたページを提供する．ドメイン U に提供すトを受け取った blkback ドライバはその要求を I/O

るページをゲストグラントページと呼び，ドメイン 0

リングから取り出し，VM のディスクイメージにアクに提供するページをシャドーグラントページと呼ぶ．

セスすることで入出力を実現する．読み込みの場合に一方，I/O リングを格納しているグラントページ

は，要求で指定されたドメイン U のバッファ領域にについても二重化は行うが，暗号化は行わない．このディスクイメージから読み込んだデータを書き込む．

二重化は，ハイパーバイザが暗号処理を終えた要求だ

書き込みの場合は，指定されたバッファ領域のデータ

けを blkback ドライバに渡し，復号処理を終えた応をディスクイメージに書き込む．入出力が完了する

答だけを blkfront ドライバに渡せるように同期をとと，blkback ドライバは応答を I/O リングに書き込るために行う．ドメイン U に提供する I/O リングをみ，blkfront ドライバにイベントを送信する．

ゲスト I/O リング，ドメイン 0 に提供する I/O リンドメイン 0 とドメイン U の間でのメモリ領域の共グをシャドー I/O リングと呼ぶ．

有には，グラントテーブルと呼ばれる機構が用いられ

UVBond は従来との互換性を保つために，ドメイ

る．ドメイン U はまず，グラントテーブルに共有しン U から渡されたグラント参照を用いて，二重化さたいメモリページを登録する．このページはグラン

れたグラントページにアクセスすることを可能にすトページと呼ばれる．グラントページにはグラント

る．ドメイン U に対しては従来通り，グラント参照

参照が割り当てられ，ドメイン 0 はグラント参照ををゲストグラントページに対応させる．一方，ドメイ指定して対応するページをマップしてアクセスする．

ン 0 に対しては，同じグラント参照をシャドーグラ

I/O リングが格納されているページのグラント参照は

ントページに対応させる．これにより，ドメイン 0 がXenStore と呼ばれるドメイン 0 内のデータベース経グラント参照に対してメモリマップ処理を行うと，ゲ由で blkfront ドライバから blkback ドライバに渡さ

ストグラントページの代わりにシャドーグラントペー

れる．ディスクの読み書きに用いられるバッファ領域

ジがマップされ，アンマップ処理を行うとシャドーグが格納されているページについては，I/O リングに書

ラントページがアンマップされる．ドメイン 0 からき込まれる要求を通してグラント参照が渡される．

はゲストグラントページにアクセスできているよう4. 2. 2 共有ページの二重化に見えるが，実際にはシャドーグラントページにアクハイパーバイザが復号した後のデータをドメイン 0

セスすることになる．

に傍受されないようにするために，UVBond は図 8のようにバッファ領域を格納しているグラントページ

4. 2. 3 暗号化ディスクを用いた入出力
UVBond では，VM の起動時にハイパーバイザがに対応するシャドーグラントページも解放する．

4. 2. 4 AES-NI による暗号処理の高速化

ドメイン U とドメイン 0 の間の通信を解析すること

UVBond では，CPU の拡張機能である AES-NIによって I/O リングが格納されたメモリページを特をハイパーバイザ内で利用することにより，ディス

定し，シャドー I/O リングを作成する．blkfront ドクの暗号化・復号化処理を高速化する．そのために，ライバは初期化時に，XenStore に I/O リングが格納

WolfSSL の AES-NI 関数を移植した．この関数はされたページのグラント参照を登録する．この際に，

XMM レジスタを利用するが，ハイパーバイザ内でこXenStore リングと呼ばれるリングバッファに要求をのレジスタを使用すると例外が発生した．Xen では

書き込んでイベントを送るため，イベントを送信す

VM の仮想 CPU をスケジューリングする際に XMMるハイパーコール内で XenStore リングから I/O リ

レジスタの復元を遅延しており，XMM レジスタへのングのグラント参照を取得する．XenStore リングがアクセス時に例外を発生させて復元するためである．

格納されているページの情報は VM の起動時にハイ

そこで，AES-NI 関数を実行する前に CR0 レジスタ

パーバイザに通知される．そして，シャドー I/O リの TS ビットをクリアしてこの例外が発生しないようングを作成した後で，ゲスト I/O リングの中身をシャにし，実行後に元の状態に戻すようにした．

ドー I/O リングにコピーする．blkfront ドライバが用いるイベントチャネルのポート番号も同様にして取4. 3 完全仮想化ディスク I/O の暗号化得する．

UVBond は準仮想化ディスク I/O だけでなく，完

blkfront ドライバから blkback ドライバに要求が全仮想化ディスク I/O にも対応している．これは，完送られた時，それがディスクへの書き込み要求であれ

全仮想化 OS を起動する場合，ゲスト OS が起動すばハイパーバイザはデータの暗号化を行う．要求を送る前に実行される BIOS は完全仮想化ディスク I/Oる際にはイベントを送信するためのハイパーコール

を用いるためである．BIOS からのディスク読み込みが呼ばれるため，その中でゲスト I/O リングに書きは，ハイパーバイザにおいて IN 命令をエミュレート

込まれた要求を解析する．要求に含まれるグラント参することで実現されており，512 バイト単位での読み

照に対応するシャドーグラントページがまだなけれ込みが行われる．512 バイトの読み込みは 4 バイト

ば作成する．ディスクへの書き込み要求の場合には，分の IN 命令と 508 バイト分の IN 命令の繰り返し

ゲストグラントページ上のバッファ領域に格納されたに分けてハイパーバイザにトラップされる．AES はデータを暗号化しながらシャドーグラントページに書

16 バイト単位でしか復号を行うことができないため，き込む．最後に，この要求をシャドー I/O リングに

後者の 508 バイトの読み込み時に 512 バイト分をまコピーする．

とめてハイパーバイザ内で復号する．VM の起動時

blkback ドライバから blkfront ドライバに応答がには BIOS のディスクへの書き込み機能は使われな送られた時，それがディスクへの読み込み要求に対すいため，書き込みの暗号化には未対応である．また，る応答であればハイパーバイザはデータの復号を行DMA 転送にも未対応である．

う．応答にはグラント参照が含まれないため，対応する要求を保存しておき，要求からグラント参照を取得

4. 4 VM の正常起動の確認

する．ディスクへの読み込み要求に対する応答の場合

UVBond では，ハイパーバイザに登録されたディスには，グラント参照に対応するシャドーグラントペー

ク暗号鍵がユーザのものであるかどうかの確認を VM

ジ上のバッファ領域に格納されたデータを復号しなが識別子の送信と同時に行う．起動した VM の VM 識らゲストグラントページに書き込む．最後に，この応別子を取得するためにドメイン 0 がハイパーコール

答をゲスト I/O リングにコピーする．使用されなくを発行した際に，ハイパーバイザは VM 識別子に確なったゲストグラントページが解放された場合，同時認用のデータを付加してディスク暗号鍵で暗号化す

memory_op
12
domctl domctl
sysctl

3

4

0

1

2

3

4

5

6

7

8

9

10

11

12

3

6

-1

12

6

-1

36

11

10

-1

35

6

-1

䝝䜲䝟䞊䝁䞊䝹␒ྕ㑄⛣ඛ䜲䞁䝕䝑䜽䝇␒ྕ䝃䝤䝁䝬䞁䝗␒ྕ

༊ษ䜚␒ྕ

図9

ハイパーコール列のシリアライズ

る．これを受け取ったクライアントは自身の持つディ対応するハイパーコール列の組を暗号化してドメイ

スク暗号鍵で復号し，確認用データを正しく復号でき

ン 0 に送信する．ハイパーコール列はオートマトン

ればユーザの持つ鍵とハイパーバイザに登録されてであるが，暗号化や送信を容易にするために図 9 のいる鍵が同じものであることが確認できる．

ように 1 次元の配列にシリアライズして扱う．この配さらに，VM の起動に用いられる暗号化ディスク

列はある状態に遷移するための入力（ハイパーコールとディスク暗号鍵が正しく対応していることを確認番号）とその状態からの遷移情報の組で構成される．

するために，UVBond はディスクのブートセクタのdomctl や sysctl などのハイパーコールは様々なサブチェックを行う．ブートセクタは VM の起動時に必コマンドを持つため，ハイパーコール番号とサブコマ

ず読み込まれ，固定のマジックナンバが格納されていンドを組にして扱う．

る．そのため，ハイパーバイザが復号後にマジックナ

ドメイン 0 は受信した VM 識別子とハイパーコー

ンバを確認できれば，暗号化ディスクの単純な置き換

ル列の組を管理コマンドの実行前にハイパーバイザ

えを自動的に検出することができる．暗号化ディスに渡す．ハイパーバイザはハイパーコール列の登録をクがユーザのものであることを完全に保証するには，行うためにまず，指定された VM に登録されている

マークルハッシュ木などを用いてディスク全体の整合

ディスク暗号鍵を用いて VM 識別子とハイパーコー

性をチェックする必要がある．しかし，ハッシュデー

ル列の組を復号する．そして，復号された VM 識別

タがディスクイメージとは別に必要となり，ハッシュ子と VM に登録されている VM 識別子を比較し，一のデータ量が大きくなるためハイパーバイザ内に登致していればハイパーコール列をその VM に登録す

録して用いるのは現実的ではない．このような整合性

る．VM 識別子が一致しなかった場合，ユーザが意図チェックを行わなくても，正しい暗号化ディスクが用していない VM へのアクセスを行おうとしているといられているかどうかは VM が正しく起動したかど判断できる．

うかで容易に判断することができる．

ハイパーコール列が登録された後，管理コマンドの実行中はハイパーコールのチェックが行われる．チェッ

4. 5 管理コマンドの実行

ク対象となるハイパーコールが呼ばれた場合，ハイ起動した VM に対して管理コマンドを実行する際

パーコール列の現在のインデックスが指す状態からのには，クライアントは VM 識別子と管理コマンドに遷移先を調べる．呼ばれたハイパーコールが正しい

入力であれば現在のインデックスを更新して次の状30態に遷移し，そのハイパーコールの実行を許可する．

パーコールが呼ばれた場合には，不正な操作と判断し，ハイパーコールの実行を拒否する．管理コマンドの実行終了時に，ハイパーコール列が受理状態になったかどうかの結果をハイパーバイザが暗号化し，クライアントに送信する．

UVBond はハイパーコール列を登録したプロセス

25ًಊ࣎ؔʤsʥ

ハイパーコール列において正しい入力ではないハイ

23.8

20

24.7

18.1

15
10
5
0
ॊཔ

UVBond(AES-NI༙ް)にだけそのハイパーコール列を適用する．これは，他

図 10

UVBond(AES-NIໃް)VM の起動時間の管理コマンド等によって呼び出されたハイパーコー
ルと区別して判定できるようにするためである．ハイ

行した場合にはそのことを検知できた．

パーバイザにおいてプロセスを識別するために，プロセスに固有な CR3 レジスタの値を用いる．CR3 レ

5. 2 VM の起動時間

ジスタには OS カーネル内に作成されるプロセスの

UVBond を用いた場合に VM の起動時間を測定しページディレクトリのアドレスが格納されている．ハ

た．測定対象は，UVBond で AES-NI を有効にした

イパーコール列を登録する際に CR3 レジスタの値も場合と無効にした場合，UVBond を用いない従来シ

登録しておき，CR3 レジスタの値が一致する場合だ

ステムの 3 種類である．ドメイン 0 で起動コマンド

けそのハイパーコール列のチェックを行う．

を実行してから VM が起動するまでの時間の測定を5 回ずつ行った．ファイルキャッシュの効果を除外す

5 実験るために，VM の起動毎にドメイン 0 のページキャッ

UVBond の有効性を確かめるための実験を行った．

シュをクリアして測定を行った．実験結果を図 10 に

実験には，Intel Xeon E3-1290 の CPU，8GB のメ示す．

モリ，1TB の HDD を搭載したマシンを使用し，ハ

起動時間は従来システムが最も短く，AES-NI を

イパーバイザとして Xen 4.4.0 を用いた．ドメイン 0

有効にした UVBond では 5.7 秒長くなった．これはでは Linux 3.16，ドメイン U では Linux 3.13 を動作

ディスク暗号処理のオーバヘッドに加え，新たに追加させた．ユーザ VM には 2 個の CPU，2GB のメモした処理によるものだと思われる．AES-NI を無効に

リ，20GB のディスクを割り当てた．

した場合と比較すると，AES-NI による高速化は 1.0秒であることが分かった．

5. 1 管理コマンドの実行
VM 識別子とハイパーコール列を利用して管理コ
マンドを実行する際に，VM リダイレクト攻撃を含

5. 3 ディスク I/O 性能
ディスク I/O ベンチマークである fio を用いて性能めた不正な操作を検知可能かを確認するための実験測定を行った．この実験では 5.2 節で用いた 3 種類のを行った．この実験では，VM の一時停止，再開を行システムに加え，従来システムにおいて dm-crypt をう管理コマンドを実行した．実験の結果，操作対象の用いてゲスト OS レベルで暗号化を行う場合についVM と VM 識別子が対応しており，かつ，ハイパーても測定を行った．VM の読み込み性能と書き込み

コール列と管理コマンドが対応している場合だけ正性能を，シーケンシャルアクセスとランダムアクセス

常に管理コマンドが実行されることを確認した．指それぞれにおいて 10 回ずつ計測した．結果を図 11，

定した VM に対応しない VM 識別子を指定した場合

図 12 に示す．

や，ハイパーコール列に対応しない管理コマンドを実

いずれの場合においても，UVBond において AES-εʖίϱεϡϩΠέιη
180

ηϩʖϕρφʤMB/sʥ

160

161.7

140

155.6

156.5

143.6

120

129.9

119.9

100
80

91.2
79.6

60
40
20
0

ಣΊࠒΊ

ϧϱξϞΠέιη
ॊཔ

dm-crypt

図 11

ॽ͘ࠒΊ
UVBond(AES-NI༙ް)UVBond(AES-NIໃް)

シーケンシャルアクセスηϩʖϕρφʤMB/sʥ

140
120

117.7
100

109.9

109.3
91.6

80
60

61.8
40

59.7

54.6

45.5

20
0

ಣΊࠒΊ
ॊཔ

ॽ͘ࠒΊ

dm-crypt

UVBond(AES-NI༙ް)ࣰߨ࣎ؔʤmsʥ

図 12

UVBond(AES-NIໃް)

ランダムアクセス

14

dm-crypt と比べると読み込み性能は少し高くなり，

12

書き込み性能は同等であった．

10
6

6

5. 4 管理コマンドの実行時間

86ドメイン 0 において管理コマンドの実行時間の計

4
6

6

6

ॊཔ

UVBond(AES-NI༙ް)UVBond(AES-NIໃް)2測を行った．測定対象として 5.2 節で用いた 3 種類のシステムを用い，VM の一時停止を行う管理コマンド0؇ཀྵαϜϱχ͹ࣰߨ図 13

ύ΢Ϗʖαʖϩ྽͹ౌ࿧

管理コマンドの実行時間の実行時間をそれぞれ 10 回ずつ測定した．UVBond
においてはハイパーコール列の暗号化およびハイパー
バイザへの登録にかかる時間についても測定した．結果を図 13 に示す．

NI を有効にした場合は無効にした場合と比べて大管理コマンドの実行時間はハイパーコール列のきく性能が向上した．このことから，AES-NI の高チェックを行う UVBond でも従来システムと同等で速化の効果があることが分かった．AES-NI を有効あった．しかし，ハイパーコール列の登録を含めた全にした場合，UVBond は従来システムと比べていず

実行時間は従来システムの 2 倍となった．これは，用れも 10%以下の性能低下に抑えられている．また，

いた管理コマンドの実行時間が非常に短く，ハイパーコール列の登録の影響が相対的に大きくなったため

管理 VM において VM リダイレクト攻撃を行うことであると考えられる．ハイパーコール列の暗号化・復が可能である．

号化については，ハイパーコール列が短かったため

AES-NI の高速化の効果は見られなかった．

FBCrypt [5] は帯域外リモート管理における入出力
をハイパーバイザレベルで暗号化することでクラウ
ド管理者への情報漏洩を防ぐ．UVBond と同様に，

6 関連研究

FBCrypt はフレームバッファを二重化し，暗号化さ

Self-Service Cloud（SSC） [3] は，クラウドの管理れたフレームバッファをドメイン 0 に提供する．た者が干渉できないユーザ専用の管理 VM（Udom0）

だし，FBCrypt はページフレーム番号を直接用いたを提供するため，クラウド管理者はリモート管理のメモリ共有にのみ対応している．また，FBCrypt で際に VM リダイレクト攻撃を行うことができない．

は I/O リングの二重化は行っていない．キーボード

Udom0 のディスク整合性は vTPM を用いて検査さ入力については，ハイパーコールを用いて I/O リン

れ，クライアントとの間は SSL で安全に接続される．

グへの書き込みを行うことで，入力が復号される前にユーザは Udom0 を経由して自身の VM を安全に管

VM 内のフロントエンドドライバによってアクセス

理することができる．サービスドメインと呼ばれるされるのを防いでいる．そのため，ドメイン 0 のバッ

VM を用いて安全にディスクの暗号化を行うことも可

クエンドドライバへの修正が必要である．UVBond

能である．しかし，vTPM は DomB と呼ばれる VM

では I/O リングを二重化することで，ディスクドラ

で動作するため，ハイパーバイザに加えて DomB もイバを修正することなく同期の問題を解決している．

信頼する必要がある．また，SSC ではクラウド管理

システムコール列を用いた侵入検知システム [6] で者が VM をまったく管理できなくなる．UVBond では，プロセスによって発行されるシステムコールの呼はクラウド管理者が VM を部分的に管理することがび出し順に基づいて侵入を検知する．プログラムの実可能である．

際の実行をトレースすることによって正常な実行をシ

BitVisor [14] はハイパーバイザ内の準パススルー

ステムコール列として記録しておき，正しいシステム

ドライバを用いてディスクの暗号化を行うことがでコール列にないシステムコールが実行された場合にきる．BitVisor はディスク暗号化に必要な最小限の侵入と判断している．UVBond のハイパーコール列

ハードウェアアクセスのみを横取りし，他のアクセはこれをハイパーバイザに応用したものである．

スはパススルーすることができるため軽量な VM を実現できる．ATA ホストコントローラ用ドライバで

7 まとめ

は PIO 転送と DMA 転送に対応しており，シャドー

本稿では，VM の暗号化ディスクを介してユーザとDMA 記述子やシャドーバッファを用いて DMA 転送

VM を強く結びつけることによって VM リダイレク

時の暗号化を実現している．UVBond と異なり完全ト攻撃を防ぐ UVBond を提案した．UVBond ではハ

仮想化 OS にのみ対応しており，準仮想化ディスクド

イパーバイザレベルでディスクの暗号化・復号化を行

ライバを用いることはできない．

うことにより，ユーザの VM が正しく起動されるこ

CloudVisor [19] はネストした仮想化を用いてハイとを保証する．VM を操作する際は，ハイパーバイザ

パーバイザの下で動作するセキュリティモニタにおいが発行したセキュアな VM 識別子とハイパーコールて，ディスクの暗号化および整合性チェックを行う．

列を用いることにより，ユーザの指定した管理コマン

整合性チェックに必要なハッシュデータは管理 VM 経ドがユーザの VM に対して実行されることを保証す由で提供される．これにより，ユーザが指定したディる．我々は UVBond を Xen に実装し，ディスクを暗スクイメージを用いて VM が正常に起動されること号化するオーバヘッドは 10%以下であることを確認が保証される．しかし，ディスク暗号化は外部からのした．

VM のリモート管理とは結び付けられていないため，

今後の課題は，VM が別のホストにマイグレーショ

ンされた時に VM 識別子を使った安全なリモート管理を継続できるようにすることである，また，UVBondのサポートを libvirt に追加し，クラウド管理システ
ムに適用することを計画している．

参 考 文 献[ 1 ] Azab, A., Ning, P., Wang, Z., Jiang, X.,
Zhang, X., and Skalsky, N.: HyperSentry: Enabling Stealthy In-context Measurement of Hypervisor Integrity, Proc. Conf. Computer and Communications Security, 2010, pp. 38–49.
[ 2 ] Barham, P., Dragovic, B., Fraser, K., Hand, S.,
Harris, T., Ho, A., Neugebauer, R., Pratt, I., andWarfield, A.: Xen and the Art of Virtualization.,
Proc. Symp. Operating Systems Principles, (2003),
pp. 164–177.
[ 3 ] Butt, S., Lagar-Cavilla, H. A., Srivastava, A.,
and Ganapathy, V.: Self-service Cloud Computing,Proc. Conf. Computer and Communications Security, 2012, pp. 253–264.
[ 4 ] CyberArk Software: Global IT Security Service,2009.
[ 5 ] Egawa, T., Nishimura, N., and Kourai, K.: Dependable and Secure Remote Management in IaaS
Clouds, Proc. Int. Conf. Cloud Computing Technology and Science, 2012.
[ 6 ] Hofmeyr, S., Forrest, S., and Somayaji, A.: Intrusion Detection Using Sequences of System Calls,
Computer Security, Vol. 6(1998), pp. 151–180.
[ 7 ] Kourai, K. and Kajiwara, T.: Secure Out-ofband Remote Management Using Encrypted Virtual Serial Consoles in IaaS Clouds, Proc. Int.
Conf. Trust, Security and Privacy in Computing
and Communications, 2015, pp. 443–450.
[ 8 ] Li, C., Raghunathan, A., and Jha, N. K.: Secure Virtual Machine Execution under an Untrusted
Management OS, Proc. Int. Conf. Cloud Computing, 2010, pp. 172–179.
[ 9 ] Li, C., Raghunathan, A., and Jha, N. K.: A

Trusted Virtual Machine in an Untrusted Management Environment, IEEE Trans. Services Computing, Vol. 5, No. 4(2012), pp. 472–483.
[10] McCune, J., Parno, B., Perrig, A., Reiter, M.,
and Isozaki, H.: Flicker: An Execution Infrastructure for TCB Minimization, Proc. European Conf.
Computer Systems, 2008, pp. 315–328.
[11] PwC: US Cybercrime: Rising Risks, Reduced
Readiness, 2014.
[12] Rutkowska, J. and Wojtczuk, R.: Preventing
and Detecting Xen Hyper-visor Subversions, Black
Hat USA, 2008.
[13] Santos, N., Gummadi, K. P., and Rodrigues, R.:
Towards Trusted Cloud Computing, Proc. Workshop Hot Topics in Cloud Computing, 2009.
[14] T. Shinagawa and H. Eiraku and K. Tanimotoand K. Omote and S. Hasegawa and T. Horie and M.
Hirano and K. Kourai and Y. Oyama and E. Kawai
and K. Kono and S. Chiba and Y. Shinjo and K.
Kato: BitVisor: A Thin Hypervisor for Enforcing
I/O Device Security, Proc. Int. Conf. Virtual Execution Environments, 2009, pp. 121–130.
[15] Tadokoro, H., Kourai, K., and Chiba, S.: Preventing Information Leakage from Virtual Machines’ Memory in IaaS Clouds, IPSJ Online
Trans., Vol. 5(2012), pp. 156–166.
[16] TechSpot News: Google Fired Employees for
Breaching User Privacy, http://www.techspot.com/
news/40280-google-fired-employees-for-breachinguser-privacy.html, 2010.
[17] Wang, J., Stavrou, A., and Ghosh, A.: HyperCheck: A Hardware-Assisted Integrity Monitor,
Proc. Int. Symp. Recent Advances in Intrusion Detection, 2010, pp. 158–177.
[18] wolfSSL Inc.: wolfSSL — Embedded SSL Library for Applications, Devices, IoT, and the Cloud,
http://www.wolfssl.com/.
[19] Zhang, F., Chen, J., Chen, H., and Zang, B.:
CloudVisor: Retrofitting Protection of Virtual Machines in Multi-tenant Cloud with Nested Virtualization, Proc. Symp. Operating Systems Principles,
2011, pp. 203–216.