(57)【特許請求の範囲】
【請求項１】
計算デバイスのファームウェアを安全にアップデートするためのシステムであって、
計算デバイスであって、
ファームウェア実行の最中の、アップデートした仮想読み出し専用メモリ（ＲＯＭ）モジュールの妥当性の検証に使用される解読プロセスを含むアップデート妥当性検証手続きと、
前記アップデート妥当性検証手続きへの参照、及び複数の仮想ＲＯＭモジュール各々のための参照を含むＲＯＭファームウェア・イメージであって、前記複数の仮想ＲＯＭモジュールは前記ＲＯＭファームウェア・イメージのビルドプロセス中に作成され、各参照は、関連する仮想ＲＯＭモジュール用のバージョン識別子、メッセージダイジェスト、独自の識別子、及び前記アップデート妥当性検証手続きを識別するバリデータ識別子を含み、前記アップデート妥当性検証手続きは、プリブートの最中に前記アップデートされた仮想ＲＯＭモジュールの信頼性を確認するために用いられ、前記アップデート妥当性検証手続きは、前記複数の仮想ＲＯＭモジュールの１つへの前記ＲＯＭファームウェア・イメージに含まれる参照をアップデートして、前記アップデートされた仮想ＲＯＭモジュールの妥当性検証に続いて前記アップデートされた仮想ＲＯＭモジュールのメッセージダイジェスト及びバージョン識別子を含める、ＲＯＭファームウェア・イメージと、
前記ＲＯＭファームウェア・イメージ及びアップデート妥当性検証手続きがロードされる前記計算デバイスのメモリとを含む計算デバイスと、
前記複数の仮想ＲＯＭモジュールを格納する前記ＲＯＭファームウェア・イメージの外部の少なくとも１つのストレージ場所とを含む、計算デバイスのファームウェアを安全にアップデートするためのシステム。
【請求項２】
前記アップデートした仮想ＲＯＭモジュールが拡張可能ファームウェアインターフェース（ＥＦＩ）フレームワーク・ファームウェア・ボリュームである、請求項１に記載のシステム。
【請求項３】
計算デバイスのファームウェアを安全にアップデートする方法であって、
前記計算デバイスに置かれたＲＯＭイメージの外部の少なくとも１つの場所に格納される、複数の仮想ＲＯＭモジュールを作成するためにファームウェア・イメージを分割する段階と、
ファームウェア実行の最中にアップデートした仮想ＲＯＭモジュールの妥当性を検証するためのアップデート妥当性検証手続きであって、独自の識別子によって識別されると共に解読プロセスを含むアップデート妥当性検証手続きを提供する段階と、
前記ＲＯＭイメージに置かれたファームウェアのビルド内の前記複数の仮想ＲＯＭモジュール各々のための参照を含める段階であって、各参照が、関連する仮想ＲＯＭモジュール用の、バージョン識別子、メッセージダイジェスト及び独自の識別子を備え、各参照が、関連するアップデート妥当性検証手続きを識別するバリデータ識別子を備え、ファームウェアの実行が、
バージョン識別子を含むアップデートした仮想ＲＯＭモジュールの妥当性を検証するために、参照内のバリデータ識別子により識別される前記アップデート妥当性検証手続きを使用し、
前記複数の仮想ＲＯＭモジュールの１つへの前記ＲＯＭイメージに含まれる参照をアップデートして、前記アップデートされた仮想ＲＯＭモジュールの妥当性検証に続いて前記アップデートされた仮想ＲＯＭモジュールのメッセージダイジェスト及び前記アップデートされた仮想ＲＯＭモジュールのバージョン識別子を含める、計算デバイスのファームウェアを安全にアップデートする方法。
【請求項４】
前記アップデートされた仮想ＲＯＭモジュールのベンダーが、
前記アップデートされた仮想ＲＯＭモジュール用のメッセージダイジェストを生成し、
前記アップデート妥当性検証手続きに含まれる前記解読プロセスに、暗号化されたメッセージダイジェストを解読することを命じる暗号化プロセスを用いて、前記アップデートした仮想ＲＯＭモジュールの前記メッセージダイジェストを暗号化する、請求項３に記載の方法。
【請求項５】
前記アップデート妥当性検証手続きが、
前記アップデート妥当性検証手続きに含まれる前記解読プロセスを用いて前記暗号化されたメッセージダイジェストを解読し、
前記アップデートした仮想ＲＯＭモジュールの妥当性を検証するために、前記アップデートした仮想ＲＯＭモジュールに生成された新しいメッセージダイジェストと、前記暗号化されたメッセージダイジェストの前記解読を比較する、請求項４に記載の方法。
【請求項６】
前記アップデート妥当性検証手続きが、前記アップデートした仮想ＲＯＭモジュールを新しいモジュールとして識別するために、前記アップデートした仮想ＲＯＭモジュールの前記バージョン識別子と、前記複数の仮想ＲＯＭモジュールのうちの１つの前記バージョン識別子を比較する、請求項４に記載の方法。
【請求項７】
前記アップデート妥当性検証手続きを前記ＲＯＭイメージの一部として格納する、請求項４に記載の方法。
【請求項８】
前記アップデート妥当性検証手続きを前記複数の仮想ＲＯＭモジュールのうちの１つとして格納する、請求項４に記載の方法。
【請求項９】
前記アップデートした仮想ＲＯＭモジュールが拡張可能ファームウェアインターフェース（ＥＦＩ）フレームワーク・ファームウェア・ボリュームである、請求項４に記載の方法。
【請求項１０】
ファームウェアの実行が、
前記計算デバイスと前記アップデートされた仮想ＲＯＭモジュールを保持する信頼されたサーバーとの間に安全なトンネルを生成するために、参照内の前記バリデータ識別子により識別される前記アップデート妥当性検証手続きを使用し、
前記トンネルを用いて、前記アップデートした仮想ＲＯＭモジュールを前記計算デバイスへダウンロードする、請求項４に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の例示的な実施形態は、一般的に、ＢＩＯＳファームウェアを含む、ＰＣにＰＯＳＴを実行するファームウェアに関し、より詳細には、ファームウェアの必要なメモリ容量を減らすことと、ファームウェアを安全に格納することと、安全な方法でファームウェアをアップデートすることとに関する。
関連出願
【０００２】
本発明は、２００５年２月２日付けで提出された米国特許出願第６０／６４９，４８６号である「ファームウェアの必要なメモリ容量を減らすと共に、ファームウェアに安全なアップデート及びストレージ領域を提供するシステム及び方法」という名称の米国特許暫定出願の特典及び優先権を主張する。
【背景技術】
【０００３】
近年、大量のファームウェア・コードをＰＣのプリブートに利用可能にする需要が増加している。ファームウェアは、読み出し専用メモリ（ＲＯＭ）モジュールに書き込まれたソフトウェアである。これらのモジュールは、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ及びフラッシュメモリを含むが、これらに限定されない。こうしたファームウェア需要が増加している理由の１つは、ＰＣを起動してオペレーティングシステム（ＯＳ）をロードする準備をする際に、ファームウェア（ＢＩＯＳ又はフレームワーク）（「フレームワーク」という用語は、（米国カリフォルニア州サンタクララ市の）インテル社の「Platform Innovation Framework for EFI」を指して本明細書で用いられ、以下で説明する）が実行する必要のある演算の複雑さが増していることである。需要増加の別の理由は、オペレーティングシステムがロードを完了する前にプリブート環境で実行する、付加価値のある追加特徴を作成することに、産業界が相当な関心を抱いていることである。
【０００４】
あいにくファームウェアを使用する従来方法に関連した課題はかなりある。現実には産業界にＰＣ用ハードウェアのコストを抑える強い動機があるために、ＲＯＭ部品又はフラッシュ部品に利用可能なストレージを増加することにより、大量のファームウェア・コードをプリブートに利用可能にするという増加した需要を十分に満足していない。加えて、ファームウェア・コードの増加に対する需要によって、インターネット上のサーバーを含む他のソフトウェア環境と通信するための安全な手段と、オペレーティングシステムがロードした後で実行するコードとが更に必要になる。その上、プリブート中にコンテンツの安全を確保するための既存のソリューションがあるものの、これらの既存のソリューションは、ローカルディスクドライブで利用可能になる専用パーティションに依存しているか、或いはキーを格納して隠す能力を提供する個別のセキュリティ・チップに依存している。更に、安全な方法でフラッシュ部品に格納されたファームウェアをアップデートするタスクが、かなり注目されている。フラッシュ部品に格納されたファームウェアをアップデートする現在の方法は、アップデート完了が失敗するとコンピュータが操作不可能になるので、コンピュータのその後の操作性への危険をはらんでいる。更に、こうしたアップデートを許すことで、多くの場合フラッシュ・ファームウェアがコンピュータの内部への完全なアクセスを備えてしまうというセキュリティ上の危険を少し負うことになる。
発明の概要
【０００５】
本発明の例示的な実施形態は、量を増加したファームウェアをコンピュータのプリブートに利用可能にするためのメカニズムを提供する。プリブートに利用可能なファームウェアの量を増加するために、ファームウェアのどの複数のセグメントをＲＯＭ部品に置く必要があるか、またファームウェアのどのセグメント１つを又はどの複数のセグメントを他の場所に置くことができるかに関して、ビルドプロセス中に設計決定を行う。ＲＯＭから遠隔に格納されたファームウェアのセグメントを「仮想ＲＯＭモジュール」と呼ぶ。仮想ＲＯＭモジュールの各々は、生成した独自の識別子を割り当てられ、また、ＭＤ５又はＳＨＡ−１といったアルゴリズムを用いて、各モジュール用に「メッセージダイジェスト」を構築する。メッセージダイジェストは、仮想モジュールが変わればメッセージダイジェストも変わるように、仮想モジュールを独自に表現する。ＲＯＭイメージのソフトウェア・ビルドでは、各仮想ＲＯＭモジュール用に作成された、メッセージダイジェストと独自の識別子とのペアを、仮想モジュール用の論理ポインタとして使用する。加えて、不揮発性ストレージ内のＲＯＭイメージ内に検索パス変数を置く。この検索パスは、仮想ＲＯＭモジュールを捜す１つ又は複数の場所に提供し、後でアップデートしてもよい。
【０００６】
製造工程中に、ＰＣのＲＯＭ部品又はフラッシュ部品に、（仮想モジュールを指す論理ポインタを含む）実際のＲＯＭイメージを置く。実際のＲＯＭイメージは、仮想ＲＯＭモジュールを実行しようとする際に、仮想ＲＯＭモジュールに関連した独自の識別子を検索すると共に、独自の識別子と一緒に検索パス変数を用いて、仮想ＲＯＭモジュールのコピーを見つける。それは、ネットワークからこのモジュールをダウンロードしてもよいのと同様に、ローカルディスクから、又はＣＤ−ＲＯＭから、又は他のストレージ媒体から、このモジュールをロードしてもよい。それは、一旦このモジュールをロードしたら、このモジュールに同じメッセージダイジェストアルゴリズムを実行し、このモジュールの実行前にこのモジュールが変更されていなかったことを確認する。
【０００７】
更に、本発明の例示的な実施形態は、安全な方法でファームウェアをアップデートできる。実際のＲＯＭ内で２つの追加属性を用いて、仮想ＲＯＭモジュールを参照する。これら２つの追加属性は、バージョン属性と、アップデートの妥当性を検証できる個別のモジュールへの参照とである。この個別のモジュールは、実際のＲＯＭに組み入れられてもよいし、組み入れられなくてもよく、別の仮想ＲＯＭモジュール用の独自の識別子であってもよい。このアップデートプロセスは、第１仮想ＲＯＭモジュールに関連したメッセージダイジェストと、第１仮想ＲＯＭモジュールに関連したバージョン属性とをアップデートする。更に、このアップデートプロセスは、（ローカルディスクに置かれていてもよい）対応するファイルの新しいコピーを作成する。このファイルは、ハッシュされる（この場合「ハッシュすること」は、ファイルにメッセージダイジェストアルゴリズムのうちの１つを実行することを意味する）と、上述のプロセスに対応する方法で、新しいメッセージダイジェストと「一致」するはずである。
【０００８】
アップデートモジュールのダウンロードに続いて、妥当性検証モジュールは、アップデートの実行を容認できることを確認する。ネットワークを介して移動するコンテンツの妥当性の検証は、ＳＨＡ−１アルゴリズムを用いてそのコンテンツで作ったメッセージダイジェストを暗号化し解読するための公開・非公開キーペアといった、インターネットを通じて送信されるコンテンツの妥当性を検証するための様々なよく理解されているメカニズムのうちの１つによって行われる。異なる妥当性検証方法（原語：scheme）を各々使用しているかもしれない異なるファームウェア・ベンダーによって利用可能になるファームウェアを各々参照する、複数のアップデート妥当性検証モジュールを用いてもよい。これら異なるファームウェア・ベンダーが同じファームウェア・メカニズムを使用する状況にあっても、各ベンダーは、コンテンツを署名するためのそれら自身の公開・非公開キーペアを使用してもよい。
【０００９】
更に、本発明の例示的な実施形態は、個々のコンピュータに対して安全ストレージの作成及びそれへのアクセスを提供する。ストレージが安全になるためには、プリブート中に実行しない後続のコードによって、ＲＯＭ部品又はフラッシュ部品の領域を読み出し専用或いは読み取り不可能にする必要がある。本発明は、ＲＯＭ部品又はフラッシュ部品のある領域を、読み出し専用（「書き込み不能」と呼ぶ）にすることも、読み取り不可能（「読み取り不能」と呼ぶ）にすることもできる。非公開ストレージを暗号化可能にするためには「読み取り不能」が必要になる一方、ストレージ上の改ざんを検知するためには書き込み不能が必要になる。
【００１０】
安全ストレージ領域を作成しアクセスするプロセスは、モジュールを検索するための独自の識別子を含む、実際のＲＯＭに「仮想ＲＯＭ」モジュール参照つまりポインタを格納する。更に、実際のＲＯＭは、マシン全体用の生成した独自の識別子を含んでいる。ある仮想ＲＯＭモジュールを検索する際には、そのモジュール識別子とそのマシン識別子との両方を使用する。一旦検索されたら、このモジュールの妥当性を、その仮想ＲＯＭモジュール参照に格納されたメッセージダイジェストを用いて検証する。必要ならば、この後で、実際のＲＯＭのどこか他の場所に格納された秘密キーを用いて、この仮想ＲＯＭモジュールを解読する。
【００１１】
プリブートコードによって、（本質的には安全ストレージの構成単位である）仮想ＲＯＭモジュールへのアップデートをメモリ内で行う。これらのアップデートが完了した時点で、この仮想ＲＯＭモジュールをそれが検索された場所へ書き込み直す。この書き込みは、上述のステップを逆にすることを含む。これは、必要ならば秘密キーを用いて最初にこのモジュールを暗号化し、この仮想ＲＯＭモジュール用の新しいメッセージダイジェストを生成して、モジュール識別子及びマシン識別子を用いてそのストレージ場所へ新しいモジュールを書き込み直すことによって行われる。更に、新しいメッセージダイジェスト値を反映するために、実際のＲＯＭにある仮想ＲＯＭモジュール参照をアップデートしなければならない。続いて、実際のＲＯＭにある仮想ＲＯＭモジュール参照と、ＰＣ用に使うマシン識別子とは、書き込み不能である。加えて、このストレージが暗号化されており、秘密キーが用いられている場合には、この秘密キーを含んだ実際のＲＯＭの領域は、読み取り不能になる。
【００１２】
本発明の１つの様態では、電子デバイスに格納されたファームウェアの必要なメモリ容量を減らす方法は、複数の仮想ＲＯＭモジュールを作成するためにファームウェア・イメージを分割するステップを含む。この電子デバイスに置かれたＲＯＭイメージの外部の少なくとも１つの場所に、これら複数の仮想ＲＯＭモジュールを格納する。この方法は、このＲＯＭイメージに置かれたファームウェアのビルド内のこれら複数の仮想ＲＯＭモジュールの各々のための参照を更に含む。各参照は、関連する仮想ＲＯＭモジュール用の、メッセージダイジェストと独自の識別子とを備える。更に、この方法は、これら複数の仮想ＲＯＭモジュールのうちの選択された１つを、この複数の仮想ＲＯＭモジュールのうちの選択された１つに関連した参照の中の独自の識別子を用いて、プリブートの最中に検索する。この方法は、この複数の仮想ＲＯＭモジュールのうちの選択された１つを、この複数の仮想ＲＯＭモジュールのうちの選択された１つに関連した参照の中のメッセージダイジェストを用いて、プリブートの最中に更に確認する。
【００１３】
本発明の別の様態では、電子デバイスに格納されたファームウェアの必要なメモリ容量を減らすためのシステムは、ビルドプロセス中に作成された複数の仮想ファームウェア・イメージ・モジュールを含んでいる。この電子デバイスに置かれたファームウェアＲＯＭイメージの外部の少なくとも１つの場所に、これら複数の仮想ＲＯＭモジュールを格納する。このシステムは、更にファームウェアＲＯＭイメージを含んでいる。このファームウェアＲＯＭイメージは、これら複数の仮想ＲＯＭモジュールの各々のための参照を含み、各参照は、関連する仮想ＲＯＭモジュール用の、メッセージダイジェストと独自の識別子とを含む。この独自の識別子を用いて、プリブートの最中にこの参照したイメージ・モジュールを検索し、また、このメッセージダイジェストを用いて、この検索されたイメージ・モジュールを実行する前にこのイメージ・モジュールの信頼性を確認する。
【００１４】
本発明の１つの様態では、電子デバイスに格納されたファームウェアの必要なメモリ容量を減らす方法は、この電子デバイスに置かれたＲＯＭイメージの外部の１つの場所に格納された、１つの仮想ＲＯＭモジュールを作成するためにファームウェア・イメージを分割するステップを含む。この方法は、このＲＯＭイメージに置かれたファームウェアのビルド内のこの仮想ＲＯＭモジュール用の参照を更に含む。この参照は、この仮想ＲＯＭモジュール用の、メッセージダイジェストと独自の識別子とを備える。加えて、この方法は、この仮想ＲＯＭモジュールを、この仮想ＲＯＭモジュールに関連した参照の中の独自の識別子を用いて、プリブートの最中に検索する。この仮想ＲＯＭモジュールの信頼性を、この仮想ＲＯＭモジュールに関連した参照の中のメッセージダイジェストを用いて、プリブートの最中に確認する。
【図面の簡単な説明】
【００１５】
本発明は、添付した特許請求の範囲における詳細な事項と共に指摘される。添付した図面に関連した以下の説明を参照することによって、本発明のさらなる利点と同様に上述した本発明の利点も一層よく理解されるはずである。
【図１】ＶＲＯＭモジュールと、生成されたメッセージダイジェスト及びＧＵＩＤとの対応を示す。
【図２】実際のＲＯＭイメージのビルドにおけるＶＲＯＭ論理ポインタの使用を示す。
【図３】ＲＯＭ部品に実際のＲＯＭイメージを格納し、ディスク或いはインターネットに仮想ＲＯＭモジュールを格納してもよい、分配プロセスの図を示す。
【図４】ビルドプロセスのフローチャートである。
【図５】仮想ＲＯＭ「ポインタ」を用いて、実際のＲＯＭ部品に存在しない仮想ＲＯＭモジュールを検索する、検索プロセスの図を示す。
【図６】検索プロセスのフローチャートである。
【図７】ビルドプロセス中に各ＶＲＯＭモジュール用に生成される追加情報と、バージョン番号と、アップデート・バリデータへの参照とを示す。
【図８】ＲＯＭイメージに格納された、アップデート・バリデータ及び「変更した」ＶＲＯＭポインタを示す。
【図９】アップデート・バリデータ用の公開・非公開キーの生成を示す。
【図１０】公開・非公開キーペアの非公開部分を用いて、モジュールアップデートに関係する「キー」の生成のフローチャートを示す。
【図１１】アップデートしたＶＲＯＭモジュールの検索及び妥当性検証を示す。
【図１２】キーの妥当性を検証するためのフローチャートへの参照を含む、アップデートの検索のフローチャートを示す。
【図１３】キーの妥当性検証のフローチャートを示す。
【図１４】ファームウェア用の安全ストレージ領域を作成するために使用したコンポーネントの分類を示す。
【図１５】「安全ストレージ領域」の暗号化及び第２ストレージ場所（この場合、ディスクドライブ）への保存を示す。
【図１６】安全ストレージの第１及びその後の書き込みのフローチャートを示す。
【図１７】安全ストレージの第１及びその後の読み出しのフローチャートを示す。
【発明を実施するための最良の形態】
【００１６】
本発明の例示的な実施形態は、コンピュータのプリブートに利用可能なファームウェアの量を増加させると共に、ファームウェアに安全なアップデート・メカニズムを提供し、安全ストレージ領域を作成してアクセスするための手段を提供する。明瞭に説明するために、以下で本発明の各局面について別々に順番に説明する。本明細書に記載したような本発明の例示的な実施形態は、インテルのPlatform Innovation Framework for EFI（「フレームワーク」）にあるドキュメント化されたＡＰＩに対する幾つかの参照を作る。非フレームワーク・ソリューションに基づいた実施形態への解釈は、当業者に明白になるはずである。更に、この説明はＰＣに焦点を当てているが、不揮発性メモリ部品に格納された予めプログラムされているファームウェア・イメージを含む、他の非ＰＣの計算デバイスも、本発明の範囲内であると考えられる。
【００１７】
本発明について詳細に説明する前に、本発明で利用されるＢＩＯＳ及びフレームワークのコンポーネントについて説明することは役に立つであろう。インテルのPlatform Innovation Framework for EFI（「フレームワーク」）は、ＢＩＯＳの機能性及び能力の完全な再インプリメンテーションである。ＢＩＯＳは、インテルＸ８６コンピュータで１６ビットのリアルモードで通常動作するが、フレームワークは、３２ビット或いは６４ビットのメモリ・モードで実行できて、特定のプラットフォーム・アーキテクチャーに制限されない。更に、ＢＩＯＳは、アセンブリコードで通常ほぼ完全に記述されているが、フレームワークは、Ｃプログラミング言語でほぼ完全に記述されている。
【００１８】
フレームワークは、ＥＦＩ（「拡張可能なファームウェアのインターフェース」）のインプリメンテーションを提供する。このＥＦＩは、オペレーティングシステムをロードし実行するソフトウェアからシステムの電源を入れるファームウェアの詳細及びインプリメンテーションを完全に抽象化するインターフェース仕様である。フレームワークのようにＥＦＩのインプリメンテーションをゼロから作成できるだけでなく、既存のＢＩＯＳからも作成できるように、完全に「不透明な」インターフェースとしてＥＦＩを定義した。この文脈での「不透明な」とは、インターフェースの発信側又はクライアントが、基礎インプリメンテーションの内部を見ることができないことを意味する。発信側は、インターフェース自体を通じてのみアクセスできる。
【００１９】
ＥＦＩは、互いと対話する際にプリブート・コンポーネントを使用し、且つフレームワークによっても使用され、且つ本発明の種々の実施形態に関連する、標準セットのメカニズムを導入する。コンポーネント間の対話を各々不透明なＣ言語ＡＰＩである「プロトコル」として定義する。プロトコルは、メモリに別々にロードでき実行できる個々のコンポーネントである「ドライバ」によってインプリメントされる。各プロトコルは、Ｃ言語ソースコード「名」と、実行時に他のプロトコルからそれを識別するために用いる、（「ＧＵＩＤ」即ち「世界中で独自の識別子」としてインプリメントされる）それ自身の独自の識別子とを備える。ドライバは、メモリにロードされると、サポートするプロトコルのセットについてＥＦＩ環境に知らせる。このＥＦＩ環境は、インメモリデータベースにおいてこれらのプロトコルを追跡すると共に、他のプリブートコードにこれらのプロトコルを検索及びアクセスさせることによって、特定のドライバ内のプロトコルの基礎インプリメンテーションに関する知識なしで、これらのプロトコルを「エクスポート」したドライバ内のコードを見つけて実行する。
【００２０】
コンポーネント間のこの不透明形式の対話は、ＣＯＭ又はＣＯＲＢＡに精通している人々によく知られているはずである。特に、独自の識別子（ＧＵＩＤ）は、コンポーネントへのインターフェースを「見つける」ためにＣＯＭでも用いられる。ＣＯＭ及びＣＯＲＢＡのように、ＥＦＩは「拡張可能」となるように設計されている。新しいプロトコルを定義してもよいし、既存のプロトコルの新しいインプリメンテーションを作成してもよい。何れの場合も、これらの拡張は、一定の方法で基礎環境に適合する。
【００２１】
ドライバの概念は、統合した方法で多くの様々なタイプのハードウェアをソフトウェアによってサポートする必要のある今日のオペレーティングシステムに精通している人々によく知られている。これらのオペレーティングシステム・ドライバ環境では、様々なクラスのハードウェアデバイス用に共通のＡＰＩを定義する。同じＡＰＩをインプリメントする様々なドライバに、ハードウェアの変化を扱う責任があるものの、これらの共通ＡＰＩは、基礎ハードウェアの相違の詳細を隠す。
【００２２】
ＥＦＩによって定義されるプリブート・コンポーネント間の対話のための標準セットのメカニズムに加えて、本発明の例示的な実施形態は、フレームワーク内でのみ定義した幾つかの拡張を利用する。フレームワークは、まさにＲＯＭ部品内のストレージ用に特に定義したフラットファイルシステムである「ファームウェア・ボリューム」の概念を導入する。このファームウェア・ボリュームは、このファイルシステムを備えた対話用プロトコルのセットを定義する。フレームワークでは、ＲＯＭイメージに格納された全てのファイルをファームウェア・ボリュームに格納する。従って、フレームワークのためのビルド・プロシージャ中に、ファームウェア・ボリュームは生成される。
【００２３】
フレームワーク・ファームウェア・ボリューム仕様に定義された拡張プロトコルのうちの１つは、「ＧＵＩＤされたセクション抽出プロトコル」である。このプロトコルは、ベンダーがファームウェア・ボリュームを、完全に不透明な表現の新しく定義された「セクション」（これらセクションはファイルの一部である）を含めて拡張できるような方法で定義される。この拡張を生じさせるためには、ファームウェア・ボリューム内のファイル用のセクション・ヘッダーにＧＵＩＤを含める。このＧＵＩＤは、「ＧＵＩＤされたセクション抽出プロトコル」をインプリメントするドライバを見つけるために、ファームウェア・ボリューム・コードによって用いられる。ファームウェア・ボリュームからファイルを抽出してメモリに置く時に、このドライバは、プロトコルを通じて呼び出して、不透明な表現を変換する。可能な変換例には、不透明な表現の解読、或いは不透明な表現中のデジタル署名のチェックが含まれる。
【００２４】
本明細書に含まれる例の多くはフレームワーク環境に言及しているが、フレームワーク記述に対して当業者に明白な調節を行うことによって、より従来的なＢＩＯＳコンポーネントを用いて本発明を実施してもよいと理解されるはずである。
【００２５】
本発明の例示的な実施形態は、ＲＯＭに格納されないファームウェア・モジュールを安全に識別するために、ビルドプロセス中に、ＲＯＭイメージに埋め込まれていた、独自の識別子とメッセージダイジェストとの組み合わせを使用する。他の従来のソリューションは、隠された或いは安全であるディスク・パーティションに主として、プリブート中にアクセス可能なファームウェアを追加する安全な方法を提供する。しかし、これらの他のソリューションでは、ＲＯＭイメージのためのビルドの時にファームウェアが存在する必要はない。ＳＨＡ−１或いは他の相当するメッセージダイジェストアルゴリズムを使用することによって、同じメッセージダイジェストを生成する異なったモジュールを作成することが非常に困難になる。メッセージダイジェストがＲＯＭイメージに埋め込まれているので、メッセージダイジェスト自体を変更すると、ＲＯＭ部品をアップデートする必要が生じる。一旦メッセージダイジェストをＲＯＭイメージに埋め込んでおけば、当業者に知られており本発明の範囲外である、フラッシュ部品の領域を読み出し専用にするＴＰＭハードウェア及びフラグといったＲＯＭイメージの改ざんを検知又は防止する様々な既存の方法がある。メッセージダイジェストがＲＯＭイメージに埋め込まれているので、このＲＯＭイメージが安全であって改ざん不可能な場合には、仮想ＲＯＭモジュールは全て、実際に安全であって内密に変更することができない。再帰的なソリューションも可能であり、仮想ＲＯＭモジュール自体が、他の場所に格納した更に他の仮想ＲＯＭモジュールを指す「仮想ＲＯＭポインタ」を含むことができる。本発明のセキュリティが、仮想ＲＯＭモジュール全てに対して遷移的（原語：transitive）であるので、その結果、全てのファームウェアがビルドプロセスの時に利用可能である限り、安全にプリブート環境に利用可能にすることができるファームウェアの量に殆ど制限がない。
【００２６】
各仮想ＲＯＭモジュール用の独自の識別子を用いて、更にこれら仮想ＲＯＭモジュールに場所の独立性を与える。各仮想ＲＯＭモジュールを複数の場所に、例えば、ディスクに、ＣＤ−ＲＯＭに、ローカル・エリア・ネットワークに、或いはインターネットに、格納してもよい。メッセージダイジェストアルゴリズムが、このモジュールを確認する安全な方法を提供するので、これら場所自体も、ストレージ場所のうちの１つからＰＣのメモリにこのモジュールを伝送するためのメカニズムも、安全でなくてよい。
【００２７】
コンピュータのプリブートに追加ファームウェアを提供する第１ステップは、実際のＲＯＭイメージに何を含めるべきか、また実際のＲＯＭイメージに何を含めるべきでないかについての設計決定である。実際のＲＯＭイメージに含まれない情報は、別々にアクセス可能な１つ又は複数の仮想ＲＯＭモジュール内にパッケージされる。性能上の理由で、その最も一般的なパスに沿ってＰＣをブートするために必要なソフトウェアは、実際のＲＯＭ内に頻繁に残される。しかしながら、例えば、多数の可能なプリブート・アプリケーション及びユーティリィティと同様に、セットアップ・ユーザーインターフェイス、代替言語のサポート、まれなブートオプション、回復即ちリフラッシュ（原語：re-flashing）ファームウェアといった、通常用いられない他のソフトウェアを実際のＲＯＭの外部の仮想ＲＯＭモジュール内に置いてもよい。
【００２８】
仮想ＲＯＭモジュールは、ファイルの可変数を含むフラットファイルシステムを構成する単一のパッケージであるフレームワーク「ファームウェア・ボリューム」であってもよい。これらの含まれたファイルの各々は、フレームワーク内でサポートされるいかなるファイルでもありえる。フレームワーク・ファームウェア・ボリュームの利点は、埋め込まれたファイルへのアクセスをサポートするフレームワーク・ファームウェア（ドライバ）が存在することである。しかしながら、仮想ＲＯＭモジュールは、実行コードと同様にデータも含む、他の種類のファイルであってもよい。上述のように、設計決定によって、仮想ＲＯＭモジュールのための複数レベルの入れ子にすることをもたらしてもよい。言い換えれば、幾つかの仮想ＲＯＭモジュールは、他の仮想ＲＯＭモジュールを指す仮想ＲＯＭポインタを含んでもよい。
【００２９】
こうした仮想ＲＯＭモジュール各々に対して、ＳＨＡ−１メッセージダイジェストと１２８ビットのＧＵＩＤ（世界中で独自の識別子）とを含む仮想ＲＯＭポインタを生成する。多くの有名なアルゴリズムのうちの何れかを用いて、メッセージダイジェストとＧＵＩＤとを生成してもよい。生成されたＧＵＩＤは、フレームワーク内で広く用いられるが、コンピュータ界のどこか他の場所にも用いられる。ＧＵＩＤ及びＳＨＡ−１メッセージダイジェストは、複製（原語：replicable）される可能性が非常に低い値を生成する。図１は、ＶＲＯＭモジュールと、生成されたメッセージダイジェスト及びＧＵＩＤとの対応を示す。第１ＶＲＯＭモジュール２に対しては、ＧＵＩＤ４とメッセージダイジェスト６とを含む第１ＶＲＯＭ論理ポインタ２０が、この第１ＶＲＯＭモジュールにそれぞれ関連し基づいて生成される。第２ＶＲＯＭモジュール１２に対しては、ＧＵＩＤ１４とメッセージダイジェスト１６とを含む別の独自のＶＲＯＭ論理ポインタ２２が生成される。
【００３０】
仮想ＲＯＭモジュール用のＧＵＩＤ及びメッセージダイジェストの生成に続いて、実際のＲＯＭイメージを標準のＲＯＭコード及び仮想ＲＯＭポインタからビルドする。図２にビルドプロセスを示す。第１ＶＲＯＭモジュール２を指す第１ＶＲＯＭ論理ポインタ２０は、第１ＶＲＯＭモジュールに関連した、生成されたＧＵＩＤ４及びメッセージダイジェスト６を含む。第２ＶＲＯＭモジュール１２を指す第２ＶＲＯＭ論理ポインタ２２は、第２ＶＲＯＭモジュールに関連した、生成されたＧＵＩＤ１４及びメッセージダイジェスト１６を含む。標準ＲＯＭコード２４と共に、第１ＶＲＯＭ論理ポインタ２０と第２ＶＲＯＭ論理ポインタ２２とを用いて、ＲＯＭイメージ３０をビルドする。このＲＯＭイメージ３０に加えられた他のＲＯＭコード２４は、直接アクセス可能な実際のＲＯＭ部品に置くことに最適であると設計者が考えるＲＯＭコードである。
【００３１】
このＲＯＭイメージ３０に仮想ＲＯＭポインタ２０及び２２を格納し且つ検索する詳細は、特定の実施形態に依存する。フレームワークに基づいた一実施形態では、（ＲＯＭイメージにある）別のファームウェア・ボリュームが、様々なタイプの「ファイル」を含む。これらのファイルの各々を複数のセクションで構築し、各セクションは、１つのファイルの、ある特定の属性を参照する。ＧＵＩＤがファームウェア・ボリューム内のこうしたファイル各々を独自に識別するので、このＧＵＩＤは、仮想ＲＯＭモジュールを検索するために用いられるものと同じ識別子でありえて、また、仮想ＲＯＭモジュールは、フレームワーク・ボリュームの意味において、「ファイル」になる。「ＧＵＩＤされたセクション抽出プロトコル」を用いて、別のこうしたセクションをインプリメントしてもよい。このセクションは、コンテンツ（ファイル用の識別子として既に含まれているＧＵＩＤ）を確認するためのＳＨＡ−１メッセージダイジェストと同様に、抽出を実行する必要があるドライバを識別するためのＧＵＩＤも含む。更に、仮にＧＵＩＤとＳＨＡ−１メッセージダイジェストとの両方を表現する場合、フレームワークの内部で、且つ既存のＢＩＯＳの一部として、他の表現を構築してもよい。
【００３２】
図３は、どのように実際のＲＯＭイメージをＲＯＭ内に置くかを示すと共に、どのように仮想ＲＯＭモジュールを他の場所に分配するかを示す。第１ＶＲＯＭポインタ２０と、第２ＶＲＯＭポインタ２２と、他のＲＯＭコード２４とを含むＲＯＭイメージ３０を、フラッシュメモリといったＲＯＭ部品４０内に置く。第１ＶＲＯＭポインタで参照される実際の第１ＶＲＯＭモジュール２は、ＲＯＭ部品４０と同じ電子デバイスのハードドライブ４２に置いてもよい。第２ＶＲＯＭポインタで参照される第２ＶＲＯＭモジュール１２は、インターネット４４或いは他のタイプのネットワーク経由でアクセス可能な任意の場所４６に格納してもよい。当業者は、ＶＲＯＭモジュールのストレージ場所へのその他の分配が本発明の範囲内で可能なことを認識するはずである。分配イベントが全て同時に起こる必要はないことに注目するべきである。実際のＲＯＭイメージがＰＣを立ち上げるのに必要である一方、仮想ＲＯＭモジュールは、他の時点で他の方法に利用可能にするのみでもよい。更に、仮想ＲＯＭモジュールにつき分配メカニズムが１つしか存在してはならないという要求はない。こうした仮想ＲＯＭモジュール各々を種々様々な方法で分配してもよい。
【００３３】
分配メカニズムの一例は、コンピュータのハードドライブをアップグレードすることに適しているかもしれない。あるハードドライブから別のハードドライブにドライブコンテンツをコピーするためのファームウェアは、先ずファームウェアのビルドプロセス中に利用可能になる。しかしながら、それは実際のＲＯＭの一部になってはいないが、それを指す仮想ＲＯＭポインタを実際のＲＯＭイメージに格納する。数年後に行うかもしれないディスク・アップグレード時において、対応する仮想ＲＯＭモジュールは、アップグレードを実行するために使用しなければならないＣＤ−ＲＯＭで利用可能になる。ファイルがビルドプロセスに以前から「含まれている」ので、これらファイルを信用してこのＣＤ−ＲＯＭから実行できる。代わりに、ハードドライブをコピーするソフトウェアをインターネットからダウンロードしてもよいし、また、同じ方法で確認してもよい。別の分配メカニズムは、ＰＣ用のディスク・イメージをビルドするプロセス中で適切であるかもしれない。このディスク・イメージは、仮想ＲＯＭモジュールをコピー可能な、安全でないディスク・パーティションを含んでもよい。
【００３４】
図４は、ＲＯＭイメージのビルドプロセス中に仮想ＲＯＭモジュールを利用するための本発明の例示的な実施形態におけるステップのシーケンスのフローチャートである。ビルドプロセス５０は、仮想ＲＯＭモジュールがあるか否かに関する決定から開始する（ステップ５１）。仮想ＲＯＭモジュールがある場合、ＧＵＩＤを生成してその仮想ＲＯＭモジュールに割り当てる（ステップ５２）。その後、ＳＨＡ−１メッセージダイジェストといったメッセージダイジェストをこの仮想ＲＯＭモジュール用に生成する（ステップ５４）。それから、ＧＵＩＤとメッセージダイジェストとのペアから仮想ＲＯＭ論理ポインタを構築する（ステップ５６）。仮想ＲＯＭモジュールがもうこれ以上ないという決定に到達する（ステップ５１）まで、このプロセスを繰り返す。その後、仮想ＲＯＭ論理ポインタと標準ＲＯＭコードとを含むＲＯＭイメージを組み立てて（ステップ５８）、ビルドプロセスを終了する（ステップ６０）。
【００３５】
一旦仮想ＲＯＭモジュールを分配したら、ＲＯＭ部品４０が置かれているＰＣ又は他の電子デバイスのメモリ内でこれら仮想ＲＯＭモジュールを検索してもよい。図５は、検索プロセスの図を示す。ＰＣメモリ７０にＲＯＭイメージ３０をロードする。ＲＯＭイメージ３０内のＶＲＯＭ論理ポインタ２０及び２２は、ハードドライブ４２とストレージ場所４６とに格納された、第１及び第２ＶＲＯＭモジュール２及び１２の存在と識別情報とを示す。その後、以下で説明するように、第１及び第２ＶＲＯＭモジュール２及び１２を検索し、メモリ７０にロードする。特定のＶＲＯＭモジュールを検索する様々な理由があるかもしれない。これら理由には、特定の仮想ＲＯＭモジュールをロードする必要性に気づいているファームウェアの他の部分の実行が含まれるか、或いは、実際のＲＯＭにはない実行ファームウェア用にプロンプトするあるインターフェースとのユーザーの対話が含まれる。
【００３６】
ファームウェア・ボリュームのセクションとして仮想ＲＯＭポインタを格納する、フレームワークベースの実施形態では、このセクションによって参照された「ファイル」を「メモリへロードする」決定として、ＶＲＯＭモジュールを検索する決定をインプリメントする。この実施形態では、上述した「ＧＵＩＤされたセクション抽出プロトコル」をサポートするフレームワーク・ドライバが、図６のフローチャートにおいて以下に説明する方法をインプリメントする。この説明では、仮想ＲＯＭモジュールの検索を試みるファームウェアを「検索ドライバ」と呼ぶが、非フレームワークの実施形態においてはファームウェアをドライバとしてインプリメントされないかもしれないと理解するべきである。
【００３７】
この検索ドライバは、ドライバ用の「見るべき場所」のための検索パスについて記述する、不揮発性ストレージに格納された変数にアクセスする。メモリ内で見つけ、ロードし、実行するための参照された実行可能プログラム（原語：referred-to executable）の手段を提供するオペレーティングシステムにおいて検索パスを使用する。こうした検索をサポートできる様々なインプリメンテーション・メカニズムがあるが、本発明によるこの検索パスの使用は類似している。フレームワークの実施形態では、いつでもユーザー又は他のソフトウェアによってアップデートされる可能性のあるＥＦＩ  ＮＶＲＡＭ変数としてＲＯＭ部品に変数を格納する。
【００３８】
検索ドライバは、順に検索パス要素を通って繰り返す。この検索パスは、仮想ＲＯＭモジュールを探索する「好適な順序」を表現する。この検索パス内のこうした要素各々に関して、ドライバは、その要素を用いて仮想ＲＯＭモジュールの検索を試みる。各要素を「ＵＲＩテンプレート」としてエンコードしてもよい。そこでは、ブラウザ及びインターネットにおいて一般に使用されている、普遍資源識別子（原語：Universal Resource Identifier）（或いは普遍資源ロケーター（原語：Universal Resource Locator））は、対応するファイルの場所を不完全に指定する。この不完全な指定は、単に仮想ＲＯＭモジュールに関係するＧＵＩＤが入る変数であってもよい。一旦入ったら、こうした「完全な」ＵＲＩは、ローカルディスク・パーティションのディレクトリ内のファイルを参照してもよく、このファイルをハイパーテキスト伝送プロトコル（ＨＴＴＰ）又は他の有名なプロトコルを用いてインターネット上で検索できる。更に、フレームワークでは、ＵＲＩ（「ｆｉｌｅ：」、「ｈｔｔｐ：」、「ｆｔｐ：」などを識別する部分）の各「方法（原語：scheme）」の検索メカニズム自体を、特定のプロトコルを理解する種々のフレームワーク・ドライバに渡してもよい。
【００３９】
任意の特定の要素を用いて検索を試みても、対応する仮想ＲＯＭモジュールが見つからないかもしれず、その場合には、検索パス内の次の要素を検索することを試みる。この検索の試みが成功する場合、その仮想ＲＯＭモジュールをメモリにロードする。この時点では、ビルドプロセス中に用いられたものと同じメッセージダイジェストアルゴリズムを実行することによって、仮想ＲＯＭモジュール用のメッセージダイジェストを確認する。仮想ＲＯＭモジュール用のメッセージダイジェストに一致がある場合は、この仮想ＲＯＭモジュールは使用可能である。しかしながら、メッセージダイジェストに一致がない場合は、検索パス内の次の要素に対して検索を進める。
【００４０】
メッセージダイジェストの確認に続いて、実際のＲＯＭに「より接近して」仮想ＲＯＭモジュールを格納してもよいか否かに関して決定してもよい。「より接近している」とは、仮想ＲＯＭモジュールをキャッシュに入れるためにわきに置かれたローカルディスクドライブ上の標準化された場所であるとして定義してもよい。こうした場所が、存在し、且つ、仮想ＲＯＭモジュールがちょうど検索された場所よりも早く検索パス内で指定される場合には、仮想ＲＯＭモジュールをアクセス前にメモリからこの場所に書き込むことができる。
【００４１】
図６は、仮想ＲＯＭモジュールを検索するための本発明の例示的な実施形態におけるステップのシーケンスのフローチャートである。検索プロセス８０は、検索パスに更に要素があるか否かに関する決定から開始する（ステップ８１）。検索パスに追加の要素がある場合（ステップ８１）、検索パスから次の場所を選択する（ステップ８２）。その後、仮想ＲＯＭモジュール用のＧＵＩＤを用いて、仮想ＲＯＭモジュールのメモリへの検索を試みる（ステップ８４）。検索が成功した場合、仮想ＲＯＭモジュール用にＳＨＡ−１メッセージダイジェストを生成して（ステップ８６）、格納された仮想ＲＯＭモジュールと比較する（ステップ８８）。これらメッセージダイジェストが一致する場合（ステップ８９）、（上述したように）「より接近して」この仮想ＲＯＭモジュールをキャッシュに入れることができるか否かに関して決定する（ステップ９１）。この仮想ＲＯＭモジュールをより接近してキャッシュに入れることができる場合（ステップ９１）、検索パス内でより接近してそれをキャッシュに入れる（ステップ９２）。その後、この仮想ＲＯＭモジュールをアクセス可能なメモリにロードして（ステップ９４）、検索プロセスを終了する（ステップ９６）。
【００４２】
更に、本発明の例示的な実施形態を用いて、ファームウェアにアップデートを安全に行うためのメカニズムを提供してもよい。バージョン番号と、アップデート妥当性検証手続きのための独自の識別子という、２つの新しい属性の生成を含めるために、独自の識別子及びメッセージダイジェストを生成する上述のステップを変更する。例えば、フレームワークの実施形態では、フレームワーク・ボリューム「ファイル」は、オプションとなる与えられたテキスト文字列と、バージョン番号、即ち単調に（原語：monotonically）増加する数値とを備える、セクションを含んでもよい。更に、フレームワーク「ＧＵＩＤされたセクション抽出プロトコル」は、セクション抽出をサポートするドライバのインスタンスを参照するＧＵＩＤを含む。言い換えれば、仮想ＲＯＭモジュールのコンテンツのダウンロード及び確認にも責任のある、個別のドライバを使用してもよい。このドライバは、入れ子になったセットのドライバを起動してもよい。
【００４３】
図７は、各仮想ＲＯＭモジュール用にパッケージする必要のある追加属性を示す。ＶＲＯＭモジュールを用いて、ＶＲＯＭポインタ１１０を生成する。このＶＲＯＭポインタ１１０は、ＧＵＩＤ１１２及びＳＨＡ−１メッセージダイジェスト１１４を含む。加えて、このＶＲＯＭポインタ１１０は、バージョン番号１１６と、独自にアップデート妥当性検証手続きを識別するアップデート・バリデータ識別子１１８とを更に含む。図８は、どのように実際のＲＯＭイメージ１４０内に、実際のＲＯＭの他の部分１３０と同様に、「アップデート・バリデータ」コード１２０と共に、モジュール用の対応する仮想ＲＯＭポインタ１１０もパッケージするかを示す。「アップデート・バリデータ」モジュール１２０を実際のＲＯＭ１４０に格納する必要がなく、このモジュールを追加の仮想ＲＯＭモジュールとして格納してもよいことに注目するべきである。更に、ＧＵＩＤされたセクション抽出プロトコル・ドライバの変形として、フレームワーク内でアッデート妥当性検証コードをインプリメントしてもよい（しかしながら、少なくとも１セットのＧＵＩＤされたセクション抽出プロトコル・ドライバをフレームワーク・インプリメンテーションにおいて実際のＲＯＭに格納しなければならない）。
【００４４】
一実施形態では、ＰＧＰのようなソルーションを用いて妥当性を検証する。（ＰＧＰ即ち「プリティ・グッド・プライバシー」は、最先端技術に熟知している人々に有名な、電子メールメッセージにデジタルで署名且つ／或いは暗号化するための１セットのアルゴリズムである）。図９でこのプロセスを示す。ファームウェアのビルドの時に、特定の「アップデート・バリデータ」モジュールに対して、キー生成プロセス１５０は、公開・非公開デジタルキーペアを生成する。このためのアルゴリズムは、ＲＳＡといった任意の標準非対称キーアルゴリズムであってもよい。キーの公開部分１５２をアップデート・バリデータモジュール１６０に格納して、非公開キー１５４をファームウェア・ベンダー自身の個別の場所１７０に格納する。アップデート妥当性検証用の追加した代替セキュリティ・メカニズムについて以下で説明する。
【００４５】
図１０のフローチャートは、１つ又は複数の仮想ＲＯＭモジュールに対するアップデートを生成する際の非公開キーの使用を示す。本発明の例示的な実施形態を含むアップデートを生成するために、アップデートの準備ができた時に２００、ベンダーは、その非公開キーを用いてアップデート「モジュールキー」を生成する。ベンダー・コードは、新しいモジュール（この新しいモジュールはバージョン番号を含んでもよい）上でＳＨＡ−１といったアルゴリズムを実行し（ステップ２０２）、その後、公開・非公開キーの非公開部分を用いて、生じたメッセージダイジェストを暗号化する（ステップ２０４）。成功すると、非公開キーによって署名された、暗号化されたアップデート・モジュールキーが生成される２０６。当業者は、代替インプリメンテーションにおいて同様の暗号化メカニズムを用いてもよいことが分かるはずである。
【００４６】
一旦アップデートを生成したら、それを検索して、その妥当性を検証し、その後、仮想ＲＯＭモジュールに「パッチを当て」てもよい。検索ステップでは、バージョン・チェックが必要となる。特定の仮想ＲＯＭモジュールの前バージョンを既にダウンロードして、「ローカルキャッシュ」において利用可能になっていてもよい。多くの有名なメカニズムのうちの１つを用いて、より新しいバージョンをいつ、どのようにチェックするべきかを決定する。このメカニズムをアップデート・バリデータのインプリメンテーションに残しておく。例えば、アップデート・バリデータは、周期的により新しいバージョンのチェックを実行してもよい。代わりに、特定の場所をアップデート用に「保留」してもよく、それを常にチェックする。これらのアップデートをオペレーティングシステムが実行するコードによって提供してもよい。より新しいバージョンが存在しない場合には、図６で上述したプロセスが行われる。新バージョンを検知した場合には、アップデートをチェックするためのメカニズムに関係なく、その妥当性を検証しなればならない。この妥当性検証プロセスは、元のＶＲＯＭモジュール用の上述した妥当性検証プロセスとは根本的に異なる。なぜならば、アップデートした仮想ＲＯＭモジュールが、仮想ＲＯＭの最初のビルドの時点で利用「不」可能だったからである。
【００４７】
本発明の１つのインプリメンテーションでは、図１１及び１２に示すように、アップデートに関係する「モジュールキー」の妥当性が検証される。アップデート・バリデータに格納された公開・非公開キーの公開部分を用いて、「モジュールキー」を解読する。その後、このモジュール自身をハッシュし、同等性に関してこれら２つの結果を比較する。
【００４８】
図１１は、このステップの１つの可能なインプリメンテーションの概観を提供する。このステップでは、ＰＣメモリ２００にロードしたＲＯＭイメージ２１０内の仮想ＲＯＭポインタ２２０が、アップデートした仮想ＲＯＭモジュール２５０を論理的に指し示す。このアップデートしたＶＲＯＭモジュール２５０をインターネット２５５経由でアクセス可能なベンダー場所２６０に格納してもよい。このアップデートしたＶＲＯＭモジュール２６０は、ＰＣメモリ２００へダウンロードされ、アップデート・バリデータ２３０によって公開キー２３５を用いてその妥当性が検証されて、その後、ローカルハードドライブ２７０に格納される。上述のように、仮想ＲＯＭポインタのこの「パッチ当て」には、このプロセス中に仮想ＲＯＭポインタ自体をアップデート可能なことが必要である。更に、セキュリティ上の理由で、このアップデートプロセスには、処理中の後ほどでの認可されていない者による仮想ＲＯＭポインタのアップデートを不可能にすることが必要である。その上、上述のように、元の仮想ＲＯＭビルド・プロシージャが安全であり、且つ、後になって認可なくＲＯＭへアップデートされることを防ぐためのメカニズムが存在する場合には、アップデートを実行するために、認可されたコードのみが実行されているので、このアップデート手続きは全く安全である。一旦妥当性検証プロセスが成功したら、アップデート・バリデータ２３０は、新しいモジュール・バージョン２５０と一致するように実際のＲＯＭイメージ２１０に格納した仮想ＲＯＭポインタ２２０をアップデートし、その後、アップデートしたモジュールを任意でローカルディスク２７０のキャッシュに入れる。このアップデートは、仮想ＲＯＭポインタ２２０に格納された、バージョン番号及びＳＨＡ−１メッセージダイジェストを変更することを含む。
【００４９】
図１２のフローチャートでこのアップデートプロセスについて更に説明する。アップデート検索プロセス２８０は、未探索のアップデート場所が存在するか否かを決定することで開始する（ステップ２８１）。未探索のアップデートプロセスがある場合（ステップ２８１）、検索パスから次の場所を選択し（ステップ２８２）、アップデートモジュールＧＵＩＤを用いてより新しいモジュールのメモリへの検索を試みる（ステップ２８４）。新バージョンが存在する場合（ステップ２８５）、図１０に関して上述したモジュールキー妥当性検証手続きを用いて、このモジュールの妥当性を検証する（ステップ２８８）。ＶＲＯＭモジュールの新バージョンが存在しない場合、標準の検索プロセスを行う（ステップ２８６）。より新しいモジュールが存在する場合には、妥当性検証を試みる（ステップ２８９）。妥当性検証が成功した場合には、上述のようにこの新しいモジュールを「より接近して」キャッシュに入れることができるか否かに関して更なる決定を行う（ステップ２９１）。この新しいモジュールをより接近してキャッシュに入れることができる場合、検索パス内でより接近してそれをキャッシュに入れる（ステップ２９２）。キャッシュに入れることに関係なく、バリデータプロセスは、アップデートしたモジュールを反映するためにＶＲＯＭポインタをアップデートし（ステップ２９４）、それから、メモリ内のアップデートしたモジュールにアクセスし（ステップ２９６）、その時点で検索プロセスを終了する２９８。
【００５０】
アップデートモジュールに関連したモジュールキーの妥当性を検証するための本発明の例示的な実施形態におけるステップのシーケンスを図１３で概説する。モジュールキー妥当性検証プロセス３００は、新しいモジュールに基づくＳＨＡ−１メッセージダイジェストの生成から開始する（ステップ３０２）。本発明の範囲を逸脱せずに、本明細書に記載された暗号化及び解読プロセスのために、様々なインプリメンテーションに様々なメッセージダイジェストアルゴリズムを用いてもよいことが当業者に理解されるはずである。その後、公開・非公開キーの公開部分を用いて、モジュールキーを解読する（ステップ３０４）。これら２つのメッセージダイジェストが同等か否かを確かめるためにそれらを比較する（ステップ３０５）。この比較でこれらメッセージダイジェストが同等であることが明らかになった場合、妥当性検証は成功である３０６。この比較でこれらメッセージダイジェストが同等であることが明らかにならなかった場合、妥当性検証は失敗である３０８。
【００５１】
上述のように、アップデートプロセスの一部として代替妥当性検証技法も使用してもよい。仮に無認可の読み出しからＲＯＭの部分を隠すことができる場合、アップデート妥当性検証のために対称な非公開キーを使用できる。そうするための技法について以下に説明する。この技法に関して、共通の非公開キーは、ビルドプロセス中に生成され、ベンダーだけでなくＲＯＭによっても暗号形式で格納される。同じ対称キーを用いて、アップデート「キー」を暗号化し解読できる。代わりに、アップデートをダウンロードするための信頼されたサーバーで、ＴＬＳ又はＳＳＬを用いる通信用の安全なトンネルを作成できる。その後、アップデート自体で提供される任意のメッセージダイジェストに基づくのではなく、信頼された者と通信が生じているという事実に基づいて、妥当性が検証される。
【００５２】
更に、本発明の例示的な実施形態を用いて、ファームウェア用の安全ストレージ領域を作成してアクセスしてもよい。暗号化又は署名のためにＲＯＭイメージの内部に秘密キーを隠しておくことにより、ＲＯＭイメージに置かれていない安全ストレージを１つ作成する。上述の任意の仮想ＲＯＭモジュールを参照しアクセスすることとほぼ同じ方法で、この安全ストレージを参照しアクセスしてもよいが、このストレージ領域がローカルディスク以外の場所にある場合は、追加の独自のマシン識別子を必要とする。
【００５３】
フレームワーク環境では、ストレージの使用を望む全てのファームウェア・コード用の安全な暗号化されたストレージのために、単一のファームウェア・ボリュームを使用してもよい。ファームウェア・ボリュームを使用すると、ストレージが単一のユニットとして非ＲＯＭ場所から読み込まれ、単一のユニットとして書き込み直される。更に、複数のファームウェア・ボリュームを用いる他のソリューションは、直ちに明白になるはずである。上述のような再帰的な方法で実際のＲＯＭ或いは第１ファームウェア・ボリュームの何れかによって、これらの追加ファームウェア・ボリュームを参照してもよい。更に、こうしたファームウェア・ボリューム各々は、それが暗号化されているか、或いは単に書き込み不能になっているかを識別するフラグを持つことができる。
【００５４】
本発明の例示的な実施形態は、ビルドプロセス中にストレージを保留してもよい。仮想ＲＯＭのビルド・プロシージャ中に、必要な暗号化されたストレージとして特定のファイルにマークを付ける。これらのファイルの各々は、１つの特定のファームウェア・コードによって最終的に使用される、ある暗号化されたストレージ領域用のプレースホルダの役割をする。このビルド・プロシージャは、これらのプレースホルダ・ファイル全てを合わせてファームウェア・ボリュームにし、ＳＨＡ−１アルゴリズムを用いてこのファームウェア・ボリューム用のメッセージダイジェストを生成して、ＲＯＭ部品用の主要なファームウェア・ボリュームにこのファームウェア・ボリュームの参照（つまり仮想ＲＯＭポインタ）を格納する。この仮想ＲＯＭポインタは、以前のように、参照した（暗号化されたストレージ）ファームウェア・ボリューム用の独自の識別子と、ファームウェア・ボリュームを検索するためにアクセスされるドライバを示すＧＵＩＤとを含む。加えて、それは２つのフラグを含み、１つ目はランタイム中にそれを暗号化するべきであることを示すもので、２つ目はそれがまだ暗号化されていないことを示すものである。
【００５５】
実際のＲＯＭ用のビルド・プロシージャは、更にマシン識別子及び暗号化キーという２つの追加の変数のためのスペースを保留する。プリブート時に読み取り不能としてマークが付けられたファームウェア・ボリュームに、暗号化キー用のスペースを置く一方で、プリブート時に書き込み不能としてマークが付けられたファームウェア・ボリュームに、マシン識別子用のスペースを置く（この読み取り及び書き込み不能については以下でより詳しく説明する）。続いて、プリブートコードによって、最初に、暗号化されたストレージを含むことになっているファームウェア・ボリュームを検索することを決定してもよい。このプリブートコードによって、仮想ＲＯＭポインタを見る際に、参照されているファイルが暗号化のためにマーク付けされているもののまだ暗号化されていないということを決定する。この状況では、プリブートコードによって、上述の同じメカニズムを用いてファイルの第１バージョンを検索する。まだストレージが使用されていないので、ビルドの時間中に構築されていた対応するファームウェア・ボリュームの共通インスタンスは、プリブートコードの実行インスタンス全てに利用可能になってもよい。ファームウェア・ボリュームを以前のようにメモリにロードし、他のファームウェア・ボリュームと同じ方法でプリブートコードがアクセスしやすくなる。しかしながら、仮想ＲＯＭポインタの場所をアップデートする必要があるので、このファームウェア・ボリュームへのアクセスを提供するドライバは、更に仮想ＲＯＭポインタの場所と同様に（永続（原語：persistent）ストレージ媒体にそれを書き込み直すべきであることを示すための）「ダーティ」フラグも追跡する。このファームウェア・ボリューム内のファイルに対するどのアップデートでも、このダーティフラグをセットさせる。
【００５６】
図１４は、「安全ストレージ領域」（つまり「安全ストレージ領域」をまとめるファームウェア・ボリューム）が最初に読み込まれて、マシンＩＤ及び暗号化キーが生成された時に、メモリ３２０をどのように分類するかを示す。このメモリ領域３２０は、ＲＯＭイメージ３３０と安全ストレージ領域３４０とを含む。このＲＯＭイメージは、アップデート可能な領域３３２と、アップデートから保護された（書き込み防止の）領域３３４とを含む。このアップデートから保護された領域３３４は、安全ストレージＶＲＯＭポインタ３３５と、独自のマシンＩＤ用ストレージ３３６とを含有する。この安全ストレージＶＲＯＭポインタは、ＶＲＯＭモジュール用のＧＵＩＤと、メッセージダイジェスト３３７と、暗号化フラグ３３３とを含む。このＲＯＭイメージは、暗号化キー用ストレージ３３９を含む、読み出しから保護された（読み出し防止の）領域３３８を更に備える。
【００５７】
ある時点において（ファームウェア・ボリュームの書き込み全てに対していつもというわけではないが）、プリブートコードによって、変更したファームウェア・ボリュームをあるストレージ媒体へ書き込むために決定を行う。この書き込みの決定は、前段落に記載したダーティフラグによって定まる。このプリブートコードによって、マシン識別子と暗号化キーとが生成されていないことを検知する。それによって、このマシン識別子とこの暗号化キーとを生成して、実際のＲＯＭ内のそれぞれのストレージ場所に保存する。これらの識別子を生成するためには、独自の値を生成するいかなる適切なメカニズムも使用できる。１つのソルーションは、両方のためのＧＵＩＤ１つを使用することである。
【００５８】
これら識別子の生成に続いて、本発明の例示的な実施形態は、次に、ファームウェア・ボリュームを暗号化するべきであるがまだそうなってはいないことを仮想ＲＯＭポインタにおいて検知する。それは、暗号化キーを用いてファームウェア・ボリュームを暗号化し、それらの結果に基づいてＳＨＡ−１メッセージダイジェストを生成する。本発明のためには、Ｂｌｏｗｆｉｓｈ、ＤＥＳ／３ＤＥＳ、ＩＤＥＡなどを含む、いかなる適切な暗号化アルゴリズムを使用してもよい。
【００５９】
ファームウェア・ボリュームの暗号化と、それらの結果に基づいたメッセージダイジェストの生成とに続いて、次に、プリブートコードによって、暗号化されたファームウェア・ボリュームを書き込む場所を決定しなければならない。この暗号化されたファームウェア・ボリューム用の１つの場所は、図１５に示すようなローカルディスクドライブ３５０のディレクトリである。しかしながら、この暗号化されたファームウェア・ボリューム３４０を、代わりにローカル・ネットワーク・サーバーに、又はウェブに、又は別のアクセス可能な場所に格納してもよい。マシン識別子３３６とファームウェア・ボリューム・ファイルを識別するＧＵＩＤ３３１との組み合わせを用いて、独自の場所にファイルを書き込む。この時点では、プリブートコードによって、ファームウェア・ボリューム３４０を暗号化したことを示すことと、新しく生成されたメッセージダイジェスト３３７を反映することとの両方のために、実際のＲＯＭ内の仮想ＲＯＭポインタ３３５をアップデートする。
【００６０】
図１６のフローチャートに、安全ストレージを書き込むプロセスを示す。安全ストレージを書き込むプロセス４００は、永続媒体にファームウェア・ボリュームを書き込み直すべきであることを示す、ダーティフラグがセットされているか否かを決定すること（ステップ４０１）で開始する。ダーティフラグがセットされていない場合は、このプロセスを終了する４２０。ダーティフラグがセットされている場合は、ＶＲＯＭポインタ３３５に暗号化されたフラグ３３３がセットされているか否かに関して決定を行う（ステップ４０３）。暗号化されたフラグがセットされている場合は（ステップ４０３）、暗号化キーを用いて安全ストレージ領域を暗号化する（ステップ４０８）。暗号化されたフラグがセットされていない場合は（ステップ４０３）、マシンＩＤを生成して格納し（ステップ４０４）、そして、暗号化キーを生成して格納する（ステップ４０６）。その後、この暗号化キーを用いて安全ストレージを暗号化する（ステップ４０８）。
【００６１】
安全ストレージの暗号化（ステップ４０８）に続いて、メッセージダイジェストを生成して、この暗号化された安全ストレージに格納する（ステップ４１０）。その後、マシンＩＤ３３６とストレージＧＵＩＤ３３１とを用いて、第２ストレージにこの暗号化されたストレージを書き込む（ステップ４１２）。安全ストレージの書き込み（ステップ４１２）の後に、この新しいメッセージダイジェストと、この暗号化されたフラグとによって、ＶＲＯＭポインタをアップデートし（ステップ４１４）、そしてこの書き込みプロセスを終了する４２０。
【００６２】
本発明の例示的な実施形態は、図１７のフローチャートに示すように、暗号化されたファームウェア・ボリュームを検索するプリブートコードをサポートする。安全ストレージの読み出しプロセス４４０は、ＶＲＯＭポインタに暗号化されたフラグがセットされているか否かをプリブートコードによって決定すること（ステップ４４１）から開始する。ファームウェア・ボリューム３４０が暗号化されていることを、プリブートコードによって仮想ＲＯＭポインタ３３５のフラグから検知する場合は（ステップ４４１）、このプリコードによって、マシン識別子３３６とＧＵＩＤ３３１との組み合わせを用いて、このファームウェア・ボリュームを検索し読み出す（ステップ４４４）。ＶＲＯＭポインタに暗号化されたフラグがセットされていない場合は、プリブートコードによって、このストレージＧＵＩＤを用いて、暗号化されていない安全ストレージの初期値を他の場所から読み出す（ステップ４４２）。一旦このファームウェア・ボリュームが読み出されると（ステップ４４２或いはステップ４４４）、メッセージダイジェストを生成して、この安全ストレージに格納する（ステップ４４６）。この生成されたメッセージダイジェストをＶＲＯＭポインタ内のメッセージダイジェストと比較し、その妥当性を検証する（ステップ４４７）。一致しない組み合わせがある場合は、この安全ストレージの読み出しは失敗する（ステップ４４８）。この妥当性検証が成功する場合は、次に、プリブートコードによって、このファームウェア・ボリュームを解読し（ステップ４５０）、それをメモリ３２０において利用可能にする。そして、この読み出しプロセスを終了する４６０。前と同様に、このファームウェア・ボリューム３４０への変更が行われたか否かを決定するために、ダーティフラグを保持する。暗号化キーとマシン識別子とを再度作成する必要がない点を除き、２度目又はその後の繰り返しにおいても、最初の書き込みと同じ方法で、この変更したファームウェア・ボリュームをストレージへ書き込む。
【００６３】
プリブート処理中のある時点において、本発明の例示的な実施形態は、更なる改ざん又はアクセスを防ぐために、実際のＲＯＭの様々な部分をロックする。このための正確なメカニズムは、ハードウェアに依存する。本説明では、このロックが起きる特定の時点に注目する。この時点とは、ストレージへの書き込みによってこの変更したファームウェア・ボリュームを一気に消去することと同時であってもよく、或いはその後であってもよい。
【００６４】
ＥＦＩ互換性を保ちながらストレージを読み取り不能にするある時点とは、オペレーティングシステムのロードを開始しかけていることをＯＳローダがＥＦＩ環境に通知する時点である「ブート終了時サービス（原語：Exit Boot Services）」中のことである。これは、インプリメントすることがかなり容易である一方（ブート終了時サービス中にドライバに通知できる）、この点での危険は、このＯＳローダ・コードの信頼レベルにある。このＯＳローダ・コードが、他の仮想ＲＯＭモジュールと同じ方法でファームウェアのビルドプロセスの一部として利用可能になった場合には、このソルーションは全く安全である。これに対して、このＯＳローダ・コードが、レガシー・ブート・プロトコルを用いるといった他の方法でアクセスされる場合には、実際のＲＯＭストレージを読み取り不能にする最適の時点は、ブートオプションを検討する直前である。フレームワーク用語では、これを「ＤＸＥ」（ドライバ実行環境）フェーズと「ＢＤＳ」（ブートデバイス選択）フェーズとの間の移行と呼ぶであろう。
【００６５】
更に、本発明の例示的な実施形態では、データをプリブート中に生成でき、安全な方法で他の環境に利用可能になる。ファームウェア・イメージのビルドプロセス中に、２つの別々の安全ストレージ・ファームウェア・ボリュームに２つのファイルを保留する。第１ファイルを公開・非公開キーの公開部分のために保留し、書き込み不能である安全ストレージ・ファームウェア・ボリューム内に保留する。第２ファイルを公開・非公開キーの非公開部分のために保留し、読み取り不能である安全ストレージ・ファームウェア・ボリューム内に保留する。
【００６６】
プリブート時に、特定のプラットフォーム用に独自の公開・非公開キーを生成し、それぞれの安全ストレージ・ファームウェア・ボリュームに格納する。このためのアルゴリズムは、ＲＳＡといった任意の標準非対称キーアルゴリズムであってもよい。続いて、プリブート・ファームウェアは、他の環境への配信用に作成されたコンテンツに署名し、この署名は、このコンテンツ上でメッセージダイジェストアルゴリズムを実行することと、公開・非公開キーの非公開部分を用いてこのコンテンツを暗号化することとによって行われる。このコンテンツと、生じた暗号化されたメッセージダイジェストとの両方を任意のストレージ場所に格納できる。別の環境がプリブート・コンテンツを受信する際、書き込み不能のストレージに公開・非公開キーの公開部分を格納するが、まだ読み出し可能である。この公開部分を用いて、このコンテンツに伴うメッセージダイジェストを解読し、その後、このコンテンツに再度適用した同じメッセージダイジェストアルゴリズムの出力とその解読結果を照合する。このプロセスでは、このコンテンツが改ざんされていないことを保証する。他の環境が公開・非公開キーの非公開部分にアクセスしにくいので、公開キーの公開部分を用いてコンテンツを解読し妥当性を検証することができることと同じ方法で、他のコンテンツを生成するか或いは署名することは実際に不可能である。
【００６７】
本発明の範囲を逸脱せずに幾つかの変更を行なってもよいので、上記説明に含まれているか或いは添付の図面に示された全ての事柄は、例示的なものとして解釈されるものであって文字通りの意味に解釈されないことが意図されている。当業者は、本発明の範囲を逸脱せずに、図に示したステップのシーケンス及びアーキテクチャーを変更してもよいことと、本明細書に含まれる実例が本発明の多数の可能な描写の珍しい例であることとを理解するはずである。
【図１】
0005403771.tif 000002
【図２】
0005403771.tif 000003
【図３】
0005403771.tif 000004
【図４】
0005403771.tif 000005
【図５】
0005403771.tif 000006
【図６】
0005403771.tif 000007
【図７】
0005403771.tif 000008
【図８】
0005403771.tif 000009
【図９】
0005403771.tif 000010
【図１０】
0005403771.tif 000011
【図１１】
0005403771.tif 000012
【図１２】
0005403771.tif 000013
【図１３】
0005403771.tif 000014
【図１４】
0005403771.tif 000015
【図１５】
0005403771.tif 000016
【図１６】
0005403771.tif 000017
【図１７】
0005403771.tif 000018