目次


保護されたコンピューティングを IBM Power Architecture 上でサポートする

セキュリティーの影響を受けやすいアプリケーションに関する懸念に対処する

Comments

概要

最近のコンピューティング環境内でコンピューティング・システムへのアクセス管理といったサービスを提供するために、アプリケーションでは、システム・ソフトウェアに依存するのが常となっています。システム・ソフトウェアには (少なくとも) オペレーティング・システムが組み込まれますが、さらにハイパーバイザーも組み込まれることがあります。システム・ソフトウェアはアプリケーションとそのデータを制御するため、従来、信頼できることが必要とされてきました。システム・ソフトウェアに組み込まれたオペレーティング・システムまたはハイパーバイザーは、あらゆるアプリケーションのデータにアクセスして、データを変更することが可能です。場合によっては、こうしたオペレーティング・システムやハイパーバイザーが、アプリケーションで実装するセキュリティー機能を改ざんし、それが検出されないこともあります。このことから、基礎となるソフトウェアを Trusted Computing Base (TCB) の一部にする必要があります。顧客が共有環境を使用する場合、システム・ソフトウェアを開発、構成、デプロイ、管理するエンティティーが悪意のあるものではないことを、顧客は信用せざるを得ません。さらに顧客には、権限をエスカレートする攻撃や、顧客のアプリケーションの機密性と完全性を侵害する攻撃などに、システム・ソフトウェアが脆弱ではないと信用することも強いられます。このように広範な信用を顧客に要求することは、多くの場合、正当化するのが難しいだけでなく、パブリック・クラウド・サービスを使用する顧客にとっては尚更のこと、極めて大きな危険要因になります。この記事では、こうした懸念に対処するために IBM が新しく導入した手法1 について説明します。製品として導入される時点では、一部の機能が異なっている可能性があることにご注意ください。

セキュリティーの影響を大きく受けるアプリケーションでこうした懸念に対処することを動機の 1 つとして、IBM SecureBlue++2,3, Intel SGX4,5,6、AMD Secure Encrypted Virtualization7,8 などのテクノロジーが開発されています。IBM では、IBM Power Systems 上でセキュアな仮想マシン (SVM) をサポートできるようにするための取り組みを行っているところです。具体的には、IBM Protected Execution Facility というファシリティーで、保存中、転送中、実行中の SVM を他のソフトウェアから保護します。これらの SVM をサポートするために、IBM では現在、IBM Power Architecture 内に Ultravisor という新しいモード (図 1 で、赤い枠で示されています) を導入しています。Ultravisor モードには、ハイパーバイザー・モードより高い特権が割り当てられます。

図 1. 新しいシステム・アーキテクチャーに含まれるモード

図 1 に示されているように、最も高い特権レベルの Ultravisor モードから最も低い特権レベルの Problem モードまで、順に特権レベルが下がっていきます。

SVM は、IBM Protected Execution Facility をサポートしているシステム上でのみ稼働することができます。また、SVM を実行するかどうかを指定するのは、その SVM を作成した顧客です。IBM Protected Execution Facility をサポートするシステムごとに、公開鍵と秘密鍵のペアが付与されます。このうち、秘密鍵はそのシステムだけに既知となります (システムの所有者には公開されません)。SVM の作成者は、SVM を作成するためのツールを使用して、SVM の実行を許可された各システムに公開鍵を提供します。最初の製造時に、IBM は各システム上でそのシステムを一意に識別する鍵ペアを生成させて、対応する公開鍵をシステム所有者に配布します。公開鍵が配布された時点で、システム所有者は IBM 提供のツールを使用して、その鍵ペアを変更します。システム所有者は、Trusted Platform Module (TPM) の機能を使用して、システムごとに異なる鍵を使用することも、システムのグループに同じ鍵を使用することもできます。SVM の許可には、IBM は関わらないという点に注目してください。

SVM を作成するには、顧客が次の作業を行う必要があります。

  • SVM として使用することになる VM を作成します。
  • SVM の実行が許可されている各システムの公開鍵を、それぞれのシステム所有者から入手します。
  • IBM 提供のツールを使用して、VM から SVM を作成します。
  • SVM を実行する 1 つ以上のシステムに、SVM を配布します。

SVM が (鍵などの機密情報を含め) 作成された後、その VM は保存中から実行中に至るまで常に暗号によって保護されます。

図 2 に Protected Execution Facility の概要を示しています。図の下の部分はハードウェア環境を表し、中央の部分はファームウェア/ソフトウェア環境、上の部分はアプリケーション環境を表します。Protected Execution Facility は、セキュアで信頼できるブートを基礎として構築されています。秘密鍵が TPM によって保護されている公開鍵/秘密鍵ペアを持つそれぞれのシステムを使用できるのは、正しいものであることが検証されたファームウェアが起動した場合のみです。図の右側下に示されているように、メモリーはセキュア・メモリーと通常のメモリーに分割されます。セキュアなブート・プロセスの一環として、セキュア・メモリーに Protected Execution Ultravisor (以降、Ultravisor と略称) がロードされます。このファームウェアはシステムの制御権を握った後、その制御を OS (通常はハイパーバイザー) に渡します。これにより、OS の実行が開始されます。図の上の部分に示されているように、セキュアな VM が作成されると、その VM の暗号キーが、ターゲット・システムの公開鍵を使用してラップされます。SVM の起動時には、SVM 内のソフトウェアが Ultravisor を呼び出します。すると、Ultravisor がその SVM をセキュア・メモリーに移動した上で、SVM の実行を再開するという仕組みです。同じハードウェア上で通常の VM を実行することもできますが、その場合、通常の VM には保護が追加されません。

図 2. Protected Execution Facility の概要

SVM は、基礎となるハイパーバイザーによるサービスを利用するために、ハイパーバイザー呼び出し (h-コール) を使用します。この新しいモデルには、Ultravisor と呼ばれる新しいモードと、これに関連するファームウェアおよびウルトラバイザー呼び出し (u-コール) が導入されています。Ultravisor と呼ばれるこのファームウェアは、透明性を高めるため、そしてコミュニティーがそのセキュリティーをレビューして強化できるようにするために、オープンソース化される予定です。Ultravisor は SVM とハイパーバイザーの間で行われるすべての呼び出しをフィルタリングし、その特定の呼び出しを実行するために必要な情報だけが、ハイパーバイザーに渡されるようにします。また、SVM にはハイパーバイザーからのレスポンスだけが返されることも確実にします。このハードウェアにより、許可されていないハイパーバイザー仮想マシンや通常の仮想マシンなどのシステム・ソフトウェアがセキュア・メモリーを参照することが阻止されます。一方、ハイパーバイザーはその従来の機能のすべてを引き続き保持します。

注目すべき点は、保存中の SVM を保護する一環として、そのディスクが Linux dm-crypt などのディスク暗号化で保護されることです。このことから当然、いくつかの質問が浮上してきます。

  • ハイパーバイザーは通常の機能を維持する一方で、セキュア・メモリーを参照することは禁止されるという状況の場合、SVM はどのように起動されるのか?
  • ページングはどのように機能するのか?ハイパーバイザーにはSVM メモリーへのアクセス権が与えられるのか?
  • I/O はどのように機能するのか?
  • この大々的な変更は、通常の VM にはどのように影響するのか?
  • パフォーマンスにはどのような影響があるのか?
  • 保護された SVM ディスク・イメージは具体的にどのような内容になるのか?

この記事の残りでは、以上の質問を取り上げていきます。

SVM の起動

SVM は zImage のようにフォーマット化されるため、SVM を変更しなくても、既存のブートローダーでそのままロードできるはずです。ハイパーバイザーは VM を起動する際に、VM (または VM の一部) をメモリー内にコピーして、VM 内で指定されているエントリー・ポイントに制御を渡します。VM と SVM のフォーマットは、エントリー・ポイントを除けば同様です。SVM のエントリー・ポイントは、完全性が保護された、暗号化されていないソフトウェア内にあります。このソフトウェアの役割の 1 つは、通常の VM としての動作を SVM としての動作に遷移させることです。そのために、Enter Secure Mode (ESM) u-コールを実行します。この呼び出しに応じて、Protected Execution Ultravisor は次の処理を行います。

  • SVM をセキュア・メモリーにコピーします。
  • 当該システムに SVM の実行が許可されているかどうかをチェックします。
  • クリア・テキストが変更されていないことを検証します (システムに SVM の実行が許可されている合)。
  • 復号に必要な部分を (完全性をチェックして) 復号します。完全性チェックに合格した場合は、セキュア・メモリー内で実行が再開されます。

SVM がセキュア・メモリー内にコピーされた後、セキュア・メモリー内で SVM の実行が再開されます。セキュア・メモリーの特徴の 1 つは、ハイパーバイザーによってアドレス指定できないことです。

ページング

ページングが必要な場合、Ultravisor は要求された SVM メモリー・ページの暗号化バージョンを作成して、ハイパーバイザーがそれを利用できるようにします (このアーキテクチャーは SVM に対するメモリーのオーバーコミットをサポートしますが、初期段階では、オーバーコミットのサポートは利用できない可能性があります)。SVM を保護するために使用される暗号モードは、Integrity Aware Parallelizable Mode (IAPM)9,10 と呼ばれる、Advanced Encryption Standard (AES) の拡張です。ハイパーバイザー (または他の何か) が暗号化された SVM ページの表現を少しでも変更した場合、IAPM によってその変更が検出されます。当初は同様の機能が調査プロジェクトでデモンストレーションされました11

I/O

SVM は Ultravisor に対し、SVM のメモリーのうち、ハイパーバイザーと共有する特定の保護されていないページを指定できます。このページ共有の指定により、SVM のページ・テーブルが通常のメモリー内のページを指すことになります。初期段階では、SVM 内のすべての I/O は、仮想 I/O に制限されます。ハイパーバイザーは、SVM がハイパーバイザーと共有するように明示的に要求したページしか参照できないため、VirtIO が SVM 内で機能するように変更する必要があります。SVM 内部にあるものは一切、ハイパーバイザーには可視にならないことから、バウンス・バッファーの使用が必要になります。SVM はその役割として、共有ページを介して書き込まれたすべてのデータを適切に保護 (暗号化) します。SVM のメモリーを保護する鍵は、SVM が稼働するシステムの外部では不明であるため、SVM が他のエンティティーと通信するためには共有ページが必要になります。SVM の作成者が通信のセキュリティーについて懸念する場合は、Transport Layer Security (TLS) や同様のメカニズムを使用してデータを保護する必要があります。つまり SVM 内部で、通信プロトコルとしての TLS がセキュア・メモリー内のデータを暗号化した上で、保護されていないメモリーにデータを渡すようにします。

SVM のディスクを暗号化ファイル・システム (dm-crypt など) を使用して保護するとき、VM はコンソールとのやり取りなしでブートすることから、カーネルがパスフレーズを使用できるようにする必要があります。SVM には、dm-crypt (または同様の機能) を使用して保護されたディスクをさらに追加することもできます。その場合、それらのディスクのパスフレーズを SVM 内で保護する必要があります。

VM の I/O 専用ディスク

初期段階では、専用ディスクを SVM に割り当てることは許可されない可能性があります。

パフォーマンスへの影響

通常の VM への影響はごくわずか (基本的にはゼロ) です。ハイパーバイザーと Ultravisor の間のインターフェースは準仮想化されることから、SVM に及ぼす影響も最小限に抑えられます。以前はハイパーバイザーによって制御されていた機能の一部は、Ultravisor によって制御されることになります。ハイパーバイザーがこうした機能を使用する必要がある場合、ハイパーバイザーのアクションが Ultravisor によって承認される必要があります。

保護されていない VM ディスク

dm-crypt や同様のメカニズムによって保護されていないディスクでも、SVM で使用することは可能です。ただし、SVM 内で別のメカニズムによってデータが暗号化されない限り、保護されていないディスクとの間で読み書きされるデータは一切保護されません。

保護された SVM ディスク・イメージ

SVM が Petitboot12 によってロードされる場合、SVM の内容は図 3 に示すようなものになります。この図に示されているように、先頭の部分にはローダーと追加の情報が格納されます。ローダーは ESM u-コールを実行します。ブート・ストラッピング・コードも ESM u-コールを実行します。この呼び出しが SVM に戻るのは、現在のシステム上で SVM の実行が許可されていて、Ultravisor で検証可能なすべての領域のチェックが完了している場合のみです。次の領域では、ブート・プロセス中にシステムに使用できる共有メモリーの量が指定されます。これに続く ESM Blob は、自身を保護する部分であり、ここにターゲット・システムの公開鍵で暗号化された対称鍵と、SVM の管理に使用されるその他のメタデータが格納されます。その後に、ブート・ファイル・システムとルート・ファイル・システムが続きます。デジタル署名保護とは、実行前に、ブート・ファイル・システムのカーネル上の署名と、RAM ディスクから実行されるすべてのファイルの署名をチェックしなければならないことを意味します。チェックに失敗した署名が 1 つでもあれば、ブートは失敗します。ブート層の暗号化とは、dm-crypt などのシステムを指します。

図 3. Petitboot に基づく場合の SVM イメージのフォーマット

まとめ

私たちが構築したファシリティーは、IBM Power Architecture 上で保護された形で SVM を実行できるようにするためのものです。SVM は暗号化されるため、これらの仮想マシンはディスク上にあるときも、(暗号化された送信を使用しないとしても) ネットワーク上で転送されるときも保護されます。各システムの構成には、公開鍵/秘密鍵ペアが使用されます。SVM の実行を許可するための情報は、許可されたシステムの公開鍵を使用して暗号化されます。単一の SVM を複数のマシン上で実行するよう許可できます。SVM がロードされる際は、許可されたシステムにより、SVM が改ざんされていないことが検証されます。改ざんが検出されると、SVM は実行されません。SVM はハイパーバイザー・サービスを使用しますが、不用意にハイパーバイザーに情報が漏洩しないよう保護されます。

謝辞

この記事を作成するにあたり、ディスカッションとテクニカル・レビューで協力してくれた IBM で一緒に働く同僚の Eric Hall、Jens Leenstra、Ramachandra Pai、Ray Valdez、George Wilson、Sarah Wright に感謝の言葉を贈りたいと思います。

  1. この資料に、最初の調査段階で案出した複数の概念が記載されています。この調査は、米国国土安全保障省 S&T/CSD (Science and Technology Directorate, Cyber Security Division) (BAA 11-02)、カナダ国防省 DRDC (DRDC)、米国空軍研究所情報理事会 (契約番号 FA8750-12-C-0243) による後援で行われたものです。資料に記載されている著作権の記述に関わらず、米国政府とカナダ国防省 (DRDC) が行政上の目的でこの資料を複製、配布する権限を有します。資料に記載されている見解および結論は、著者らによるものであり、暗黙的または明示的を問わず、必ずしも米国国土安全保障省、米空軍研究所、米国政府、またはカナダ国防省またはカナダ国防研究開発所 (DRDC) の公式な方針あるいは承認を表すものではありません。
  1. 「CPU Support for Secure Executables」(P. Williams、R. Boivie 共著)。2011 年 6 月 22 日 ~ 24 日にペンシルバニア州ピッツバーグで開催された第 4 回 International Conference on Trusted Computing、Trust 2011 で発表された記事
  1. 「SecureBlue++: CPU Support for Secure Execution」(R. Boivie、P. Williams 共著)。2011 年 9 月 20 日 ~ 22 日にフロリダ州オーランドで開催された第 2 回 Annual NSA Trusted Computing Conference で発表された記事
  1. 『Innovative instructions and software model for isolated execution』(Frank McKeen、Ilya Alexandrovich、Alex Berenzon、Carlos V. Rozas、Hisham Shafi、Vedvyas Shanbhogue、Uday R. Savagaonkar 共著、HASP@ ISCA 10、2013 年)
  1. 『Using innovative instructions to create trustworthy software solutions』(Matthew Hoekstra、Reshma Lal、Pradeep Pappachan、Vinay Phegade、Juan Del Cuvillo 共著、HASP@ ISCA 11、2013 年)
  1. 「Proceedings of the 2nd international workshop on hardware and architectural support for security and privacy」のボリューム 13「Innovative technology for CPU based attestation and sealing」(Ittai Anati、Shay Gueron、Simon Johnson、Vincent Scarlata 共著、ニューヨーク州 ACM、2013 年)
  1. AMD Secure Encrypted Virtualization (SEV)
  1. ホワイトペーパー「AMD Memory Encryption
  1. 「International Conference on the Theory and Applications of Cryptographic Techniques」の529 ページ ~ 544 ページ「Encryption modes with almost free message integrity」(Charanjit S. Jutla 著、Springer、ベルリン、ハイデルベルグ、2001 年)
  1. 「Journal of Cryptology 20」の第 2 回「The security of the IAPM and IACBC modes」(Johan Hastad 著、2007 年) (153 ~ 163)
  1. Final Technical Report Hardware Support for Malware Defense and end-to-end Trust
  1. Petitboot ブートローダー

ダウンロード可能なリソース


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=1064625
ArticleTitle=保護されたコンピューティングを IBM Power Architecture 上でサポートする
publish-date=02072019