Intel SGX を用いるアプリケーションの移送
代表研究者

光 来 健 一九州工業大学大学院情報工学研究院教授

1 はじめに近年，
コンピュータ上で様々な情報を扱うようになり，
情報漏洩に対する対策が喫緊の課題となっている．
これまで，システムの根幹をなす OS において様々な対策が行なわれてきた．例えば，Linux では SELinux [1]や AppArmor [2]などを用いたアクセス制御によりアプリケーションの権限を制限する機能を提供している．
アクセス制限により，マルウェアがアプリケーションの機密情報を盗んだり，機密情報を外部に送信したりすることを防ぐことができる．しかし，OS による対策は OS が攻撃を受けて乗っ取られてしまうと無効化される恐れがある．その結果，マルウェアによる機密情報へのアクセスを制限できなくなったり，OS からアプ
リケーション内の機密情報を盗まれたりする可能性がある．
そこで，最近用いられるようになっているのが Intel SGX [3][4][5]による機密情報の保護である．SGX を用いて作成されたアプリケーション内では，CPU 固有の鍵でメモリが暗号化された保護領域である Enclave を作成することが可能になる．Enclave の中の情報には OS を含むいかなるプログラムもアクセスできないた
め，Enclave の内部で機密情報を扱うことで，マルウェアや OS から機密情報を保護することができる．しかし，SGX を用いる SGX アプリケーションが動作しているコンテナを別のホストにマイグレーションすると，実行を継続できなくなる．Enclave のメモリはそれを作成した CPU の鍵で暗号化されており，マイグレーシ
ョンにより Enclave を実行する CPU が変わると鍵も変わってしまうためである．その結果，Enclave メモリの復号に失敗して Enclave の実行を継続できなくなってしまう．
本研究では，コンテナ・マイグレーション後にも SGX アプリケーション内の Enclave を継続的に実行可能にする MigSGX を提案する．Enclave の状態は SGX による保護により外部から保存・復元することができな
いため，MigSGX では Enclave 自身に状態の保存・復元を行わせる．状態の保存時には Enclave が自身のメ
モリ上のデータを外部メモリに書き出し，状態の復元時には保存したデータで Enclave のメモリを上書きする．その際に，保存した状態データからの情報漏洩を防ぐために，CPU 非依存の鍵を用いて Enclave 内で暗号化・復号化を行う．また，外部メモリに対する書き込みと読み込みをパイプライン処理で行うことにより，小さな外部メモリで巨大な Enclave メモリの保存・復元を可能にする．これらの機能は Enclave 内で動作する MigSGX ライブラリと，Enclave 外部で動作する MigSGX ランタイムを通して SGX アプリケーションに提供される．
我々は MigSGX を Intel SGX SDK 2.2 [6]と CRIU 3.9 [7]に実装した．MigSGX ランタイムは Enclave 内のMigSGX ライブラリを SGX の ECALL 機構を用いて安全に呼び出し，Enclave のヒープ領域とデータ領域の保存・復元を行う．Enclave 内でデータ領域に関する情報を取得できるようにするために，MigSGX はコンパイ
ル後に Enclave プログラムのバイナリに情報を埋め込む．マイグレーションを行う MigSGX マネージャとMigSGX ランタイムの間の通信をできるだけ安全に行えるようにするために，CRIU のパラサイト機構[10] を用いる．MigSGX を用いて SGX アプリケーションのマイグレーションについて性能を測定した．その結果，
Enclave メモリの保存・復元をパイプライン処理することにより，メモリ使用量を減らしてマイグレーショ
ン性能を大幅に向上させられることが分かった．

2 背景
2-1 SGX アプリケーションのマイグレーション
コンピュータで様々な情報を扱うようになるにつれて，機密情報が外部に漏洩する事件が年々増加している．情報漏洩を防ぐために，システムの根幹をなす OS において様々なセキュリティ対策が施されてきた．
例えば，Linux では SELinux [1]や AppArmor [2]などを用いたアクセス制御が提供されており，アプリケー
ションの権限を制限することができる．アクセス制限により，マルウェアの実行やファイルの不正な読み書
き，外部との不正な通信を禁止することができる．これにより，マルウェアが他のアプリケーションの持つ機密情報を盗み出すことを防ぐことができる．

1

図 1 Intel SGX を用いた機密情報の保護

しかし，OS が攻撃を受けて乗っ取られてしまった場合，OS のアクセス制御を無効化される恐れがある．
OS には様々な脆弱性が報告され続けており，それらの脆弱性を用いた攻撃が可能である．OS が攻撃を受けた結果，マルウェアにアプリケーションの情報を読み取られ，機密情報を窃取される可能性がある．さらに，
OS からアプリケーションの情報を読み取ることは容易であるため，OS 内のマルウェアによって機密情報が盗まれる可能性もある．OS の下で動作するハイパーバイザを用いて OS の挙動を監視することもできる[8] が，
ハイパーバイザも同様に攻撃を受ける可能性がある．
そこで，OS やハイパーバイザに依存せずにアプリケーション内の機密情報を保護するために，Intel SGX と呼ばれる CPU の機構が用いられるようになってきた．SGX を用いるアプリケーションでは，図 1 のようにCPU 固有の鍵でメモリが暗号化された保護領域である Enclave を作成することが可能になる．Enclave 内の情報には OS を含むいかなるプログラムもアクセスできないため，Enclave 内部で機密情報を扱うことでマルウェアや OS 等から機密情報を保護できる．Enclave は CPU のみを信頼すればよく，OS やハイパーバイザ等を信頼する必要はない．Enclave では正しく署名されたプログラムのみが実行可能であり，改ざんされた
プログラムは実行できない．
また，実行中の Enclave 内のプログラムやデータを改ざんすることもできない．
しかし，SGX アプリケーションにはマイグレーションを行うことができないという問題がある[12]．マイグレーションは仮想マシンやコンテナ，プロセスを別のホストに移動させる技術である．SGX アプリケーシ
ョンを実行しているホストにメンテナンス等が必要になりホストを停止しなくてはならない場合でも，マイグレーションを行うことによりアプリケーションを継続して実行することができる．マイグレーションはア
プリケーションの内部状態を保存し，移送先ホストで復元することにより実現される．近年，Docker[9] 等のコンテナ型仮想化が普及したことにより，コンテナをマイグレーションする重要性が増している．コンテ
ナは OS によって提供されるアプリケーションのための仮想実行環境であり，仮想マシンと比較して軽量であるという特徴がある．コンテナ・マイグレーションではコンテナ内の各アプリケーション（プロセス）がそれぞれマイグレーションされる．
SGX アプリケーションが動作しているコンテナを通常のコンテナと同様にマイグレーションした場合，移送先で SGX アプリケーションの実行を継続することができなくなる．マイグレーションの際には，SGX アプ
リケーション内の Enclave のメモリは移送元の CPU の鍵によって暗号化された状態のまま移送先に転送される．移送先の CPU が持つ鍵は移送元の CPU の鍵とは異なるため，移送先では Enclave メモリを正しく復号することができない．そのため，Enclave の実行を継続できなくなってしまう．移送先で SGX アプリケーシ
ョン自身が Enclave を一から再作成することで対処することも可能であるが，移送元での Enclave 内の状態が失われ，アプリケーション開発者の負担が大きくなる．
2-2 関連研究
本研究では SGX アプリケーションが動作しているコンテナのマイグレーションを対象としているが，SGX
アプリケーションを含む VM のマイグレーションについては先行研究がある．SGX ハードウェアを拡張する手法[12] では，CPU に新しい命令セットを導入することで Enclave に対して透過的な VM マイグレーションを可能にしている．そのために，移送元ホストと移送先ホストにマイグレーション用 Enclave を作成してリ
モートアテステーションを行い，マスターシークレットを交換する．それぞれのホスト上でマスターシーク
レットを CPU に格納すると，SGX はマイグレーション用の鍵を生成する．移送元ホストが Enclave メモリを2

図 2 MigSGX のシステム構成

転送する際には SGX がこの鍵を用いて Enclave メモリを暗号化し直して書き出し，移送先ホストでも同じ鍵を用いて復号したデータを再作成した Enclave のメモリに格納する．この手法は SGX アプリケーション側でのサポートを必要としないが，Intel SGX が対応しない限り利用することができない．
ソフトウェアのみで実現する手法[13] では，MigSGX と同様に Enclave 自身に状態の保存や復元を行わせる．さらに，Enclave 内で動いているスレッドが停止するのを待ってから状態を保存できるように Two-phase
Checkpointing を行う．また，Enclave 内のスレッドによる Enclave 外部の関数呼び出しも追跡して，移送先でその状態を再現する．これらの機構は MigSGX でも用いることができる．マイグレーション時には，ハイパーバイザが VM 内のゲスト OS に割り込みを送り，OS が SGX アプリケーションにシグナルを送る．攻撃者がシグナルを送ることは考慮されておらず，ゲスト OS への修正も必要となる．
Enclave の内部状態だけでなく，外部の永続状態をマイグレーションできるようにする手法[14] も提案されている．Enclave 外部の永続状態としては，Enclave ごとの専用の鍵によってシール（暗号化）されたデータや単調増加しかしないカウンタなどがある．この手法ではマイグレーション用ライブラリが提供され，
Enclave はライブラリの中で生成された鍵を用いてデータの暗号処理を行う．これにより，鍵を移送先に転送してデータの復号を行うことが可能になる．単調カウンタについては，マイグレーション用ライブラリが移送元での値を転送し，移送先で再設定する．これらの手法は MigSGX でも利用可能である．
GPU 上で動作しているプログラム（GPU カーネル）と協調することによって GPGPU アプリケーションをマ
イグレーションする手法[15] が提案されている．GPU には CPU 側からアクセスできない状態があり，GPU カーネルを CPU 側から一時停止させることもできない．そこで，協調的マルチタスクを実現する GPGPU アプリ
ケーションのためのフレームワークである GLoop [16] を用いることでマイグレーションを実現している．GLoop を用いて GPU カーネルを一時停止し，GPU のすべての実行コンテキストを CPU から取り出せるよ
うにする．その後，プロセスのマイグレーションを行い，移送先で GPU の状態を復元する．GPU カーネルを一時停止させるソフトウェア機構は MigSGX でも利用できる可能性がある．

3 MigSGX本研究では，コンテナ・マイグレーション後にも SGX アプリケーション内の Enclave を継続的に実行可能にする MigSGX を提案する．Enclave の状態は SGX による保護により外部から保存・復元することができな
いため，MigSGX では Enclave 自身に状態の保存・復元を行わせる．移送元ホストでは，Enclave が自身のメ
モリ上のデータを CPU 非依存の鍵を用いて暗号化し，それを外部メモリに書き出すことで状態の保存を実現
する．移送先ホストでは，Enclave 自身が保存したデータを復号して自身のメモリを上書きすることにより状態の復元を実現する．暗号化に用いる CPU 非依存の鍵は，Enclave のリモートアテステーションを利用して移送元と移送先の同一の Enclave 間でのみ共有する．
MigSGX のシステム構成を図 2 に示す．MigSGX は Enclave 内部のプログラムに MigSGX ライブラリを提供する．マイグレーション時に MigSGX ライブラリが Enclave の状態の保存・復元を行うことで，アプリケー
ション開発者にマイグレーションを意識させない．SGX アプリケーションの Enclave 外部では MigSGX ラン
タイムが動作し，マイグレーション時に Enclave の状態を保存・復元するために Enclave 内の MigSGX ライ

3

図 3 MigSGX のマイグレーション手順

ブラリを呼び出す．コンテナの外部では MigSGX マネージャが動作し，MigSGX ランタイムと通信しながら SGX
アプリケーションのマイグレーションを行う．
SGX アプリケーションのマイグレーションの手順は図 3 のようになる．まず，MigSGX マネージャが SGX ア
プリケーション内の MigSGX ランタイムと通信を行い，Enclave の状態の保存を指示する．MigSGX ランタイ
ムが Enclave 内の MigSGX ライブラリを呼び出すと，MigSGX ライブラリは Enclave の状態を取得しながら暗号化し，Enclave 外部のメモリに書き出す．書き出しが終了すると，MigSGX マネージャは SGX アプリケー
ション全体の状態の保存を行う．その際に，書き出された Enclave の状態も一緒に保存される．最後に，保存した状態データを移送先ホストに転送する．
移送先ホストの MigSGX マネージャは，状態データを受け取ると SGX アプリケーションの Enclave 以外の部分を復元する．SGX アプリケーションの復元後，MigSGX マネージャは MigSGX ランタイムと通信を行い，
Enclave の状態の復元を指示する．MigSGX ランタイムは新たに Enclave を作成し，Enclave 内部の MigSGX ラ
イブラリを呼び出す．MigSGX ライブラリは外部メモリに保存されている Enclave の状態データを復号しながら Enclave のメモリを上書きすることにより状態を復元する．

4 実装
我々は MigSGX ライブラリと MigSGX ランタイムを Intel SGX SDK 2.2 [6] に実装し，CRIU 3.9 [7] をベースに MigSGX マネージャを実装した．
4-1 Enclave メモリの保存
Enclave の状態を保存する際に，MigSGX ランタイムはまず，状態を保存するためのバッファを確保する．
次に，Enclave 内の MigSGX ライブラリを ECALL 機構を用いて呼び出す．ECALL はアプリケーション開発者が指定した Enclave 内の関数だけを安全に呼び出せるようにするために SGX が提供する機構である．MigSGX
ライブラリは Enclave の状態として Enclave メモリ上のデータを取得し，それを暗号化して確保したバッフ
ァに書き込む．
我々は Enclave の状態を保存するための ECALL 関数を MigSGX ライブラリに定義し，MigSGX ランタイム
から呼び出せるようにした．Intel SGX SDK では，アプリケーション開発者は Enclave 定義言語（EDL）を用いて，ECALL で呼び出すことのできる Enclave 内の関数を定義する．しかし，この方法ではアプリケーシ
ョンごとに状態保存のための ECALL 関数を定義する必要がある．そこで，MigSGX では EDL を用いずに MigSGX
ライブラリ内部でアプリケーションに依存しない ECALL 関数を定義した．
MigSGX ランタイムはまず，図 4 のように ECALL を用いて Enclave のヒープ領域とデータ領域のサイズを

図 4 Enclave の状態データの取得

4取得し，それらの領域のデータを格納するために必要なバッファを確保する．次に，そのバッファを指定して ECALL を実行し，Enclave のヒープ領域とデータ領域の暗号化されたデータを取得する．ヒープ領域はmalloc 等で動的に確保される領域であり，データ領域は，大域変数または静的変数が含まれる領域である．
0 で初期化された変数はデータ領域ではなく BSS 領域に格納されるが，本研究では区別する必要がない場合
はまとめてデータ領域と呼ぶ．Enclave メモリ上にはスタック領域も存在するが，MigSGX ではマイグレーシ
ョン時に Enclave 内の ECALL 関数が実行中でないことを想定しているため，スタック領域のデータの保存は行っていない．また，移送先で Enclave を再作成する際にプログラムがロードされるため，コード領域についても保存しない．
ECALL で呼び出された Enclave 内の MigSGX ライブラリにおいて，ヒープ領域の先頭アドレスとサイズは
SDK の内部 API を用いて取得可能である．しかし，データ領域についてはプログラムをロードした後のEnclave 内に情報が存在しない．そこで，MigSGX では Enclave プログラムのコンパイル後に生成されたバ
イナリに対して署名を行う際に，バイナリからデータ領域と BSS 領域の先頭アドレスとサイズをそれぞれ取得し，その情報をバイナリに埋め込む．この際に，データ領域と BSS 領域は連続していることを利用して，
データ領域の先頭アドレスと両方の領域のサイズの合計のみを埋め込む．そして，MigSGX ライブラリからその情報を取得できるように，データ領域の情報を取得する API を SDK に追加した．
MigSGX ライブラリはヒープ領域とデータ領域のデータを MigSGX ランタイムのバッファに書き出す際に，CPU 非依存の鍵を使って暗号化を行う．MigSGX ランタイムは Enclave の外部で動作しており，攻撃を受けて情報が漏洩する可能性があるためである．
暗号処理を高速化するために，
CPU の暗号化支援機構である AES-NIを利用する wolfSSL [11]の関数を MigSGX ライブラリに移植した．
MigSGX ランタイムのバッファへのデータの書き込みが完了すると，MigSGX ランタイムは Enclave を終了させる．Enclave は移送先では実行を継続することができないためである．Enclave を終了させておかないと，そのメモリが移送先に転送されることになり，マイグレーション時間が増加する．その後，Enclave を操作するために使われる SGX デバイスをクローズする．CRIU は SGX デバイスの状態を保存できず，マイグ
レーションに失敗してしまうためである．SGX デバイスは Enclave を終了させた後には使われないため，ク
ローズしても動作に影響はない．
4-2 Enclave メモリの復元
Enclave の状態を復元する際に，MigSGX ランタイムはまず，移送元と同じ Enclave プログラムを用いてEnclave を再作成する．その後，Enclave の状態を復元するための ECALL を用いて MigSGX ライブラリを呼び出す．MigSGX ライブラリは，移送元で MigSGX ランタイムのバッファに保存された Enclave の状態データを読み込み，Enclave の内部で復号して Enclave メモリの復元を行う．
移送先で Enclave を再作成する際に，通常通りに Enclave を作成すると Enclave メモリを復元した後でEnclave 内のプログラムを正常に実行することができない場合がある．この問題は移送元の Enclave 内部でポインタ等のアドレスに依存する変数が使われていた場合に生じる．Enclave は OS によってプロセスのメ
モリアドレス空間にランダムに配置され，移送元の Enclave と移送先で再作成した Enclave との間でベースアドレスが変わるためである．移送先の Enclave が移送元のアドレスにアクセスしても，正しいデータにアクセスすることはできない．
そこで，移送先の MigSGX ランタイムは Enclave を移送元と同じアドレスに再作成する．そのために，移送元で Enclave を作成する際に Enclave のベースアドレスを MigSGX ランタイム内に保存しておく．そして，移送先で Enclave を再作成する際には保存しておいたアドレスを指定して Enclave を作成する．Enclave のメモリは mmap システムコールを用いて確保されるため，その第１引数にアドレスを指定することで Enclaveの配置を固定する．このアドレスは移送元で Enclave に使われていたメモリ領域であり，その Enclave は終了させられているため，移送先でも確実に同じアドレスにメモリを確保することができる．
4-3 MigSGX ランタイムとの通信
MigSGX マネージャは SGX アプリケーションに対して Enclave の状態の保存・復元を指示するために，
MigSGX ランタイムと通信を行う必要がある．この通信には様々な方法が考えられるが，アクセス制限を行え
る方法を選択する必要がある．アクセス制限がなければ攻撃者は容易に Enclave の状態を外部メモリに保存させることができ，暗号化された状態データを取得して解析に利用することができる．また，状態保存後に

5

図 5 パラサイト機能を利用した通信は Enclave が終了させられるため，DoS 攻撃を行うこともできる．
ネットワーク通信を用いると IP アドレスやポート番号より細かいアクセス制限は難しい．公開鍵暗号を用いた認証を行う方法も考えられるが，MigSGX マネージャのデジタル証明書の管理が煩雑になる．Unix ド
メインソケットや名前付きパイプを用いると，作成されるファイルに対してパーミッションを設定することでアクセス制限を行うことができる．しかし，SGX アプリケーションを実行したユーザにはアクセスを許可する必要があるため，そのユーザの権限を奪われるとアクセス制限は無力化する．共有メモリやメッセージ
キューを用いると，セグメント識別子やメッセージキュー識別子さえ分かればどのプロセスでもアクセスすることができる．シグナルを用いると，送信元プロセスのユーザ ID に基づいてアクセス制限を行うことができる．しかし，シグナルではシグナル番号以外の情報を送ることができない．
そこで，MigSGX では CRIU のパラサイト機構[10] を用いて通信を行う．パラサイト機構はアプリケーシ
ョンに動的にコードを埋め込んで実行することを可能にする．埋め込まれるコードはパラサイトコードと呼ばれる．まず，MigSGX マネージャは図 5 のように SGX アプリケーションのプロセスを一時停止してパラサ
イトコードを埋め込み，プロセスを再開してパラサイトコードを実行する．パラサイト機構を利用するには管理者権限が必要となるため，管理者権限が奪われない限りは安全に通信を行うことができる．
しかし，パラサイトコードが直接 ECALL を用いて Enclave の保存・復元を行うのは難しい．パラサイトコードから SGX アプリケーションの中の MigSGX ランタイムの関数を呼び出すのが難しいためである．そこで，
MigSGX ランタイムは保存・復元処理を行うスレッドをそれぞれ立ち上げ，メインスレッドとそれぞれのスレ
ッド間で匿名パイプを作成する．匿名パイプはプロセス外部からアクセスできないため安全である．この匿名パイプをパラサイトコードから特定できるようにするために，ファイル記述子に専用の番号を割り当て
る．パラサイトコードは匿名パイプを通じて保存・復元処理を行うスレッドを呼び出し，そのスレッドから
ECALL を用いて MigSGX ライブラリを呼び出す．
4-4 保存・復元のパイプライン処理
大容量メモリを用いる Enclave の保存・復元を効率よく行うために，MigSGX ライブラリと MigSGX ランタ
イムの間で共有メモリを用いてパイプライン処理を行う．パイプライン処理を行わない場合，Enclave メモ
リを一旦，すべて外部メモリに保存するため，Enclave メモリと同じサイズの外部メモリが必要になる．
Enclave メモリのサイズが大きい場合，システム全体のメモリ不足を引き起こし，ディスクとの間でスワップが発生することによって保存・復元の性能が大幅に低下する可能性がある．
MigSGX マネージャは Enclave メモリの保存・復元の開始時にパラサイト機構を用いて MigSGX ランタイムのメモリ上に共有メモリを確保する．そして，その共有メモリへのポインタを MigSGX ライブラリへ渡し，
MigSGX ライブラリが Enclave のメモリを保存・復元する間，その共有メモリを繰り返し利用する．保存・復元が完了すると MigSGX マネージャは共有メモリを解放する．
Enclave メモリの保存時には，MigSGX ライブラリが Enclave の状態データを少しずつ共有メモリへ書き出し，それを MigSGX マネージャが読み込んで外部ファイルへ書き出す．MigSGX ライブラリによる Enclave 内部から共有メモリへの Enclave の状態データの書き込みと，MigSGX マネージャによる共有メモリから外部ファイルへの書き出しを，Enclave のヒープ領域とデータ領域の読み出しがすべて終わるまで繰り返す．
MigSGX マネージャは，共有メモリ上のフラグを監視し，同期をとりながら保存処理を行う．
Enclave メモリの復元時には，MigSGX マネージャが外部ファイルから Enclave の暗号データを共有メモリ
へ少しずつ書き込む．MigSGX ライブラリは共有メモリから Enclave の暗号化データを読み取って復号し，6

図 6 Enclave 間での鍵の共有

復号後のデータを Enclave のメモリへ上書きする．MigSGX マネージャによる外部ファイルから共有メモリへの暗号化データの書き込みと，MigSGX ランタイムによる共有メモリから Enclave 内部への読み込みを，Enclave のヒープ領域とデータ領域の復元がすべて終わるまで繰り返す．MigSGX マネージャは，共有メモリ
上のフラグを監視し，同期をとりながら復元処理を行う．
4-5 鍵管理
MigSGX では信頼できる鍵サーバを用意して，Enclave メモリの暗号化・復号化の際に用いる CPU 非依存の鍵を管理する．SGX アプリケーションをマイグレーションする際には図 6 のようにまず，鍵サーバで鍵を生成し，移送元 Enclave とその鍵を共有する．その際に，Enclave のリモートアテステーションを行い，Enclaveと鍵を一対一に対応づける．移送先で Enclave が再作成されると，鍵サーバとの間で同じ鍵を共有する．その際にも，Enclave のリモートアテステーションを行い，移送元の Enclave と同一である場合にのみ鍵を送信する．これにより，鍵を不正に取得されて，Enclave メモリを復号されることを防ぐ．

5 実験
SGX アプリケーションをマイグレーションした後の動作を確認し，マイグレーションの性能を調べる実験を行った．マイグレーションを行う際には移送元ホストで SGX アプリケーションの状態を保存し，その状態を移送先ホストに転送して，SGX アプリケーションを復元する．SGX アプリケーションとして，Enclave 内
でデータを管理するキーバリューストアを作成した．実験には，Intel Xeon E3-1225 v5 の CPU，4GB のメモリを搭載したマシンを用いた．OS には Intel SGX ドライバをインストールした Linux 4.4.0 を用いた．また，MigSGX を実装した Intel SGX SDK 2.2 および CRIU 3.9 を用いた．
5-1 動作確認
まず，作成したキーバリューストアにいくつかのデータを格納し，その後で MigSGX を用いてマイグレー
ションを行った．その結果，マイグレーション後でも SGX アプリケーションが正常に動作し，マイグレーシ
ョン前に格納していたデータを取り出すことができた．次に，マイグレーションによる性能への影響を調べた．キーバリューストアに set 命令でデータを格納する性能と get 命令でデータを取得する性能をマイグレーションの前後で比較した．実験結果より，マイグレーション後の性能が 1～4%低下していたが，これは誤差の範囲内だと考えられる．
5-2 保存・復元にかかる時間
MigSGX マネージャが SGX アプリケーションの状態を保存・復元するのにかかる時間を測定した．この実
験では，Enclave に割り当てるメモリサイズを 20～160MB まで変化させた．測定結果を図 7 に示す．状態の復元のほうが少し時間がかかっているが，保存にかかる時間も復元にかかる時間も Enclave のメモリサイズにほぼ比例して増加した．しかし，100MB 付近で時間が大きく増加した．これは，Enclave のメモリサイズ
が Enclave ページキャッシュ（EPC）のサイズを超えたためである．実験に用いた CPU における EPC のサイズは約 98MB であった．Enclave が EPC 上にないメモリページにアクセスすると，メインメモリ上に暗号化されて格納されているデータが EPC に読み込まれて復号される．同時に，EPC 上のいずれかのページが暗号化されてメインメモリ上に書き出される．このオーバヘッドのために，Enclave メモリの保存・復元により

7

図 7 保存・復元の性能

図 8 暗号化オーバヘッド

長い時間がかかるようになった．
5-3 暗号化のオーバヘッド
Enclave の内部で CPU 非依存の鍵を用いて AES 暗号化・復号化を行うオーバヘッドを調べるために，暗号化を行なわない場合と性能を比較した．
暗号化を行った場合の保存・復元の性能低下は図 8 のようになった．
Enclave のメモリサイズが 80MB 以下の時の性能低下は保存時で 2.5 倍程度，復元時で 2.2 倍程度であった．
一方，100MB 以上の時にはオーバヘッドが大きく減少し，保存時の性能低下は 1.7 倍程度，復元時は 1.1 倍程度であった．100MB 付近で暗号化のオーバヘッドが減少するのは，EPC のサイズを超えたことにより保存・復元にかかる時間そのものが大幅に増加したためである．
5-4 マイグレーション時間
巨大な Enclave メモリを持つ SGX アプリケーションを作成してマイグレーションに関する性能を測定した．
その際に，パイプライン処理の有用性を確かめるために，パイプライン処理を用いた場合と用いない場合とで性能を比較した．Enclave メモリサイズは 14GB と 16GB の 2 種類で実験を行った．SGX アプリケーショ
ンのマイグレーション時間の測定結果を図 9 に示す．14GB，16GB ともに，パイプライン処理を用いない場
合は SGX アプリケーションのマイグレーション時間が増加することが分かった．特に 16GB では，マイグレ
ーションにかかる時間が大幅に増加した．パイプライン処理を用いることで，マイグレーション時間を 14GBの場合で 8%，16GB の場合で 52%削減できた．
マイグレーション時間の内訳を調べると，パイプライン処理を用いない場合は SGX アプリケーションの保存時間が増加することが分かった．パイプライン処理を用いることで，保存時間を 14GB の場合で 29%，16GBの場合で 34%の時間を削減できた．また，Enclave メモリサイズが 14GB の場合，パイプライン処理を用いて8

図 9 マイグレーション時間

も復元時間は変わらなかった．しかし，16GB の場合は復元時間が大幅に増加することが分かった．これは，復元処理中にメインメモリの空き容量が少なくなりスワップが頻繁に発生したためである．パイプライン処理を用いることで，復元時間を 66%削減できた．一方，SGX アプリケーションの状態データの転送時間はパ
イプライン処理を用いた場合により長くなった．14GB の場合に 7%増加し，16GB の場合に 4%増加した．これ
は，共有メモリを用いる場合には，Enclave メモリのデータを一定サイズごとに外部ファイルに保存し，それらを転送することにより転送効率が悪くなったためである．

6 まとめ
本研究では，コンテナ・マイグレーション後にも SGX アプリケーション内の Enclave を継続的に実行可能にする MigSGX を提案した．Enclave の状態は外部から保存・復元することができないため，MigSGX では
Enclave 自身に状態の保存・復元を行わせる．Enclave の状態データを Enclave の外部メモリに安全に保存するために，CPU 非依存の鍵を用いて暗号化を行う．我々は MigSGX を Intel SGX SDK および CRIU に実装した．実験により，MigSGX によるマイグレーションの後で SGX アプリケーションが正常に動作することを確認できた．また，SGX アプリケーションのマイグレーションにかかる時間は Enclave のメモリサイズにほぼ比
例するが，パイプライン処理を用いない場合はシステムメモリが足りなくなり，大幅に増加する場合がある
ことが分かった．
今後の課題は，SGX アプリケーションの停止時間を減らすためにライブマイグレーションに対応することである．そのためには，Enclave メモリの更新部分だけを保存・転送できるようにする仕組みが必要となる．また，Enclave の状態の暗号化・復号化に用いる CPU 非依存の鍵を鍵サーバと Enclave 間で安全に共有する仕組みを実装することも必要である．

【参考文献】[1] Red Hat, "SELinux Project," https://github.com/SELinuxProject/selinux[2] Canonical Ltd, "AppArmor," https://gitlab.com/apparmor[3] I. Anati, S. Gueron, S. Johnson, and V. Scarlata, "Innovative Technology for CPU based
Attestation and Sealing," Workshop on Hardware and Architectural Support for Security andPrivacy, 2013.
[4] M. Hoekstra, R. Lal, P. Pappachan, V. Phegade, and J. Del Cuvillo, "Using Innovative
Instructions to Create Trustworthy Software Solutions," Workshop on Hardware andArchitectural Support for Security and Privacy, 2013.

9[5] F. McKeen, I. Alexandrovich, A. Berenzon, C. V. Rozas, H. Sha, V. Shanbhogue, and U. R.
Savagaonkar, "Innovative Instructions and Software Model for Isolated Execution," Workshop on
Hardware and Architectural Support for Security and Privacy, 2013.
[6]
Intel
Corporation,"IntelSoftware
Guard
Extensions(Intel
SGX)
SDK,"
https://software.intel.com/en-us/sgx-sdk[7] OpenVZ Team, "CRIU," https://criu.org/[8] T. Garnkel and M. Rosenblum, "A Virtual Machine Introspection Based Architecture for
Intrusion Detection," Proc. Network and Distributed Systems Security Symp., pp.191-206, 2003.
[9] Docker Inc., "Enterprise Container Platform | Docker," https://www.docker.com/[10] OpenVZ Team, "CRIU Compel," https://criu.org/Compel[11] wolfSSL Inc., "wolfSSL Embedded SSL/TLS Library," https://www.wolfssl.com/[12] J. Park, S. Park, J. Oh, J. Won, "Toward Live Migration of SGX-Enabled Virtual Machines,"
Proc. 2016 IEEE World Congress on Services, pp.111-112, 2016.
[13] J. Gu, Z. Hua, Y. Xia, H. Chen, B. Zang, H. Guan, J. Li, "Secure Live Migration of SGX
Enclaves on Untrusted Cloud," Proc. 47th Annual IEEE/IFIP Int. Conf. Dependable Systems andNetworks, pp.225-236, 2017.
[14] F. Alder, A. Kurnikov, A. Paverd, N. Asokan, "Migrating SGX Enclaves with Persistent State,"
Proc. 48th Annual IEEE/IFIP Int. Conf. Dependable Systems and Networks, pp.195-206, 2018.
[15] S. Yuhara, Y. Suzuki, and K. Kono, "An Application Framework for Migrating GPGPU CloudApplications," Proc. IEEE Int. Conf. Cloud Computing Technology and Science, 2018.
[16] Y. Suzuki, H. Yamada, S. Kato, and K. Kono, "GLoop: An Event-driven Runtime forConsolidating GPGPU Applications," Proc. ACM Symp. Cloud Computing 2017, pp.80-93, 2017.

〈発
題

名

Intel SGX を利用するコンテナのマイグレーション機構表資料〉

掲載誌・学会名等
情報処理学会コンピュータセキュ
リティシンポジウム 2018

10

発表年月
2018 年 10 月 22 日