(57)【特許請求の範囲】
【請求項１】
非トラステッド・ユーザ端末にサーバからデータ通信ネットワークを介してオペレーティング・システム・イメージをプロビジョニングする方法であって、ユーザ端末のブートを制御するためのブートローダ・ロジックとセキュリティ・データとを含む耐改ざん性ストレージを有するトラステッド・デバイスが前記ユーザ端末に接続された際に、
前記トラステッド・デバイス上の前記ブートローダ・ロジックを介して前記ユーザ端末をブートするステップと、
前記ブートローダ・ロジックの制御下で、前記ユーザ端末を介して前記トラステッド・デバイスと前記サーバとの間の接続を確立し、前記トラステッド・デバイス上の前記セキュリティ・データを使用して前記サーバを認証するステップと、
前記接続を介して前記サーバからオペレーティング・システムのブート・イメージを受け取るステップと、
前記オペレーティング・システムが前記ユーザ端末において実行されるように、前記ブート・イメージを使用してオペレーティング・システム・イメージを前記サーバから前記ユーザ端末にプロビジョニングするステップとを含む方法。
【請求項２】
前記オペレーティング・システムがハイパーバイザである、請求項１に記載の方法。
【請求項３】
前記ユーザ端末において前記ハイパーバイザの制御下でバーチャル・マシンが実行されるように、少なくとも１つのバーチャル・マシン・イメージを前記サーバから前記ユーザ端末にさらにプロビジョニングするステップを含む、請求項２に記載の方法。
【請求項４】
前記ブート・イメージが、前記オペレーティング・システムのカーネルと、前記オペレーティング・システムのプロビジョニングを容易にするための初期ＲＡＭディスクとを含み、前記方法が、前記ブート・イメージを受け取った際に、前記ユーザ端末上で前記ＲＡＭディスクを開始し前記オペレーティング・システム・カーネルをブートするステップを含む、請求項１ないし３のいずれかに記載の方法。
【請求項５】
前記オペレーティング・システム・イメージがストリーミングによって前記サーバから前記ユーザ端末にプロビジョニングされる、請求項１ないし４のいずれかに記載の方法。
【請求項６】
前記オペレーティング・システム・イメージのストリーミング中に、前記ユーザ端末において前記イメージのブロックをローカル・ストレージにコピーし、それにより前記オペレーティング・システムのローカル・イメージを築き上げるステップを含む、請求項５に記載の方法。
【請求項７】
前記ブロックを前記ユーザ端末のハード・ディスクにコピーするステップを含む、請求項６に記載の方法。
【請求項８】
前記ブロックをコピーすることが、前記ローカル・オペレーティング・システム・イメージがほぼ完成するまで継続する、請求項６または７に記載の方法。
【請求項９】
前記ユーザ端末において前記オペレーティング・システムの動作中に修正された、前記ローカル・オペレーティング・システム・イメージのブロックを、前記ネットワークを介して前記サーバにコピーして返すステップを含む、請求項６ないし８のいずれか一項に記載の方法。
【請求項１０】
前記サーバへの暗号化されたチャネルを確立し、前記暗号化されたチャネルを介して前記オペレーティング・システム・イメージをプロビジョニングするステップを含む、請求項１ないし９のいずれかに記載の方法。
【請求項１１】
前記ブロックを暗号化された形で前記ローカル・ストレージに記憶するステップを含む、請求項６に記載の方法。
【請求項１２】
前記サーバと前記トラステッド・デバイスとの間の安全なデータ通信のために、前記ユーザ端末を介して、前記サーバと前記トラステッド・デバイスとの間で、相互認証されたエンドツーエンドの暗号化済みチャネルを確立するステップを含む、請求項１ないし１１のいずれかに記載の方法。
【請求項１３】
前記オペレーティング・システム・イメージを暗号化解除するための暗号鍵を、前記相互認証されたチャネルを介して前記サーバから受け取り、前記鍵を前記トラステッド・デバイスの前記安全なストレージに記憶するステップを含む、請求項１２に記載の方法。
【請求項１４】
請求項１ないし１３のいずれかに記載の方法をコンピュータに実施させるためのプログラム・コード手段を含む、コンピュータ・プログラム。
【請求項１５】
非トラステッド・ユーザ端末にサーバからデータ通信ネットワークを介してオペレーティング・システム・イメージをプロビジョニングするのを制御するためのデバイスであって、前記デバイスをユーザ端末に接続するための端末インタフェースと、ブートローダ・ロジックおよびセキュリティ・データを含む耐改ざん性ストレージとを備え、前記デバイスが前記端末インタフェースを介して前記ユーザ端末に接続された際に、前記ブートローダ・ロジックが、
前記ユーザ端末をブートすること、
前記ユーザ端末を介して前記デバイスと前記サーバとの間の接続を確立し、前記デバイス上の前記セキュリティ・データを使用して前記サーバを認証すること、
前記接続を介して前記サーバからオペレーティング・システムのブート・イメージを受け取ること、および、
前記オペレーティング・システムが前記ユーザ端末において実行されるように、前記ブート・イメージを使用してオペレーティング・システム・イメージを前記サーバから前記ユーザ端末にプロビジョニングすることを制御するように適合された、デバイス。
【請求項１６】
前記ブートローダ・ロジックが、前記ユーザ端末のブート時に、すでに前記サーバから前記ユーザ端末にプロビジョニングされたローカル・オペレーティング・システム・イメージが前記ユーザ端末におけるローカル・ストレージ中で利用可能であることを示すオフライン・インジケータがセットされているかどうかチェックし、セットされている場合に、前記ユーザ端末上で実行されるように前記ローカル・オペレーティング・システム・イメージのブートを制御するようにさらに適合された、請求項１５に記載のデバイス。
【請求項１７】
前記ブートローダ・ロジックが、前記ローカル・イメージのインテグリティをチェックし、前記インテグリティが確認されたことを条件として前記ローカル・イメージのブートを制御するようにさらに適合された、請求項１６に記載のデバイス。
【請求項１８】
前記デバイスのユーザと通信するためのユーザ・インタフェースを備える、請求項１５ないし１７のいずれか一項に記載のデバイス。
【請求項１９】
前記デバイスがポケットＵＳＢデバイスである、請求項１５ないし１８のいずれか一項に記載のデバイス。
【請求項２０】
非トラステッド・ユーザ端末にデータ通信ネットワークを介してオペレーティング・システム・イメージをプロビジョニングするための装置であって、
前記ネットワークを介して前記オペレーティング・システム・イメージへのアクセスを提供するためのサーバと、
デバイスが非トラステッド・ユーザ端末に接続された際に前記サーバから前記ユーザ端末に前記オペレーティング・システム・イメージをプロビジョニングするのを制御するための請求項１５ないし１９のいずれか一項に記載のデバイスとを備える装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、ユーザ端末へのオペレーティング・システムのプロビジョニングに関する。非トラステッド・ユーザ端末にサーバからデータ通信ネットワークを介してオペレーティング・システム・イメージをプロビジョニングするための方法、装置、およびコンピュータ・プログラムが提供される。
【背景技術】
【０００２】
リモート・デスクトップ技術は、ネットワークに接続されたユーザ端末からネットワークを介してユーザがアプリケーションをリモートに実行できるための、広く利用可能な手段である。従来、これは、ユーザがネットワークを介して接続できるサーバにおいて、アプリケーションの複数のインスタンスをサンドボックス上で実行することによって達成されてきた。より最近のシステムでは、個々のユーザが、サーバ・インフラストラクチャ上で実行されるユーザ自身のバーチャル・マシン（ＶＭ）にアクセスすることができる。当然ながらこのようなシステムでは、セキュリティが、重要な考慮事項である。この目的で、ユーザ・エンドにおけるリモート・デスクトップ動作を制御するためのクライアント・システムを、当事者にとってトラステッドな専用クライアント・デバイス上に提供することができる。このようなシステムが、http://www.tassacorp.com/white-paper/28に記載されており、その目標は特に、システム・ユーザによってデータが構内からダウンロードおよび除去されるのを防止することである。このシステムでは、専用クライアント・デバイスは、それ自体のクライアント・オペレーティング・システム（動作前にサーバからプリインストールまたはプロビジョニング（ストリーミング）された）を有し、このクライアント・オペレーティング・システムは、ユーザ自身のＶＭオペレーティング・システム（これ自体はサーバ上で実行される）のリモート・デスクトップ動作のために、リモート・サーバに安全に接続する機能を提供する。仮想デスクトップ環境を提供する別のこのような専用クライアント・デバイスが、http://shop.lenovo.com/us/sitelets/alt-desktop/overviewに記載されている。
【０００３】
リモート・デスクトップの大きな利点は、そのシンプルな管理可能性である。全てのオペレーティング・システム（ＯＳ）は、サーバに記憶され、１つの中央位置でバックアップおよびアップグレードされ得る。加えて、上に言及したシステムのようにセキュリティを強化するための専用クライアント・デバイスが提供されない限り、ユーザはどんな任意ユーザ端末も自由に使用することができ、特定のマシンまたは構内に拘束されない。しかし、リモート・デスクトップ・システムは、明瞭な欠点を有する。第１に、うまくスケールしない。すなわち、サーバ・リソース、プロセッサ、メモリ、およびネットワークの必要数量は、ユーザの数に伴って線形に増加する。このインフラストラクチャの代価は、さらに高いレートで増加する。加えて、ユーザ端末はサーバに常に接続されていなければならず、それにより、システムはサーバ停止またはネットワーク停止の影響を受けやすくなり、ユーザはオフラインで作業できなくなる。リモート・デスクトップ解決法に伴う別の根本的な問題は、ユーザ端末上で利用可能な多くのリソースを使用しないことである。
【０００４】
ある代替解決法は、ＯＳをユーザ端末において実行できるように、ＯＳのディスク・イメージをサーバからユーザ端末にプロビジョニングすることである。"OS Streaming Deployment", Clerc, Garces-Erice and Rooney,IPCCC Dec 2010には、ＯＳイメージが端末において完全にインストールされる前にＯＳ動作が開始できるように、ストリーミングによってＯＳイメージをユーザ端末に展開するためのシステムが記載されている。この場合もやはり、ＯＳが損なわれていないことがユーザに保証されるように、ストリーミング・システムに伴うセキュリティを考慮する必要がある。サーバ上で利用可能なバーチャル・マシンのディスク・イメージを、ユーザ端末上で実行されるハイパーバイザにストリーミングするシステムが知られている。ハイパーバイザは、ストリーミング・プロセス、およびユーザ端末におけるＶＭの実行を制御する。ＶＭイメージがユーザ端末において完全にインストールされた後は、ユーザはＶＭをオフラインで実行することができ、イメージに対して加えられた修正は、後日にサーバに返すことができる。Ｃｉｔｒｉｘ  Ｓｙｓｔｅｍｓ  ＩｎｃｏｒｐｏｒａｔｅｄのＸｅｎＤｅｓｋｔｏｐ製品が、ユーザＶＭをユーザ端末にストリーミングするためのこのようなシステムを提供している（http://www.citrix.com/English/ps2/products/subfeature.asp?contentID=2300411参照）。同様のシステムが、"OS Streaming with Intel vPro",ttp://communities.intel.com/servlet/JiveServlet/download/3629-1-2406/OS%20Streaming%20within%20Intel%20vPro%20technology.pdf.に記載されている。これらのシステムは、ユーザ端末上のリソースを利用するが、ユーザ端末上で実行されるハイパーバイザがトラステッドであることを必要とする。このことは、純粋なリモート・デスクトップ・システムと比較して、このようなシステムの有用性を著しく制限する。というのは、端末のどのユーザも、その端末を全ての後続ユーザに対して損なう可能性があるからである。
【０００５】
リモート・デスクトップ分野の外では、ＯＳのセキュリティを保証する試みは、マシンにインストールするための暗号化済みＯＳが記憶されたＵＳＢ（ｕｎｉｖｅｒｓａｌ  ｓｅｒｉａｌ  ｂｕｓ）ストレージ・デバイスから、ユーザ・マシンをブートすることを含む。このようなＵＳＢドライブ・システムが、http://www.windowsfordevices.com/c/a/News/Spyrus-Secure-Pocket-Drive-gets-patent-Citrix-certification/に記載されている。Ｓｙｓｔｅｍａｔｉｃ  Ｄｅｖｅｌｏｐｍｅｎｔ  Ｇｒｏｕｐ  ＬＬＣのＬＯＫ−ＩＴデバイス（http://www.lok-it.net/）も同様である。ＵＳＢデバイスからオペレーティング・システムをブートすることはまた、http://en.gentoo-wiki.com/wiki/Booting_encrypted_system_from_USB_stick、およびhttp://linuxconfig.org/secure-online-banking-with-linux-usb-liveにも記載されている。米国特許公開第２０１０／０２８７３６３号Ａ１には、マザーボードにプリインストールされた暗号鍵を使用してＯＳの妥当性がユーザ・コンピュータによって最初に検証される、別の例が提供されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】米国特許公開第２０１０／０２８７３６３号Ａ１
【非特許文献】
【０００７】
【非特許文献１】http://www.tassacorp.com/white-paper/28
【非特許文献２】http://shop.lenovo.com/us/sitelets/alt-desktop/overview
【非特許文献３】"OS StreamingDeployment", Clerc, Garces-Erice and Rooney, IPCCC Dec 2010
【非特許文献４】http://www.citrix.com/English/ps2/products/subfeature.asp?contentID=2300411
【非特許文献５】"OS Streaming with IntelvPro", ttp://communities.intel.com/servlet/JiveServlet/download/3629-1-2406/OS%20Streaming%20within%20Intel%20vPro%20technology.pdf.
【非特許文献６】http://www.windowsfordevices.com/c/a/News/Spyrus-Secure-Pocket-Drive-gets-patent-Citrix-certification/
【非特許文献７】http://www.lok-it.net/
【非特許文献８】http://en.gentoo-wiki.com/wiki/Booting_encrypted_system_from_USB_stick
【非特許文献９】http://linuxconfig.org/secure-online-banking-with-linux-usb-live
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本発明は、非トラステッド・ユーザ端末にサーバからＯＳイメージを安全にプロビジョニングするための非常に効率的なプロセスを提供することを課題とする。
【課題を解決するための手段】
【０００９】
本発明の一態様は、非トラステッド・ユーザ端末にサーバからデータ通信ネットワークを介してオペレーティング・システム・イメージをプロビジョニングする方法を提供する。この方法は、ユーザ端末のブートを制御するためのブートローダ・ロジックとセキュリティ・データとを含む耐改ざん性（ｔａｍｐｅｒ−ｒｅｓｉｓｔａｎｔ）ストレージを有するトラステッド・デバイスがユーザ端末に接続された際に、
トラステッド・デバイス上の前記ブートローダ・ロジックを介してユーザ端末をブートするステップと、
ブートローダ・ロジックの制御下で、ネットワークを介してサーバへの接続を確立し、トラステッド・デバイス上の前記セキュリティ・データを使用してサーバを認証するステップと、
前記接続を介してサーバからオペレーティング・システムのブート・イメージを受け取るステップと、
オペレーティング・システムがユーザ端末において実行されるように、ブート・イメージを使用してオペレーティング・システム・イメージをサーバからユーザ端末にプロビジョニングするステップとを含む。
【００１０】
本発明の実施形態により、非トラステッド・ユーザ端末にサーバからオペレーティング・システム・イメージを安全にプロビジョニングすることができる。トラステッド・デバイス（好都合には、ポケットＵＳＢデバイスなどの小型ポータブル・デバイス）がユーザに提供され、このデバイスをユーザ端末に接続することができる。このデバイスはシステム・オペレータまたは他のトラステッド・エンティティによってユーザに供給されてよく、このデバイスは、ブートローダ・ロジックとセキュリティ・データとを含む耐改ざん性ストレージを有する。ユーザは、非トラステッドであるが好都合なユーザ端末を選択して、トラステッド・デバイスを接続することができる。接続されると、ユーザ端末は、トラステッド・デバイス上のブートローダ・ロジックを介してブートされる。次いで、ブートローダ・ロジックは、ネットワークを介してサーバへの認証された接続を確立し、必要とされるＯＳイメージへのアクセスを提供する。このプロセスにおいて、サーバは、トラステッド・デバイスにプリインストールされたセキュリティ・データを使用して認証される。次いで、認証された接続を介してサーバからオペレーティング・システムのブート・イメージが得られ、ブート・イメージを使用して、必要とされるＯＳイメージがサーバからユーザ端末にプロビジョニングされ、したがって、ユーザ端末においてＯＳを実行することができる。これにより、非トラステッド端末にネットワークを介してＯＳイメージを安全にプロビジョニングするための単純明快なシステムが提供される。改ざん防止（ｔａｍｐｅｒ−ｐｒｏｏｆ）ストレージ中のセキュリティ・データを介して検証されたサーバへの認証された接続は、ＯＳがトラステッド・ソースから得られること、したがってＯＳ自体もユーザにとってトラステッドとなり得ることを保証する。さらに、このシステムによりユーザは、端末がトラステッドであることを必要とせずに、どんな任意ユーザ端末も利用することができ、端末のリソースを活用してＯＳイメージを実行することができる。ユーザ端末にプリインストールされた、どんなＯＳまたは他の損なわれている可能性のあるソフトウェアも、システムの動作に必要とされず、したがって、非トラステッド端末の使用に通常なら付きものであるセキュリティ・リスクを回避することができる。このように、トラステッドなＯＳイメージを、端末の「ベア・メタル」上に、すなわち基本的なマシン・ハードウェアのみを使用して、安全にインストールすることができ、それによりＯＳのインテグリティを保証することができる。
【００１１】
ユーザ端末にプロビジョニングされるＯＳイメージは、サーバにおいて維持されるユーザのバーチャル・マシンのＯＳイメージとすることができる。しかし、ハイパーバイザもまた、述べたプロセスを介して等しく安全にプロビジョニングすることができる。したがって、トラステッド・デバイスからのブート時に、ハイパーバイザのＯＳイメージである初期ＯＳイメージを端末にプロビジョニングすることができる。次いで、ユーザ端末においてハイパーバイザの制御下でバーチャル・マシンが実行されるように、少なくとも１つのバーチャル・マシン・イメージをサーバからさらにプロビジョニングすることができる。このようにして、ユーザは、端末上で実行される全てのソフトウェア（ハイパーバイザ自体を含む）がサーバから安全にプロビジョニングされた状態で、非トラステッド端末において１つまたは複数のＶＭを扱うことができる。
【００１２】
ユーザ端末において実行されるようにＯＳをプロビジョニングすることは、様々な方式で実施することができる。いくつかの基本的な実施形態では、単純に、ＯＳがユーザ端末において動作する前に、ＯＳイメージ全体をダウンロードすることができる。しかし、好ましい実施形態では、ストリーミングによるプロビジョニングを実施し、それにより、ユーザ端末においてＯＳの動作がより迅速に開始することができる。特に好ましい実施形態では、ＯＳイメージのストリーミング中に、ユーザ端末においてイメージのブロックがローカル・ストレージ（例えばユーザ端末のハード・ディスク）にコピーされ、それにより、オペレーティング・システムのローカル・イメージが築き上げられる。ＯＳの動作において、必要とされるブロックが利用可能ならばそれにローカルにアクセスすることができ、または、利用可能でなければサーバからストリーミングしてローカル・ストレージに追加することができる。動作において修正されたローカルＯＳイメージのブロックは、好都合なようにネットワークを介してサーバにコピーして返すことができる。この「ストリーミング展開」技法は、ＯＳ実行を加速させることができ、最終的にはユーザ端末のオフライン動作を可能にすることができる。特に、ＯＳイメージ・ブロックをコピーすることは、ローカルＯＳイメージがほぼ完成するまで、すなわち少なくとも、ＯＳがサーバへのプロビジョニング接続から独立して実行できるほど十分に完成するまで、継続することができる。次いでユーザは、サーバから切断して、端末をオフラインで使用することができる。オフライン動作中にローカルＯＳイメージに加えられた変更は、後の段階でサーバに転送して返すことができる。
【００１３】
いくつかの実施形態では、サーバへの認証された接続は、ユーザ端末を介して、トラステッド・デバイスとサーバとの間で確立することができる。他の実施形態では、この接続は、ユーザ端末とサーバとの間であり、トラステッド・デバイスを介してルーティングされない。セキュリティ強化のために、好ましいプロビジョニング方法は、サーバへの暗号化されたチャネルを確立し、暗号化されたチャネルを介してオペレーティング・システム・イメージをプロビジョニングするステップを含む。この暗号化されたチャネルは、ＯＳブート・イメージが端末に通信される際に経由する最初の認証された接続として確立することができる。しかし、実施を簡略にするためには、暗号化されたチャネルは、ブート・イメージが最初の接続を介して受け取られた後で別個に確立してもよい。これにより、ＯＳイメージ・ブロックは、サーバからの搬送中に暗号化される。ブロックをローカルに記憶することによってローカルＯＳイメージを築き上げる実施形態では、ブロックをそれらの暗号化された形でローカル・ストレージに記憶することができる。これにより、適切な暗号化解除鍵を有さない無許可の当事者はローカル・ストレージにコピーされたブロックを読み取ることができないことが保証される。最大限のセキュリティのためには、ローカルに書き込まれたブロックの暗号化解除／暗号化を動作中に動的に実施することができる。
【００１４】
特に好ましい実施形態は、サーバとトラステッド・デバイスとの間の安全なデータ通信のために、ユーザ端末を介して、サーバとトラステッド・デバイスとの間で、相互認証されたエンドツーエンドの暗号化済みチャネルを確立することを含む。このチャネルは、前述の、ＯＳイメージをプロビジョニングするための最初の接続または暗号化されたチャネルあるいはその両方とすることができる。しかし、効率的な実装形態では、サーバとトラステッド・デバイスとの間のこのチャネルを、ＯＳプロビジョニング・チャネルとは別個に提供することができ、それにより、トラステッド・デバイスを介してユーザ端末にＯＳイメージ・ブロックをルーティングする必要はない。サーバとトラステッド・デバイスとの間のこのチャネルは、セキュリティに注意を要するほとんどの通信、例えば、システムの動作において使用される暗号鍵の通信に、使用することができる。例えば、オペレーティング・システム・イメージ・ブロックの暗号化を解除するための鍵を、この安全なチャネルを介してサーバから受け取り、トラステッド・デバイスの安全なストレージに記憶することができる。好ましい実施形態では、この安全なチャネルのセットアップは、ユーザが適切に許可されていることを確認するためのユーザ入力を必要とする。例えば、トラステッド・デバイスのユーザ・インタフェースを介して有効なパスワードもしくはＰＩＮ（ｐｅｒｓｏｎａｌ  ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｎｕｍｂｅｒ）を入力すること、または、ユーザを識別するスマート・カードをトラステッド・デバイスに挿入することを必要とする。
【００１５】
本発明の第２の態様は、非トラステッド・ユーザ端末にサーバからデータ通信ネットワークを介してオペレーティング・システム・イメージをプロビジョニングするのを制御するためのデバイスを提供する。このデバイスは、デバイスをユーザ端末に接続するための端末インタフェースと、ブートローダ・ロジックおよびセキュリティ・データを含む耐改ざん性ストレージとを備える。ブートローダ・ロジックは、デバイスが端末インタフェースを介してユーザ端末に接続された際に、
ユーザ端末をブートすること、
ネットワークを介してサーバへの接続を確立し、トラステッド・デバイス上の前記セキュリティ・データを使用してサーバを認証すること、
前記接続を介してサーバからオペレーティング・システムのブート・イメージを受け取ること、および、
オペレーティング・システムがユーザ端末において実行されるように、ブート・イメージを使用してオペレーティング・システム・イメージをサーバからユーザ端末にプロビジョニングすることを制御するように適合される。
【００１６】
上に論じたような、ユーザ端末のオフライン使用を可能にするシステムでは、ブートローダ・ロジックはさらに、ユーザ端末のブート時に、オフライン・インジケータがセットされているかどうかチェックするように適合されてよい。オフライン・インジケータがセットされている場合、これは、サーバとの保留セッション中にすでにユーザ端末にプロビジョニングされたローカルＯＳイメージが、ユーザ端末におけるローカル・ストレージ中で利用可能であることを示す。オフライン・インジケータは、ブートローダ・ロジックからアクセス可能な任意のローカル・ストレージ中で維持されてよいが、ユーザ端末のハード・ディスクの最初にある単純なフラグであることが好都合である。オフライン・インジケータがセットされていることがわかった場合は、次いでブートローダ・ロジックは、ユーザ端末上で実行されるようにローカルＯＳイメージのブートを制御する。このような、前にプロビジョニングされたローカルＯＳイメージをブートすることは、ローカル・イメージに対するインテグリティ・チェックをブートローダ・ロジックによって実施するのを条件とすることができる。
【００１７】
本発明の別の態様は、非トラステッド・ユーザ端末にデータ通信ネットワークを介してオペレーティング・システム・イメージをプロビジョニングするための装置を提供する。この装置は、ネットワークを介してオペレーティング・システム・イメージへのアクセスを提供するためのサーバと、デバイスがユーザ端末に接続された際に非トラステッド・ユーザ端末にサーバからオペレーティング・システム・イメージをプロビジョニングするのを制御するための本発明の第２の態様によるデバイスとを備える。
【００１８】
本発明の別の態様は、本発明の第１の態様による方法をコンピュータに実施させるためのプログラム・コード手段を含むコンピュータ・プログラムを提供する。（用語「コンピュータ」は、最も一般的な意味で使用され、コンピュータ・プログラムを実施するためのデータ処理能力を有する任意のデバイス、コンポーネント、またはシステムを含むことは、理解されるであろう。さらに、本発明を具体化するコンピュータ・プログラムは、独立したプログラムを構成してもよく、またはより大きいプログラムの要素であってもよく、コンピュータにロードされるように供給されてよい（例えば、ディスクや電子的伝送などのコンピュータ可読媒体に組み入れられてよい）。コンピュータ・プログラムのプログラム・コード手段は、当該方法を、直接に、あるいは（ａ）別の言語、コード、もしくは表記法に変換された後と（ｂ）異なる材料形式で複製された後とのいずれかまたは両方で、コンピュータに実施させるように意図された、１組の命令を、任意の言語、コード、または表記法によって任意に表現したものを含んでよい。）
【００１９】
一般に、本明細書で、本発明の一態様の一実施形態に関して特徴が記述される場合、対応する特徴が、適宜、本発明の別の態様の実施形態でも提供されてよい。
【００２０】
次に、本発明の好ましい実施形態を、添付の図面を参照しながら例として述べる。
【図面の簡単な説明】
【００２１】
【図１】本発明を具体化するＯＳプロビジョニング・システムの概略図である。
【図２】図１のシステムのトラステッド・デバイスのより詳細な概略図である。
【図３】図１のシステムにおけるＯＳプロビジョニング・プロセスの主要ステップを示す図である。
【図４】図１のシステムにおけるＯＳプロビジョニング・プロセスのより詳細なステップを示す図である。
【図５】図４のＯＳプロビジョニング・プロセスの後続ステップを示す図である。
【図６】図４および５のプロセスを介してプロビジョニングされるユーザ端末のアーキテクチャの概略図である。
【図７】プロビジョニングされたユーザ端末のオフライン動作におけるステップを示す図である。
【発明を実施するための形態】
【００２２】
図１に、本発明を具体化するＯＳプロビジョニング・システム１の基本的なコンポーネントを示す。システムはＯＳサーバ２を含み、ＯＳサーバ２から、データ通信ネットワーク３を介してサーバに接続されたユーザ端末にオペレーティング・システムをプロビジョニングすることができる。サーバ２は、ユーザに代わってＯＳイメージを維持し、プロビジョニング・プロセスを介してこれらのイメージへのアクセスを提供する。この例では、サーバ２によってプロビジョニングできるＯＳイメージは、全てのユーザによって一般に使用されるハイパーバイザと、個々のシステム・ユーザに特有である１組のバーチャル・マシンとを含む。サーバ２は、図では単一のブロックとして示されているが、一般には、述べたＯＳプロビジョニング機能を提供するサーバ・システムの、１つまたは複数のマシンを含み得る。ネットワーク３は、一般に、１つまたは複数のコンポーネント・ネットワークまたはインターネットワークあるいはその両方を含み得る。図では、単一のユーザ端末４がネットワーク３に接続されるのが示されている。ユーザ端末４は、任意の汎用コンピュータ・デバイス、例えば普通のユーザ・コンピュータ（デスクトップ、ラップトップ、ＰＤＡ（パーソナル・ディジタル・アシスタント）、携帯電話機など）とすることができる。特に、端末４は、ユーザによってもサーバ２のオペレータによってもトラステッドな必要はない。端末４のプロビジョニングは、トラステッド・デバイス５によって制御され、トラステッド・デバイス５は、システム・オペレータによってユーザに供給されたものとすることができ、端末４に接続され得る。トラステッド・デバイス５については様々なフォームファクタを想定することができるが、このデバイスは、ポケット・デバイス、すなわち、ユーザのポケットに入れて容易に持ち運べるサイズの小型ポータブル・デバイスであることが最も好都合である。この好ましい実施形態では、デバイス５は、図２により詳細に示すようなポケットＵＳＢストレージ・デバイスである。
【００２３】
図２は、トラステッド・デバイス５の主なコンポーネントを示す概略ブロック図である。デバイスは、デバイスをユーザ端末４に接続するための端末インタフェース（Ｉ／Ｆ）（ここではＵＳＢインタフェース６）を有する。デバイスはまた、デバイス・ユーザとの対話のためのユーザ・インタフェース７を有する。この例におけるユーザ・インタフェース７は、表示装置および基本的なキー入力機構を備え、それにより、動作中に情報をユーザに対して表示することができ、ユーザは応答や命令などをデバイスに入力することができる。デバイス５は、デバイスの動作全般を制御するための制御ロジック８を備える。制御ロジック８は、安全な（耐改ざん性）ストレージ９を備え、ストレージ９は、ブートローダ・プログラム・ロジックおよびセキュリティ・データを含む。ブートローダ・ロジック（または単に「ブートローダ」）は、後で詳細に述べる機能を実施するためのプログラム・コード（および任意の関連データ）を含む。ここでのセキュリティ・データは、サーバおよびユーザの認証に使用される暗号証明書と、デバイス５の特定ユーザに割り当てられた暗号公開鍵／秘密鍵の対の秘密鍵（シークレット・キー）ｓｋとを含む。制御ロジック８は、ハードウェアとソフトウェアの組合せによって実現することができ、安全なストレージ９は、内容が勝手にいじられるのを阻止するために、任意の好都合な方式で改ざんから物理的に保護される。例えば、ストレージ９は、１つまたは複数の自己破壊型データ・コンテナによって具体化されてよく、したがって、改ざんされると、破壊されるかさもなければデバイスを使用不可能にする。または、制御ロジック８は、耐改ざん性エポキシを使用してデバイス５に埋め込まれた安全なチップとして実現することができる。あるいは、この両方として実現することができる。
【００２４】
トラステッド・デバイス５中のブートローダ・ロジックは、システム１におけるＯＳプロビジョニング・プロセスの実施を制御するための機能を提供する。ブートローダ・ロジックは一般に、述べた機能を実施するための１つまたは複数のブートローダ・コンポーネント・モジュールを備えてよい。この特定の例では、ブートローダは、マスタ・ブート・レコード（ＭＢＲ）、ミニブートローダ、およびネットワーク・ブートローダを備える。これらのコンポーネントの動作を、まずシステム１における基本的なＯＳプロビジョニング・プロセスについて述べる。
【００２５】
図３の流れ図は、このプロセスの主要ステップを示すＯＳプロビジョニング動作の概観を示している。動作は、ユーザが任意のユーザ端末４を選択して、トラステッド・デバイス５を端末のＵＳＢポートに接続したときに開始する。これは図のステップ２０で表される。ステップ２１で、ユーザは、端末マシンをオンに切り替える。端末４のファームウェアがＵＳＢストレージを自動的にブートオフするように設定されていてよく（例えば、利用可能な場合の好ましいオプションとして）、または、ユーザは、電源投入時に端末においてこのオプションを通常の方式で選択することができる。安全なストレージ９の、端末ファームウェアから見える部分が、ブート可能にイネーブルにされ、前述のブートローダ・コンポーネントをブート可能パーティション内部に含む。したがって、ステップ２２で、端末は、トラステッド・デバイスからブートし、ブートローダ・コンポーネントは、ブートのチェーンを制御して、ついにはネットワーク・ブートローダが開始される。ステップ２３で、ネットワーク・ブートローダは、ネットワーク３を介してＯＳサーバ２に（例えばＯＳサーバ２の最初のブート・サーバに）接続する。ステップ２４で、ネットワーク・ブートローダは、安全なストレージ９のセキュリティ・データに記憶された適切なサーバ証明書（例えば最初のブート・サーバに対する証明書）にアクセスしてサーバを認証し、サーバと安全なＨＴＴＰＳ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ  Ｓｅｃｕｒｅ）接続を確立する。ステップ２５で、端末にプロビジョニングされることになるＯＳのブート・イメージが、ＨＴＴＰＳ接続を介してサーバから受け取られる。特に、ネットワーク・ブートローダは、安全な接続を介して、（暗号化された）ブート・イメージをサーバからコピーする。この事前サーバ認証は、受け取ったブート・イメージが信頼できるものであることを保証する。このブート・イメージの例については後述するが、このブート・イメージは、プロビジョニング環境を確立するための必要最小限の内容を少なくとも含む。ステップ２６で、ネットワーク・ブートローダは、ブート・イメージを使用して、必要とされるＯＳイメージをユーザ端末４にプロビジョニングする。特に、ブート・イメージを使用してＯＳプロビジョニング環境がセットアップされ、この環境で、端末マシン上で実行されるようにＯＳイメージがＯＳサーバ２からプロビジョニングされる。このプロセスの特定の例については後で詳述する。このようにしてＯＳイメージがトラステッド・サーバから得られるので、ＯＳのインテグリティを保証することができる。ＯＳイメージは、ステップ２６で、必要とされる時間だけ長くプロビジョニングされ（後でさらに論じる）、その後、図３の基本的なプロビジョニング・プロセスは完了する。
【００２６】
この好ましい実施形態では、上述した基本的なプロセスを使用して、ハイパーバイザと、当該ユーザからアクセス可能な１つまたは複数のバーチャル・マシン・イメージとの両方がユーザ端末４にプロビジョニングされる。次いで、ハイパーバイザの制御下で、バーチャル・マシン・イメージをユーザ端末において実行することができる。プロビジョニングは、ストリーミングによって、より詳しくはストリーミング展開によって実施され、これにより、サーバからストリーミングされたイメージのブロックがユーザ端末におけるローカル・ストレージにコピーされ、それにより当該ＯＳのローカル・イメージが築き上げられる。最初のハイパーバイザ・プロビジョニングのためのこのプロセスの主要ステップを、図４に関して以下に述べる。
【００２７】
図４に、ＯＳサーバ２（図の左側に示す）、ユーザ端末４（図の中央右）、およびトラステッド・デバイス５（図の右側）によって実施される、ハイパーバイザのプロビジョニングにおける連続的なステップを示す。この図のステップ（ａ）は、概して図３のステップ２０〜２２に対応し、これにより、ユーザ端末４（最初はその「ベア・メタル」状態にある）が、トラステッド・デバイス５上のブートローダ・ロジックを介してブートされる。ステップ（ｂ）で、ネットワーク・ブートローダによって、サーバ２への認証された接続が確立され、これは図３のステップ２３および２４に対応する。ステップ（ｃ）は、図３のステップ２５に対応し、これにより、ハイパーバイザの暗号化済みブート・イメージがサーバ２から受け取られる。ブート・イメージは、ハイパーバイザのカーネルと、ハイパーバイザの後続プロビジョニングを容易にするためのプログラム・ロジックを含む初期ＲＡＭディスクとを含む。この例では、ＲＡＭディスクは、後述する動作におけるネットワーク接続性に必要とされるデバイス・ドライバと、サーバからのハイパーバイザ・イメージのストリーミング展開を制御するためのストリーミング・ロジックを提供するストリーミング・デバイス・ドライバ（以下「ストリーミング・ドライバ」）と、ストリーミングされたハイパーバイザ・イメージ・ブロックの暗号化／暗号化解除のためのプログラム・ロジックを提供する暗号化モジュールと、トラステッド・デバイスについてのプロキシ・アプリケーションとを含む。次に、ステップ（ｄ）で、ネットワーク・ブートローダは、ハイパーバイザ・ブート・イメージの暗号化を解除し、これを端末のメモリ・ディスクにインストールし、次いでこれをブートする。したがって、ユーザ端末上で、ＲＡＭディスクが開始され、ハイパーバイザ（「ｈｙｐ」）カーネルがブートされる。加えて、ネットワーク・ブートローダは、ユーザ端末４上で、トラステッド・デバイス５についてのプロキシ・アプリケーションを開始する。このプロキシは、プロセスの後続ステップによって必要とされる暗号化／暗号化解除のために、トラステッド・デバイスを介してサーバ２から受け取られたかまたは端末４によって送られた、必要とされるパケットのルーティングを可能にする。このようなプロキシ・アプリケーションは、周知であり、適切な実装形態は当業者には容易に明らかであろう。
【００２８】
プロキシが開始されると、プロセスのステップ（ｅ）で、トラステッド・デバイス５の制御ロジック８は、プロキシ・アプリケーションの助けによってサーバとトラステッド・デバイスとの間で安全にデータを通信するために、ユーザ端末４を介して、ＯＳサーバ２とトラステッド・デバイス５との間で、相互認証されたエンドツーエンドの暗号化済みチャネルを確立する。この安全なチャネルは、この例では、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ）プロトコルを使用する。ＴＬＳセッションの確立において、ＯＳサーバは、安全なストレージ９からの適切な証明書（すなわち、現在のチャネルが確立される対象となるＯＳサーバ２における特定のサーバ・マシンに対する証明書であり、このサーバ・マシンは、上のステップ（ｂ）で認証されたサーバ・マシンとは異なる可能性がある）を使用して、制御ロジック８によって認証される。加えて、制御ロジック８は、安全なストレージ９中に保持されるユーザ証明書を用いて、トラステッド・デバイスをサーバ２に対して認証する。この認証ステップの一部として、ユーザは、デバイス・ユーザ・インタフェース７を介して適切なＰＩＮまたはパスワードを入力することによって自分のデバイス使用権限を証明する必要があるのが理想的である。安全なＴＬＳチャネルが確立されると、トラステッド・デバイス５は、サーバからの暗号化された通信を、安全なストレージ９中に保持される秘密鍵ｓｋを使用して暗号化解除することができる。図４のステップ（ｆ）で、この安全なチャネルが制御ロジック８によって使用されて、続いて起こるプロセスにおいてストリーミングされることになるハイパーバイザ・イメージ・ブロックの暗号化解除のための鍵が得られる。このハイパーバイザ・キーは、安全なストレージ９に記憶され、後続の動作で必要とされるのに応じて制御ロジック８によって利用可能にされる。
【００２９】
図４のステップ（ｇ）で、ネットワーク・ブートローダは、上のステップ（ｄ）で受け取ったハイパーバイザ暗号化モジュールおよびストリーミング・ドライバをインストールする。次に、ステップ（ｈ）で、ネットワーク・ブートローダは、ｉＳＣＳＩ（ｉｎｔｅｒｎｅｔ  Ｓｍａｌｌ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｆａｃｅ）プロトコルを使用して、ＯＳサーバへのさらに別の暗号化されたチャネルを確立する。次いで、このチャネルは、ステップ（ｉ）でハイパーバイザ・ストリーミング・ドライバによって使用されて、ハイパーバイザの暗号化済みイメージ・ブロックがＯＳサーバ２からプロビジョニングされる。このチャネル上のパケットは、トラステッド・デバイス５を介してルーティングされないことに留意されたい。しかし、このチャネルを介してストリーミングされるハイパーバイザ・イメージ・ブロックは、ステップ（ｆ）でＴＬＳチャネルを介してトラステッド・デバイスに送られた鍵に従って暗号化されている。したがって、全てのパケットがデバイス５を介してルーティングされる場合に達成可能であろう速度よりも速い動作を可能にしながらも、セキュリティが保証される。ストリーミング・ドライバは、サーバ２から受け取られたハイパーバイザ・イメージ・ブロックを、ユーザ端末４におけるローカル・ストレージ（この例ではハード・ディスク）に記憶する。このようにして、ストリーミングが進行するにつれてハイパーバイザのローカル・イメージが徐々に築き上げられる。後でさらに論じるように、このストリーミング展開プロセスを、端末が「完全にプロビジョニングされる」まで、すなわちローカル・イメージが実質的に完成されるまで、継続することができる。いずれの場合も、図４のプロセスのステップ（ｊ）で、ネットワーク・ブートローダは、ローカル・ファイル・システムをＲＡＭディスクからハード・ディスクに変更する。次いで、ハイパーバイザ・プロビジョニング・プロセスは完全に確立され、ハイパーバイザは、ストリーミング・ドライバの制御下でユーザ端末において実行される準備が整う。
【００３０】
ハイパーバイザが実行中になれば、１つまたは複数のユーザＶＭをユーザ端末にさらにプロビジョニングすることができる。ここでの基本的なプロセスを、図４のプロセスの続きとして図５に示す。したがって、図５のステップ（ｋ）で、ハイパーバイザは、ＯＳサーバ２における、現在のユーザにアクセス許可されているバーチャル・マシンのリストを得る。ハイパーバイザは、トラステッド・デバイス５からこのＶＭリストを得るが、トラステッド・デバイス５は、このＶＭリストを、上記のステップ（ｅ）で確立された安全なＴＬＳチャネルを介してＯＳサーバから受け取る。ＶＭリストは、ハイパーバイザのウィンドウ・マネージャを使用して、端末４においてユーザに提示することができる。ステップ（ｌ）で、ユーザは、これらのＶＭイメージのうちでブートすべき１つまたは複数を選び、この選択は、ハイパーバイザによって、トラステッド・デバイス５の制御ロジック８に渡される。ステップ（ｍ）で、制御ロジック８は、選択された各ＶＭに対するセッション・キーを、安全なＴＬＳチャネルを介してＯＳサーバ２から得る。これらのセッション・キーは、続いて起こる動作においてそれぞれのＶＭのイメージ・ブロックを暗号化解除するのに必要とされる。セッション・キーは、安全なストレージ９に記憶され、ＶＭ動作を制御するためにハイパーバイザに利用可能にされる。プロビジョニングされることになるバーチャル・マシンに関するメタ・データ、例えばＯＳタイプ、ハードウェア仕様、メモリ要件などもまた、セッション・キーと共に得られ、制御ロジック８によってハイパーバイザに供給される。各ユーザＶＭにつき、プロセスのステップ（ｎ）で、ハイパーバイザは、対応するセッション・キーを介したＶＭイメージ・ブロックの暗号化／暗号化解除のための関連する暗号化モジュールと共に、ストリーミング・ドライバの異なるインスタンスを作成およびインストールする。ステップ（ｏ）で、次いでハイパーバイザは、ｉＳＣＳＩチャネルを介してＯＳサーバから暗号化済みＶＭイメージ・ブロックのストリーミングを開始し、ユーザ端末におけるＶＭ実行を可能にする。この場合もやはり、ストリーミング展開は、各ＶＭイメージにつき、ハイパーバイザによってセットアップされた関連するストリーミング・ドライバの制御下で実施され、それにより、端末４においてローカルＶＭイメージが徐々に築き上げられる。前と同様、これは、ローカルＶＭイメージが完成されて、完全にプロビジョニングされたマシンが得られるまで、継続することができる。
【００３１】
図６に、上記のプロビジョニング・プロセスを介して得られる仮想システム・アーキテクチャの簡略化された概略図を示す。この例では、ＶＭ１およびＶＭ２として符号が付けられた２つのユーザＶＭが、ハイパーバイザの制御下で実行されるようにユーザ端末にプロビジョニングされると仮定する。ハイパーバイザの機能全体は、影付きブロック３０で示される。端末ハード・ディスクは３１で表される。物理ディスク３１は、第１のパーティションがハイパーバイザに予約され第２のパーティションがユーザＶＭのセットに予約されるように、区分化される。ハイパーバイザのルート・デバイスは、そのストリーミング・ドライバである。このストリーミング・ドライバは、第１のパーティションへのアクセスを制御し、必要に応じて全てのブロックがローカルにコピーされるのを確実にする。特に、ドライバは、利用可能ならばブロックをローカルに取り出し、または、利用可能でなければブロックをサーバからストリーミングしてローカルにコピーする（ストリーミング・ドライバは、例えば上に言及したＩＰＣＣＣ文書に記載のものに基づくことができ、適切な実装形態は、本明細書における動作の記述から当業者には容易に明らかであろう）。ブロックは、３３で示されるハイパーバイザ暗号化モジュールを介して、暗号化された形で記憶され、暗号化されない形で、３２で示されるコア・ハイパーバイザ・システムに利用可能にされる。ハイパーバイザ暗号化モジュールは、図４のステップ（ｆ）で得られたハイパーバイザ・キーを使用して、ハイパーバイザ・ブロックの動的な暗号化／暗号化解除を実施する。個々のＶＭの構成は同様であり、関連するストリーミング・ドライバ・インスタンスが、バーチャル・マシンのディスクとして使用される。各ＶＭのブロックは、そのＶＭ自体のＯＳに加えて、このＯＳ上で実行されるユーザ・アプリケーションを含み、関連する暗号化モジュールによって、このＶＭに対するセッション・キーを使用して動的に暗号化／暗号化解除される。したがって、ストリーミング・プロセスは、ＶＭ内部で実行されるＯＳからはトランスペアレントであり、ストリーミングはハイパーバイザ３０中で起こる。
【００３２】
ローカルに修正されたイメージ・ブロックは、すぐに、またはいずれか好都合な後の時点で（例えばＶＭセッション中に定期的に）、ハイパーバイザによってネットワークを介してサーバ２にコピーして返すことができる。ＶＭセッションは、トラステッド・デバイス５が端末４に接続されている間だけ、開いた状態に維持される。トラステッド・デバイスが取り外された場合、ハイパーバイザは、単にセッションをフリーズさせてそれ以上の入力を遮るか、またはセッションを閉じることができる。セッションを閉じることは、書き込まれていないデータをサーバに書き戻し、全てのｉＳＣＳＩセッションを終了し、ＶＭを閉鎖し、次いでハイパーバイザを終了すること含む。ディスク上のデータは、セッション・キーを介してのみ読み取ることができ、セッション・キーは、セッションの除去に伴って失われる。したがって、ディスク上の全てのデータは、読取不可能になる。セッションはまた、マシンをオフにすることによって打ち切ることもでき、その時点でサーバは、打ち切られたセッションを、クローズドとしてマークすることになる。この場合もやはり、セッション・キーが失われたため、ディスク上のデータは決して読み取ることができない。
【００３３】
ハイパーバイザおよび必要なＶＭのローカル・イメージによってマシンが完全にプロビジョニングされたと仮定すると、このことは、後続の「オフライン」動作、すなわちサーバ２へのストリーミング接続から独立した実行のための、基礎を提供する。特に、ユーザは、展開を完了するようハイパーバイザにまず通知することによって、オフライン・モードに切り替えることができる。ハイパーバイザは、そのルート・ディスク全体を読み取って、全てのブロックがローカルに利用可能であることを確実にし、全ての開いているバーチャル・マシンに対してこれと同じ動作を実施する。展開を完了すると、ハイパーバイザはまた、安全なＴＬＳチャネルを介してサーバ２からブート・イメージをダウンロードし、これをローカル・ディスクのブート・パーティションに書き込む。このブート・イメージは周知であり、そのサイズおよびシグネチャ（ハッシュ）は、トラステッド・デバイス５上のミニブートローダに知られている。セッション・キーは、デバイス５の安全なストレージ９中で保持され、ハイパーバイザは、オフライン・インジケータ（ここでは、ローカル・ディスクの最初にある単純なフラグ）をセットすることによってパーティションをマークする。
【００３４】
続いてオフライン・モードでセッションを再アクティブ化するのを、図７の各ステップによって示す。ここで、図の左側の垂線は、ユーザ端末４のローカル・ディスクを表し、中央の垂線は、完全にプロビジョニングされたユーザ端末を表す。この図のステップ（ａ）で示すように、次のブート時、ミニブートローダは、ディスクの最初にあるオフライン・フラグをチェックし、このフラグがセットされていると識別し、したがってブロックのセット全体がローカルに利用可能であると見なす。ステップ（ｂ）で、ミニブートローダは、ブート・イメージをブート・パーティションからメモリにロードし、ステップ（ｃ）で、ローカル・イメージに対するインテグリティ・チェックを実施する。特に、ミニブートローダは、ブート・イメージの暗号ハッシュを計算し、これを既知の値と比較する。このようにしてローカル・イメージのインテグリティが確認された場合にのみ、ユーザはオフライン・モードでセッションを再開することができる。次いで、ミニブートローダによってメモリにロードされた内容から、ハイパーバイザがブートする。（オンラインの場合とは異なり、このブート・イメージは、ハイパーバイザのカーネルおよび初期ＲＡＭディスクで構成されてよく、ストリーミング・インフラストラクチャにアクセスするための修正は必要とされないことに留意されたい。マシン上の全ての内容は、それらの起源（トラステッド・インフラストラクチャから前にストリーミングされた）、またはそれらの状態（トラステッド・デバイスから入手可能な鍵で暗号化された）、またはそれらのインテグリティ（暗号化されていないデータはディスク上のブート・イメージのみであり、このブート・イメージは、説明したようにブート時に検証される）、あるいはこれらの全てのおかげで、信頼される。）したがって、ステップ（ｄ）でＲＡＭディスクが開始され、ハイパーバイザ・カーネルがユーザ端末上でブートされる。加えて、ユーザ端末４上でミニブートローダがプロキシを起動する。ステップ（ｅ）で、ミニブートローダは、プロキシを介して、トラステッド・デバイス５からハイパーバイザ・キーを取り出し、ステップ（ｆ）で、ハイパーバイザ暗号化モジュールおよびストリーミング・ドライバをインストールする。ステップ（ｇ）で、ミニブートローダは、ローカル・ファイル・システムをＲＡＭディスクからハード・ディスクに変更する。次いで、ハイパーバイザは、ステップ（ｈ）に示されるようにローカル・ディスクからアクセスされることが可能であり、ストリーミング・ドライバの制御下で実行される準備が整う。ステップ（ｉ）で、ハイパーバイザは、トラステッド・デバイス５から、保留ＶＭに対するセッション・キーを取り出す。各ユーザＶＭにつき、ステップ（ｊ）で、ハイパーバイザは、関連するストリーミング・ドライバおよび暗号化モジュールをインストールする。次いで、ＶＭは、ステップ（ｋ）で示されるようにローカル・ディスクからアクセスされることが可能であり、回復されたセッション・キーを使用してユーザ端末において実行される準備が整う。
【産業上の利用可能性】
【００３５】
以上により、非トラステッド・ユーザ端末にサーバからＯＳイメージを安全にプロビジョニングするための非常に効率的なプロセスが提供されることがわかるであろう。デバイス５はトラステッド・ソースを起源とし、安全なストレージ９の内容はユーザまたは端末マシンによって修正できないので、デバイス５は、システムの当事者にとってトラステッドにすることができる。端末マシンにプリインストールされた（損なわれている可能性のある）どんなソフトウェアも、プロビジョニング動作に必要とされない。ハイパーバイザ自体を含めた、端末マシン上で実行される全てのソフトウェアは、サーバから安全にプロビジョニングされる。したがって、プロビジョニング動作をサポートするように設計された専用クライアント・デバイスとは対照的に、ユーザ端末は、システムの当事者にとって非トラステッドな任意のいかなるコンピューティング・デバイスであってもよい。このように、ユーザは、出所、用途、場所などによって制限されることなく、操作する任意の好都合な端末を選択することができ、ユーザのＶＭを実行するのに端末のローカル・リソースを活用することができる。
【００３６】
前述の例示的な実施形態に多くの変更および修正を加えることができることは理解されるであろう。例として、図４および５で使用される種々のチャネルのうちの１つまたは複数に関連する機能を、他の実施形態で組み合わせることもできる。特に、いくつかの実施形態では、サーバへの最初の認証された接続は、ユーザ端末を介して、トラステッド・デバイスとサーバとの間で確立されてもよい。また、ローカルＯＳイメージ・ブロックは、望むなら、後続のオフライン・ブートのために端末ハード・ディスク以外のローカル・ストレージ（例えば、ＵＳＢキー、外部ＳＳＤ（ｓｏｌｉｄ−ｓｔａｔｅ  ｄｒｉｖｅ）、ＳＤ（Ｓｅｃｕｒｅ  Ｄｉｇｉｔａｌ）カードなど）に記憶されてもよい。このようなポータブル・ディスクは、望むなら、後で別の端末において使用することができる。別の例として、いくつかの実施形態では、ハイパーバイザ・キーまたはＶＭセッション・キーあるいはその両方は、ＯＳサーバによって動的に発行されるのではなく、トラステッド・デバイス５の安全なストレージに事前に記憶されていてもよい。単一のＶＭセッション・キーが、全てのユーザのＶＭに対して提供されてもよい。トラステッド・デバイス５の、他のフォームファクタ、例えばＵＳＢインタフェース以外の端末インタフェースを有するフォームファクタも、当然ながら想定することができる。いくつかの実施形態では、ユーザ認証は、トラステッド・デバイスに挿入された、ユーザを識別するスマート・カードを介して実施することができる。他の多くの変更および修正も、本発明の範囲を逸脱することなく、述べた実施形態に加えることができる。
【図１】
0005940159.tif 000002
【図２】
0005940159.tif 000003
【図３】
0005940159.tif 000004
【図４】
0005940159.tif 000005
【図５】
0005940159.tif 000006
【図６】
0005940159.tif 000007
【図７】
0005940159.tif 000008