(57)【特許請求の範囲】
【請求項１】
コンピュータが不揮発性メモリに格納された第１の旧モジュールと第２の旧モジュールを第１の新モジュールと第２の新モジュールで更新する方法であって、
フラッシュ・ツールが前記第２の旧モジュールを上書きするように前記第１の新モジュールと前記第２の新モジュールを書き込む機能を前記コンピュータに実現させるステップと、
前記第１の旧モジュールが前記第１の新モジュールと前記第２の新モジュールの完全性を検証する機能を前記コンピュータに実現させるステップと、
プロセッサのリセットに応答して前記第１の新モジュールを実行するステップと、
前記第１の新モジュールに続いて実行された前記第２の新モジュールが前記第１の新モジュールを前記第１の旧モジュールが書き込まれていた記憶領域に書き込む機能を前記コンピュータに実現させるステップと
を有する方法。
【請求項２】
前記第１の旧モジュールは前記不揮発性メモリの書き込み保護の可能な記憶領域に書き込まれている請求項１に記載の方法。
【請求項３】
前記書き込み保護の可能な記憶領域が、リセットした前記プロセッサが最初に実行するアドレスを有するブート・ブロックである請求項１または請求項２に記載の方法。
【請求項４】
前記第１の旧モジュールおよび前記第１の新モジュールが前記コンピュータで実行されるプログラムの完全性を保証する信頼のチェーンにおいて最上位に位置するＣＲＴＭ（Core Root of Trust for Measurement）である請求項１から請求項３のいずれかに記載の方法。
【請求項５】
前記第１の新モジュールを実行するステップの前に、前記第１の旧モジュールが前記第１の旧モジュールと前記第１の新モジュールのいずれを実行するかを判断する機能を前記コンピュータに実現させるステップを含む請求項１から請求項４のいずれかに記載の方法。
【請求項６】
前記第１の旧モジュールが前記不揮発性メモリに前記第１の旧モジュールと前記第２の新モジュールが共存することを示す混在フラグを設定する機能を前記コンピュータに実現させるステップを有し、
前記判断する機能を前記コンピュータに実現させるステップが前記混在フラグを確認する機能を前記コンピュータに実現させるステップを含む請求項５に記載の方法。
【請求項７】
前記第１の新モジュールと前記第２の新モジュールを書き込む機能を前記コンピュータに実現させるステップに続いて前記フラッシュ・ツールが更新フラグを設定する機能を前記コンピュータに実現させるステップを有し、
前記混在フラグを設定する機能を前記コンピュータに実現させるステップを、前記プロセッサのリセットに応答して実行された前記第１の旧モジュールが前記更新フラグを確認して実行する機能を前記コンピュータに実現させる請求項６に記載の方法。
【請求項８】
前記フラッシュ・ツールが、前記第１の新モジュールと前記第２の新モジュールを格納するブート・デバイスに格納されている請求項１から請求項７のいずれかに記載の方法。
【請求項９】
コンピュータが第１の旧モジュールを格納するブート・ブロックと第２の旧モジュールを格納するシステム・ブロックと前記第１の旧モジュールを格納するステージング・ブロックが定義された不揮発性メモリを第１の新モジュールと第２の新モジュールで更新する方法であって、
フラッシュ・ツールが前記システム・ブロックに前記第２の新モジュールを書き込み前記ステージング・ブロックに前記第１の新モジュールを書き込む機能を前記コンピュータに実現させるステップと、
前記第１の旧モジュールが前記第１の新モジュールと前記第２の新モジュールの完全性を検証する機能を前記コンピュータに実現させるステップと、
プロセッサがリセットされたときに実行される前記第１の旧モジュールが、前記第１の新モジュールおよび前記第２の新モジュールが前記不揮発性メモリに書き込まれていると判断する機能を前記コンピュータに実現させたときに、前記第１の旧モジュールが実行を完了する前に前記第１の新モジュールを実行するステップと、
前記第１の新モジュールに続いて実行される前記第２の新モジュールが前記第１の新モジュールを前記ブート・ブロックに書き込む機能を前記コンピュータに実現させるステップと
を有する方法。
【請求項１０】
前記ブート・ブロックが前記第１の旧モジュールの製造者が保有する秘密鍵に対応する公開鍵を格納し、前記システム・ブロックが前記第１の新モジュールと前記第２の新モジュールのハッシュ値を前記秘密鍵で暗号化した暗号化ダイジェストを格納し、
前記完全性を検証する機能を前記コンピュータに実現させるステップが、
前記第１の旧モジュールが前記公開鍵で前記暗号化ダイジェストを復号する機能を前記コンピュータに実現させるステップと、
前記第１の旧モジュールが前記第１の新モジュールと前記第２の新モジュールのハッシュ値を計算する機能を前記コンピュータに実現させるステップと
を有する請求項９に記載の方法。
【請求項１１】
前記第１の新モジュールを実行するステップが前記ブート・ブロックのライト・ロックを省略する請求項９または請求項１０に記載の方法。
【請求項１２】
前記第１の旧モジュールが更新フラグを設定してプロセッサをリセットする機能を前記コンピュータに実現させるステップと、
前記第１の旧モジュールが前記更新フラグを検出したときに混在フラグを設定して前記プロセッサをリセットする機能を前記コンピュータに実現させるステップとを有し、
前記第１の新モジュールを実行するステップが、前記第１の旧モジュールが前記混在フラグを検出したときに前記第１の新モジュールにジャンプする機能を前記コンピュータに実現させるステップを含む請求項９から請求項１１のいずれかに記載の方法。
【請求項１３】
前記第１の旧モジュールが前記更新フラグを検出しないときに前記ブート・ブロックに対してライト・ロックを設定して通常のブートを実行する機能を前記コンピュータに実現させるステップを有する請求項１２に記載の方法。
【請求項１４】
プロセッサと、
前記プロセッサがリセットされたときに最初に実行する第１の旧モジュールと該第１の旧モジュールに続いて実行する第２の旧モジュールを記憶する不揮発性メモリと、
前記第１の旧モジュールを更新する第１の新モジュールと前記第２の旧モジュールを更新する第２の新モジュールを記憶する記憶装置に接続が可能なインターフェースと、
前記プロセッサがフラッシュ・ツールを実行することで構成された、前記第２の旧モジュールを上書きするように前記第１の新モジュールと前記第２の新モジュールを前記不揮発性メモリに書き込む手段と、
前記プロセッサが前記第１の旧モジュールを実行することで構成された前記第１の新モジュールおよび前記第２の新モジュールの完全性を検証する手段とを有し、
前記プロセッサのリセットに応答して前記プロセッサが前記第１の新モジュールに続いて前記第２の新モジュールを実行して、前記第１の新モジュールを前記第１の旧モジュールが書き込まれていた記憶領域に書き込むコンピュータ。
【請求項１５】
前記第１の旧モジュールが書き込まれる記憶領域が、前記第１の旧モジュールが前記第２の旧モジュールに前記プロセッサの制御権を移す前にライト・ロックの設定が可能なブート・ブロックである請求項１４に記載のコンピュータ。
【請求項１６】
前記第１の旧モジュールおよび前記第１の新モジュールを前記コンピュータの製造者が製造したことがＰＫＩ（Public Key Infrastructure）方式で検証することで保証されている請求項１４または請求項１５に記載のコンピュータ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータに実装されるシステム・ファームウェアを更新する技術に関する。
【背景技術】
【０００２】
コンピュータには、ハードウェアとオペレーティング・システム（ＯＳ）、デバイス・ドライバまたはアプリケーション・プログラムなどの上位のプログラムとデバイスの間のインターフェースを提供するＢＩＯＳが実装される。ＢＩＯＳは通常マザーボードに取り付けられたフラッシュ・メモリ（ＢＩＯＳ＿ＲＯＭ）に格納されて電源を起動したときにオペレーティング・システム（ＯＳ）をロードする前に実行される。
【０００３】
ＴＣＧ（Trusted Computing Group）といわれる組織では、コンピュータの製造者がより安全で信頼できるコンピュータを提供するためのハードウェア、ＢＩＯＳおよびＯＳの仕様を策定している。ＴＣＧの仕様では、ＢＩＯＳの一部に同一システムで動作するすべてのプログラムの信頼の基礎となるように完全性が保証されたＣＲＴＭ（Core Root of Trust for Measurement）というコードが定義されている。
【０００４】
ＣＲＴＭは、コンピュータで実行されるプログラムのなかで絶対的に完全性が保証されている。ここにプログラムの完全性とは、コンピュータの製造者またはシステムのオーナー（以下、製造者という。）以外の者がシステム・ファームウェアの更新または改変をしていないことを意味し、一貫性またはインテグリティ（integrity）などということもある。
【０００５】
ＣＲＴＭはＢＩＯＳ＿ＲＯＭに定義されたブート・ブロックという記憶領域に格納される。ＢＩＯＳ＿ＲＯＭのブート・ブロック以外の記憶領域をシステム・ブロックということにする。また、ＢＩＯＳ＿ＲＯＭに格納された全体のコードをシステム・ファームウェアということにする。なお、コンピュータには、個別のデバイスのコントローラにデバイス・ファームウェアも実装される。
【０００６】
プロセッサには、リセットされたときに最初にブート・ブロックのＣＲＴＭを実行するようにリセット・ベクタが設定されている。ＣＲＴＭはＢＩＯＳの中の次にプロセッサの制御権を渡すコードの完全性を、制御権を渡す前に検証する。その後制御権を受け取ったコードは他のコードに制御権を渡す前に当該コードの完全性を検証する。以後同様にして順番に後段のプログラムの完全性を検証することで１つのコンピュータで実行されるプログラム全体に信頼のチェーンを構築することができる。このときＣＲＴＭは信頼のチェーンのなかで最も上位に位置して信頼の基礎を構築する。
【０００７】
ところでシステム・ファームウェアはデバイスの進化とともに随時更新が必要になる。新システム・ファームウェアも旧ＣＲＴＭから継続して信頼の基礎を築く必要があるため、旧ＣＲＴＭは新システム・ファームウェアが真正な製造者により製造されたものであることを事前に検証する。また、新ＣＲＴＭのＢＩＯＳ＿ＲＯＭへの書き込みはＯＳをロードする前の安全な環境で行うことが望ましい。したがって新ＣＲＴＭを書き込むコードは、旧システム・ファームウェアまたは新システム・ファームウェアの一部としてそれらの中に埋め込まれている。
【０００８】
特許文献１は、ブート・ブロックにＣＲＴＭが格納されＢＩＯＳブロックにＢＩＯＳが格納されたプライマリ・フラッシュ・バンクと、ＣＲＴＭとＢＩＯＳのコピーをブート・ブロックとＢＩＯＳブロックに格納するセカンダリ・フラッシュ・バンクを備えるコンピュータ・システムを開示する。一方のバンクのＢＩＯＳを実行できないときは他方のバンクに切り換える。また、ブート・ブロックには、ＣＲＴＭを更新するためのコードが格納されている。
【０００９】
特許文献２は、ＣＲＴＭを更新する方法を開示する。同文献に記載する更新方法では、新ＣＲＴＭをメイン・メモリに展開し、フラグを設定してコンピュータをサスペンド状態に遷移させる。レジュームの際にフラグを検出すると、旧ＣＲＴＭが新更新モジュールを認証する。ＢＩＯＳ＿ＲＯＭの被認証モジュールを新更新モジュールで更新したあとにＣＲＴＭのロックを解除する。認証された新更新モジュールを実行して、旧ＣＲＴＭを新ＣＲＴＭに書き換える。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】米国特許７６１３８７２号公報
【特許文献２】特開２００８−５２３４９４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
ＣＲＴＭはシステム・ブロックに制御権を移す際にブート・ブロックに書き込み保護（ライト・ロック）を行う。以後、他のコードがライト・ロックを解除することはできないためブート・ブロックはセキュアな記憶領域として構成されている。したがって、ＣＲＴＭが損傷するとユーザでは容易に復旧できなくなるため、近年はＣＲＴＭのコード量を必要最小限に留めるようになってきている。そのために、ＣＲＴＭを更新するコードもシステム・ブロックに格納するようになってきている。その結果、それまでにない更新時の問題が発見された。
【００１２】
図６は、ＢＩＯＳ＿ＲＯＭに格納された旧システム・ファームウェアを従来の方法で更新する際の問題を説明する図である。更新前の状態を示す図６（Ａ）では、ブート・ブロックに旧ＣＲＴＭ１ａが格納され、システム・ブロックには旧ＢＩＯＳ３ａと旧ＣＲＴＭ１−ａが格納されている。ここでは更新後の状態を示す図６（Ｃ）のように、旧ＣＲＴＭ１ａを新ＣＲＴＭ１ｂで書き換え、旧ＢＩＯＳ３ａを新ＢＩＯＳ３ｂで書き換えるものとする。旧ＣＲＴＭ１ａ−１、新ＣＲＴＭ１ｂ−１は、それぞれ旧ＣＲＴＭ１ａ、新ＣＲＴＭ１ｂのコピー元のコードであり、更新時だけ必要とされる。
【００１３】
図６（Ｂ）の状態で旧ＣＲＴＭ１ａを新ＣＲＴＭ１ｂ−１で書き換えるコードは、新ＢＩＯＳ３ｂの中に埋め込まれているため、更新を行う際はＣＰＵをリセットして最初に旧ＣＲＴＭ１ａを実行する。また、旧ＣＲＴＭ１ａは新ＢＩＯＳ３ｂと新ＣＲＴＭ１ｂ−１で構成される新システム・ファームウェアの完全性を検証してから更新される。このような事情から、システム・ファームウェアの更新は２段階プロセスで行っている。
【００１４】
具体的には、最初に図６（Ｂ）に示すようにシステム・ブロックに新ＢＩＯＳ３ｂと新ＣＲＴＭ１ｂ−１からなる新システム・ファームウェアを書き込む。つぎにＣＰＵをリセットした後、旧ＣＲＴＭ１ａが、ＰＫＩ（Public Key Infrastructure）方式で新システム・ファームウェアの完全性を検証する。旧ＣＲＴＭ１ａは、新システム・ファームウェアの完全性を検証すると、自身の更新のためにブート・ブロックに対してライト・ロックをせずに、新ＢＩＯＳ３ｂにプロセッサの制御権を渡す。新ＢＩＯＳ３ｂは新ＣＲＴＭ１ｂ−１をブート・ブロックに新ＣＲＴＭ１ａとして書き込む。このとき、ＢＩＯＳ＿ＲＯＭには図６（Ｂ）のように、旧ＣＲＴＭ１ａと新ＢＩＯＳ３ｂが混在する状態が発生する。そして、リセットされたプロセッサが旧ＣＲＴＭ１ａを実行し、さらに新ＣＲＴＭ１ｂ−１を書き込むために新ＢＩＯＳ３ｂを実行するときに、ＣＲＴＭとＢＩＯＳとでコーディング／ビルドにおいて同じファイルを参照し、新システム・ファームウェアでそのファイルが更新された場合、旧ＣＲＴＭ１ａの変数の定義と新ＢＩＯＳ３ｂの変数の定義が異なると、その時点でプログラムの実行が中断して更新ができなくなってしまう。
【００１５】
新ＢＩＯＳ３ｂをコーディングする際に、旧ＣＲＴＭ１ａと変数の定義を一致させれば問題はないがシステム・ファームウェアの製造者に過度の負担をかけることになりかねない。また、新システム・ファームウェアは旧ＣＲＴＭ１ａからコーディング上の制約を受けることになり、自由に改良を加えることができなくなる。さらに不注意なコーディングをしてしまった場合には、当該モジュールの更新を断念したり、時間をかけてデバッグしたりする必要がある。
【００１６】
特許文献２にかかるＣＲＴＭの更新方法でも、旧ＣＲＴＭと新更新モジュールがＢＩＯＳ＿ＲＯＭに共存するため同様の問題が生ずる。製造者は、新ＣＲＴＭと新ＢＩＯＳとの間では容易に整合性を図ることができるため、２段階プロセスでセキュアに更新するときに旧ＣＲＴＭとの整合性の問題を回避できることが望ましい。
【００１７】
そこで本発明の目的は、システム・ファームウェアを確実に更新する方法を提供することにある。さらに本発明の目的は完全性を検証したシステム・ファームウェアで更新する方法を提供することにある。さらに本発明の目的は、ライト・ロックの可能な記憶領域に格納されるコードの量を低減することができる更新方法を提供することにある。さらに本発明の目的は、新システム・ファームウェアのコーディングの自由度を拡大した更新方法を提供することにある。さらに本発明の目的は、そのような方法を実現するコンピュータおよびコンピュータ・プログラムを提供することにある。
【課題を解決するための手段】
【００１８】
本発明にかかる不揮発性メモリには第１の旧モジュールと第２の旧モジュールが格納されている。第１の旧モジュールを更新する第１の新モジュールと第２の旧モジュールを更新する第２の新モジュールは、外部メモリやネットワークを通じてコンピュータに提供することができる。
【００１９】
最初に第２の旧モジュールを上書きするように第１の新モジュールと第２の新モジュールを不揮発性メモリに書き込む。つづいて第１の旧モジュールが第１の新モジュールと第２の新モジュールの完全性を検証する。つづいてプロセッサのリセットに応答して第１の新モジュールを実行する。さらにつづいて、第１の新モジュールに続いて実行される第２の新モジュールが第１の新モジュールを第１の旧モジュールが書き込まれていた記憶領域に上書きする。
【００２０】
このような手順により、第１の旧モジュールと第２の旧モジュールを、通常のブートでＯＳをロードする前に、完全性を検証した第１の新モジュールと第２の新モジュールで更新することができる。このとき、プロセッサがリセットされると第１の新モジュールを実行してから第２の新モジュールに制御権が移るため、第１の旧モジュールと第２の新モジュールとの間での変数の定義が整合していなくてもプログラムの実行が途中で停止することはない。製造者は第１の新モジュールと第２の新モジュールの間で定義する変数の整合性を図ればよいため、第１の旧モジュールの制約を受けないで新システム・ファームウェアをコーディングすることができる。
【００２１】
第１の旧モジュールは不揮発性メモリの書き込み保護の可能な記憶領域に書き込むことができる。また書き込み保護の可能な記憶領域は、リセットしたプロセッサが最初に実行するアドレスを有するブート・ブロックとすることができる。このとき、第２の新モジュールが第１の新モジュールをブート・ブロックに書き込むため、ブート・ブロックに格納するコードの量を低減することができる。第１の旧モジュールと第１の新モジュールはコンピュータで実行されるプログラムの完全性を保証する信頼のチェーンにおいて最上位に位置するＣＲＴＭ（Core Root of Trust for Measurement）とすることができる。
【００２２】
第１の新モジュールを実行するステップでは、第１の旧モジュールが第１の旧モジュールの残りの部分と第１の新モジュールのいずれを実行するかを判断することができる。このとき不揮発性メモリに第１の旧モジュールと第２の新モジュールが共存することを示す混在フラグを設定することができる。このとき、判断するステップにおいて混在フラグを確認するようにしてもよい。
【００２３】
フラッシュ・ツールと第１の新モジュールと第２の新モジュールを格納するブート・デバイスを接続し、第１の新モジュールと第２の新モジュールを書き込んだあとにフラッシュ・ツールが更新フラグを設定することができる。このとき、混在フラグを設定するステップは、プロセッサのリセットに応答して実行された第１の旧モジュールが更新フラグを確認して実行するようにしてもよい。第１の新モジュールと第２の新モジュールはフラッシュ・ツールが書き込むようにしてもよい。また、フラッシュ・ツールを実行する前に第１の旧モジュールがその完全性を検証することが望ましい。
【発明の効果】
【００２４】
本発明により、システム・ファームウェアを確実に更新する方法を提供することができた。さらに本発明により完全性を検証したシステム・ファームウェアで更新する方法を提供することができた。さらに本発明により、ライト・ロックの可能な記憶領域に格納されるコードの量を低減することができる更新方法を提供することができた。さらに本発明により、新システム・ファームウェアのコーディングの自由度を拡大した更新方法を提供することができた。さらに本発明により、そのような方法を実現するコンピュータおよびコンピュータ・プログラムを提供することができた。
【図面の簡単な説明】
【００２５】
【図１】本発明にかかるノートＰＣの概略の機能ブロック図である。
【図２】不揮発性メモリ、ＵＳＢメモリ、およびＮＶＲＡＭのデータ構造の一例を示す図である。
【図３】システム・ファームウェアを更新する際の、ＢＩＯＳ＿ＲＯＭのデータの変遷を示す図である。
【図４】システム・ファームウェアの更新手順を示すフローチャートである。
【図５】システム・ファームウェアの更新手順を示すフローチャートである。
【図６】システム・ファームウェアを更新する際の問題を説明する図である。
【発明を実施するための形態】
【００２６】
図１は、ノートブック型パーソナル・コンピュータ（ノートＰＣ）１０の主要なハードウェアの構成を示す機能ブロック図である。図１には本発明の説明に必要な範囲のハードウェアだけを記載している。本発明においてはハードウェアの構成は周知であるためここでは簡略的に説明する。ノース・ブリッジ１３には、ＣＰＵ１１、メイン・メモリ１５、ビデオ・コントローラ１７およびサウス・ブリッジ２１が接続される。ビデオ・コントローラ１７には、ＬＣＤ１９が接続される。
【００２７】
サウス・ブリッジ２１はさまざまな規格のインターフェースを備え、図１には代表的にＳＡＴＡにハードディスク・ドライブ（ＨＤＤ）２３が接続され、ＳＰＩにＢＩＯＳ＿ＲＯＭ２５が接続され、ＵＳＢにＵＳＢコネクタ２７が接続され、ＬＰＣにＮＶＲＡＭ３１が接続されている様子を示している。ＢＩＯＳ＿ＲＯＭ２５は、ノートＰＣ１０のマザーボードに取り付けられている。ＵＳＢメモリ２９は、ＵＳＢコネクタ２７に接続する外部メモリとすることができる。ＮＶＲＡＭ３１は、電源が停止しても記憶を保持する不揮発性のメモリでリード・ロックおよびライト・ロックの可能なセキュアな記憶領域を備えている。
【００２８】
図２は、ＢＩＯＳ＿ＲＯＭ２５、ＵＳＢメモリ２９、およびＮＶＲＡＭ３１のデータ構造の一例を示す図である。ＢＩＯＳ＿ＲＯＭ２５の記憶領域には、ブート・ブロック１０１、システム・ブロック１０３およびステージング・ブロック１０５が定義されている。ＢＩＯＳ＿ＲＯＭ２５に格納されたすべてのコードおよびデータをシステム・ファームウェアという。ＢＩＯＳ＿ＲＯＭ２５に格納されたコードの参照番号には、更新前のコードにはサフィックスａを、更新後のコードにはサフィックスｂを付している。以下の説明では、更新前のコードについての説明は更新後のコードにも適用する。
【００２９】
ブート・ブロック１０１に格納されたコード全体を旧ＣＲＴＭ１００ａという。旧ＣＲＴＭ１００ａは、ＣＰＵ１１がリセットされたときに最初に実行されるリセット・ベクタのアドレスを有する。ブート・ブロック１０１は、ＢＩＯＳ＿ＲＯＭ２５の中で書き込みを禁止するライト・ロックの設定が可能な記憶領域である。旧ＣＲＴＭ１００ａは、通常のブート・ルーチンを実行する際にはＣＰＵ１１の制御権をシステム・ブロック１０３に格納された旧ＢＩＯＳ１１７ａに移す前に、サウス・ブリッジ２１のＳＰＩインターフェースを使用して、ブート・ブロック１０１をライト・ロックする。
【００３０】
旧ＣＲＴＭ１００ａは、本実施の形態にかかる更新を実行する際には、ライト・ロックを設定しないで新ＣＲＴＭ１００ｂ−１にジャンプするがその手順は後に説明する。ライト・ロックはサウス・ブリッジ２１がリセットされたときに自動的に解除される。旧ＣＲＴＭ１００ａは、更新のとき以外は自身がＣＲＴＭであるが故に、ブート・ブロック１０１のライト・ロックを行う。また、旧ＣＲＴＭ１００ａは新ＣＲＴＭ１００ｂをブート・ブロック１０１に上書きする際に、事前に新ＣＲＴＭ１００ｂの完全性の検証をしてからライト・ロックを行わない判断処理をする。したがって、更新にかかる新ＣＲＴＭ１００ｂは製造されてからマルウェアにより改竄されることはなく、また、旧ＣＲＴＭ１００ａまたは最初のＣＲＴＭを製造した製造者により製造されたものであることが一貫して保証される。
【００３１】
旧ＣＲＴＭ１００ａは、基本デバイス初期化コード１１１ａ、実行パス制御コード１１２ａ、完全性検証コード１１３ａ、および更新処理コード１１５ａといった必要最小限のコードで構成されている。基本デバイス初期化コード１１１ａは、リセットされたＣＰＵ１１がメイン・メモリ１５を使用できるようにするために必要な最小限のデバイスに対するＰＯＳＴ（Power On Self Test）処理をするためのコードである。
【００３２】
実行パス制御コード１１２ａは、ＮＶＲＡＭ３１の混在フラグ１５３を参照して、ブート・ルーチンを通常のブート・ルーチンと更新のブート・ルーチンのいずれかに決定する。実行パス制御コード１１２ａはＢＩＯＳ＿ＲＯＭ２５に旧ＣＲＴＭ１００ａと新システム・ファームウェアが混在する状態で実行される旧ＣＲＴＭ１００ａのコードをできるだけ少なくするために、基本デバイス初期化コード１１１が実行されてからできるだけ早い段階で実行される。完全性検証コード１１３ａは更新時に新システム・ファームウェアのハッシュ値を計算したり、通常のブート時にＣＰＵ１１の制御権を渡す前に旧ＢＩＯＳ１１７ａのハッシュ値を計算したりするためのＳＨＡ−１エンジンを含む。
【００３３】
完全性検証コード１１３ａは、新システム・ファームウェアの完全性をＰＫＩ方式で検証するための公開鍵を含む。完全性検証コード１１３ａは、実際のブート・ルーチンにおいて次にＣＰＵ１１の制御権を渡すＢＩＯＳ１１７ａの完全性を検証する。更新処理コード１１５ａは、ＮＶＲＡＭ３１の更新フラグ１５１を参照して、ＢＩＯＳ＿ＲＯＭ２５に旧ＣＲＴＭ１００ａと新システム・ファームウェアが混在すると判断したときにＮＶＲＡＭ３１に混在フラグ１５３を設定し、混在しないと判断したときは通常のブート・ルーチンに従ってブート・ブロック１０１をライト・ロックしてからＢＩＯＳ１１７ａにＣＰＵ１１の制御権を渡す。
【００３４】
システム・ブロック１０３は、システム・ファームウェアの中でＣＲＴＭ以外のコードを格納する記憶領域である。システム・ブロック１０３の先頭アドレスは固定アドレスになっている。システム・ブロック１０３には、旧ＢＩＯＳ１１７ａ、旧フラッシュ・ドライバ１１９ａおよび旧暗号化ダイジェスト１２１ａが格納されている。旧ＢＩＯＳ１１７ａは、デバイスの検査および初期化をするＰＯＳＴコード、デバイスを直接制御するＩ／Ｏコード、パワーオン・パスワードやＨＤＤパスワードの処理をするパスワード処理コード、セットアップ画面を表示してＢＩＯＳのセットアップをするためのセットアップ・コード、ノートＰＣ１０の電源を制御するパワー・マネジメント・コードなどの複数のモジュールで構成されている。
【００３５】
旧ＢＩＯＳ１１７ａはつぎにＣＰＵ１１の制御権を渡すデバイス・ファームウェアやブート・ローダの完全性を検証するためのＳＨＡ−１エンジンおよび公開鍵を保有していてもよい。このように各モジュールが次に制御権を渡すモジュールの完全性を検証することで、旧ＣＲＴＭ１００ａを基点としてシステム全体におけるソフトウェアの信頼のチェーンを構築することができる。
【００３６】
旧フラッシュ・ドライバ１１９ａは、前回更新されたときにステージング・ブロック１０５に書き込まれた旧ＣＲＴＭ１００ａ−１をブート・ブロック１０１に書き込むためにコピー元となったコードである。旧フラッシュ・ドライバ１１９ａは、旧システム・ファームウェアが更新された後は実行されることはない。旧暗号化ダイジェスト１２１ａは、旧システム・ファームウェアのハッシュ値を真正な製造者が保有する秘密鍵で暗号化したデータである。このダイジェストはシステム・ブロック１０３およびステージング・ブロック１０５が対象となっている。ステージング・ブロック１０５は、システム・ファームウェアを更新するために一時的に使用する記憶領域である。ステージング・ブロック１０５の先頭アドレスは固定アドレスになっている。ステージング・ブロック１０５には、旧ＣＲＴＭ１００ａ−１が格納されている。旧ＣＲＴＭ１００ａ−１は、ブート・ブロック１０１に格納された旧ＣＲＴＭ１００ａと同じコードで更新時だけに必要とされる。
【００３７】
ＵＳＢメモリ２９は、新システム・ファームウェア１３１、フラッシュ・ツール１３３、ＯＳ１３５および暗号化ダイジェスト１３７を含む。新システム・ファームウェア１３１は、ＢＩＯＳ＿ＲＯＭ２５に格納された旧システム・ファームウェアを書き換えるための新しいコードである。フラッシュ・ツール１３３は、ＣＰＵ１１がリセットされたときに旧ＣＲＴＭ１００ａに通常のブートではなく更新をさせるための処理をするコードである。
【００３８】
フラッシュ・ツール１３３は更新の際に、新システム・ファームウェア１３１をメイン・メモリ１５に展開する。ＯＳ１３５は、フラッシュ・ツール１３３とハードウェアとのインターフェースを提供するプログラムである。暗号化ダイジェスト１３７は、ＵＳＢメモリ２９に記憶されたフラッシュ・ツール１３３およびＯＳ１３５のハッシュ値を旧システム・ファームウェアの製造者が保有する秘密鍵で暗号化したデータである。
【００３９】
ＮＶＲＡＭ３１は、更新フラグ１５１および混在フラグ１５３を保有する。更新フラグ１５１はフラッシュ・ツール１３３が設定し、混在フラグ１５３は旧ＣＲＴＭ１００ａの更新処理コード１１５ａが設定する。更新フラグ１５１および混在フラグ１５３は、ＮＶＲＡＭ３１のライト・ロックの可能な記憶領域に設定される。ＮＶＲＡＭ３１のライト・ロックはサウス・ブリッジ２１がリセットされたときに解除されるが、更新処理コード１１５ａは、更新フラグ１５１または混在フラグ１５３を設定したあとにサウス・ブリッジ２１のＬＰＣインターフェースにライト・ロックを設定する。旧ＢＩＯＳ１１７ａは、ブート・デバイスがＵＳＢメモリ２９であると判断したときは、フラッシュ・ツール１３３に制御権を渡す際にＮＶＲＡＭ３１のライト・ロックを解除する。
【００４０】
図３は、システム・ファームウェアを更新するときのＢＩＯＳ＿ＲＯＭ２５に書き込まれているコードの変遷を示す図である。図３（Ａ）は更新前の状態を示し、図３（Ｂ）は更新途中の状態を示し、図３（Ｃ）は更新が完了した状態を示している。図４、図５はシステム・ファームウェアの更新手順を示すフローチャートである。つぎに図３〜図５に基づいて、システム・ファームウェアを更新する手順を説明する。
【００４１】
図４のブロック２０１では、ＢＩＯＳ＿ＲＯＭ２５に図３（Ａ）に示すように旧システム・ファームウェアが格納されている。旧システム・ファームウェアは、ブート・ブロック１０１に格納された旧ＣＲＴＭ１００ａ、システム・ブロック１０３に格納された旧ＢＩＯＳ１１７ａ、旧フラッシュ・ドライバ１１９ａ、および旧暗号化ダイジェスト１２１ａ、ステージング・ブロック１０５に格納された旧ＣＲＴＭ１００ａ−１で構成されている。
【００４２】
更新の理由は、ブート・ブロック１０１に格納された旧ＣＲＴＭ１００aおよびシステム・ブロック１０３に格納された旧ＢＩＯＳ１１７ａまたはいずれか一方のコードに存在する。ブロック２０３で、新システム・ファームウェア１３１を含むＵＳＢメモリ２９をＵＳＢコネクタ２７に装着してパワー・オフ状態から電源を起動するとＣＰＵ１１がリセットされて旧ＣＲＴＭ１００ａが実行される。このときサウス・ブリッジ２１もリセットされてＮＶＲＡＭ３１のライト・ロックが自動的に解除される。つぎに旧ＣＲＴＭ１００ａに続いてＢＩＯＳ１１７ａのＰＯＳＴコードが実行される。
【００４３】
ＰＯＳＴコードが実行されている間に、ユーザは特定のファンクション・キーを押下してセットアップ・コードを呼び出しＬＣＤ１９にＢＩＯＳのセットアップ画面を表示する。ユーザはセットアップ画面を通じてＵＳＢメモリ２９をブート・デバイスの最上位に設定しセットアップを終了する。ＰＯＳＴが終了すると、ブロック２０５でＢＩＯＳ１１７ａは、完全性を検証してからフラッシュ・ツール１３３およびＯＳ１３５をメイン・メモリ１５にロードする。
【００４４】
ブロック２０７でフラッシュ・ツール１３３は、新システム・ファームウェア１３１をメイン・メモリ１５に読み出し、ブロック２０９でシステム・ブロック１０３とステージング・ブロック１０５に新システム・ファームウェアを書き込む。このときのＢＩＯＳ＿ＲＯＭ２５の状態を図３（Ｂ）に示す。図３（Ｂ）では、ブート・ブロック１０１には旧ＣＲＴＭ１００ａが格納されているが、システム・ブロック１０３には新ＢＩＯＳ１１７ｂ、新フラッシュ・ドライバ１１９ｂ、新暗号化ダイジェスト１２１ｂが書き込まれ、ステージング・ブロック１０５には新ＣＲＴＭ１００ｂ−１が書き込まれている。
【００４５】
ブロック２１１でフラッシュ・ツール１３３はＮＶＲＡＭ３１に更新フラグ１５１を設定する。ブロック２１３でフラッシュ・ツール１３３は電源を再起動する。ノートＰＣ１０がパワー・オン・リセットされるとＣＰＵ１１は図５のブロック３０１で旧ＣＲＴＭ１００ａを実行してブートを開始する。このときＮＶＲＡＭ３１のライト・ロックも自動的に解除される。ブロック３０３で実行パス制御コード１１２ａは、ＮＶＲＡＭ３１の混在フラグ１５３を参照する。
【００４６】
この時点では混在フラグ１５３が設定されていないので、実行パス制御コード１１２ａは完全性検証コード１１３ａにジャンプする。ブロック３０５で完全性検証コード１１３ａはシステム・ブロック１０３とステージング・ブロック１０５に書き込まれた新システム・ファームウェア１３１の完全性を検証する。完全性検証コード１１３ａは、新システム・ファームウェア１３１のハッシュ値を計算する。
【００４７】
完全性検証コード１１３ａは、新暗号化ダイジェスト１２１ｂを生成する際にダイジェストの暗号化に使用した秘密鍵と対で生成された公開鍵で新暗号化ダイジェスト１２１ｂを復号したダイジェストと、計算した新システム・ファームウェア１３１のハッシュ値（ダイジェスト）を比較する。両者が一致したときは、新システム・ファームウェアは旧ＣＲＴＭ１００ａが保有する公開鍵を提供した製造者が製造したことになり完全性の検証が成功する。両者が一致しないときは、新システム・ファームウェアは真正な製造者が製造したあとに改竄されたか第３者が製造したことになり完全性の検証が失敗する。
【００４８】
完全性の検証が失敗したときはブロック３１１に移行し、成功したときはブロック３２１に移行する。ブロック３１１で完全性検証コード１１３ａは、ブート・ブロック１０１に対するライト・ロックを設定する。ブロック３１３で完全性検証コード１１３ａはビープ音を鳴らしてユーザに更新が失敗したことを知らせるとともにノートＰＣ１０の動作を停止する。
【００４９】
これ以降ユーザは、ＵＳＢメモリ２９に完全性のある新システム・ファームウェアを格納して再度更新作業をすることができる。あるいは、新システム・ファームウェアをＢＩＯＳ＿ＲＯＭ２５に書き込む前にシステム・ブロック１０３に書き込まれていた旧ＢＩＯＳ１１７ａ、旧フラッシュ・ドライバ１１９ａ、旧暗号化ダイジェスト１２１ａをいずれかの不揮発性メモリに退避しておき、旧システム・ファームウェアに書き戻すようにしてもよい。
【００５０】
ブロック３２１で完全性検証コード１１３ａは更新処理コード１１５ａにＣＰＵ１１の制御権を渡す。更新処理コード１１５ａはＮＶＲＡＭ３１を参照して更新フラグ１５１を確認する。この時点ではブロック２１１で更新フラグ１５１が設定されているためブロック３３１に移行する。ブロック３３１で更新処理コード１１５ａは、ＮＶＲＡＭ３１に混在フラグ１５３を設定する。ブロック３３３で更新処理コード１１５ａはブート・ブロック１０１に対するライト・ロックを設定しないでＣＰＵ１１をリセットしブロック３０１に移行する。
【００５１】
ブロック３２１からブロック３２３に移行するのは、ブロック２１１で更新フラグ１５１を設定しないで通常のブート・ルーチンを実行する場合である。ブロック３２３で更新処理コード１１５ａは、ブート・ブロック１０１に対してライト・ロックを設定してから、旧ＢＩＯＳ１１７ａのＰＯＳＴコードにジャンプし通常のブート・ルーチンを継続する。ＰＯＳＴが終了するとブロック３２５でＢＩＯＳ１１７ａは、完全性を検証したブート・ローダを読み出して通常のブート・ルーチンを実行する。
【００５２】
ブロック３３３からブロック３０１に移行したときは、サウス・ブリッジ２１はリセットされないがブロック３３３でブート・ブロック１０１のライト・ロックは解除されたままである。ブロック３０３で実行パス制御コード１１２ａはＮＶＲＡＭ３１の混在表示フラグ１５３を参照してブロック３４１に移行する。ブロック３４１で実行パス制御コード１１２ａは完全性検証コード１１３ａをスキップしてステージング・ブロック１０５に書き込まれた新ＣＲＴＭ１００ｂ−１の先頭アドレスにジャンプする。
【００５３】
なお、ブロック３３３でライト・ロックをしてからパワー・オン・リセットをする場合は、実行パス制御コード１１２ａがブート・ブロック１０１のライト・ロックをせずにブロック３４１に移行することもできる。ブロック３４３で新ＣＲＴＭ１００ｂ−１は、自身の処理が終わると、システム・ブロック１０５の新ＢＩＯＳ１１７ｂにジャンプする。なお、ＣＲＴＭ１００ｂ−１の中で、ＮＶＲＡＭ３１に混在フラグ１５３が設定されていることを確認できれば、完全性検証コード１１３ｂをスキップすることもできる。
【００５４】
新ＢＩＯＳ１１７ｂは、ＮＶＲＡＭ３１に混在フラグ１５３が設定されていることを確認すると、ＰＯＳＴ処理の間に、新フラッシュ・ドライバ１１９ｂを使用してステージング・ブロック１０５に書き込まれた新ＣＲＴＭ１００ｂ−１を、旧ＣＲＴＭ１００ａが書き込まれたブート・ブロック１０１に上書きする。このときのＢＩＯＳ＿ＲＯＭ２５の状態を図３（Ｃ）に示す。
【００５５】
図３（Ｃ）は、ブート・ブロック１０１にステージング・ブロック１０５の新ＣＲＴＭ１００ｂ−１と同じコードである新ＣＲＴＭ１００ｂが書き込まれている様子を示している。ブロック３４５で新フラッシュ・ドライバ１１９ｂはＮＶＲＡＭ３１の更新フラグ１５１と混在フラグ１５３を解除して、ブロック３４７でＣＰＵ１１をリセットしブロック３４９で新ＣＲＴＭ１００ｂを実行する。その後、ブロック３０３に戻って新システム・ファームウェア１３１による通常のブート・ルーチンが実行される。なお、ステージング・ブロック１０５の新ＣＲＴＭ１００ｂ−１は、これ以降のブートの際に実行されることはない。
【００５６】
新システム・ファームウェア１３１は、ブロック３０１からブロック３２１までの実行パスを経由してブロック３２３でブート・ブロック１０１とＮＶＲＡＭ３１にライト・ロックを設定してブロック３２５に移行する。ブロック３０１以降の手順はノートＰＣ１０の電源を起動してからＨＤＤ２３に格納されたＯＳをロードする前のマルウェアから攻撃されない安全な環境で実行される。そして旧ＣＲＴＭ１００ａが新システム・ファームウェア１３１の完全性を認定しないときは更新を停止するため、セキュアな環境で安全なシステム・ファームウェアに更新することができる。また、完全性の検証は、ブート・ブロック１０１に格納された当初の製造者の公開鍵を使って行うため、ノートＰＣ１０の製造当初からのプログラムの信頼のチェーンを維持することができる。
【００５７】
上記の手順に寄れば、図３（Ｂ）のように旧ＣＲＴＭ１００ａと新システム・ファームウェア１３１がＢＩＯＳ＿ＲＯＭ２５に併存する状態でブートを開始するときに、旧ＣＲＴＭ１００ａは混在フラグ１５３を早い段階で確認すると新ＣＲＴＭ１００ｂ−１にジャンプする。製造者は新ＣＲＴＭ１００ｂ−１と新ＢＩＯＳ１１７ｂを同一のタイミングでコーディングするため変数の定義を容易に整合させることができる。したがって、旧ＣＲＴＭ１００ａと新ＢＩＯＳ１１７ｂの変数の定義が相違しても新ＣＲＴＭ１００ｂ−１と新ＢＩＯＳ１１７ｂの変数の定義が整合していれば更新の途中でハングアップすることはない。
【００５８】
また本実施の形態では、新フラッシュ・ドライバ１１９ｂをシステム・ブロック１０３に格納して新ＣＲＴＭ１００ｂのコード量を少なくすることができるため、ＣＲＴＭの経年的な信頼性を向上させることができる。これまで、新システム・ファームウェアをＵＳＢメモリ２９から提供する方法を説明したが、新システム・ファームウェアの提供方法はこれに限定するものではない。たとえば、ネットワークを通じてＨＤＤ２３の独立したパーティションに新システム・ファームウェアをダウンロードしてＨＤＤ２３から提供するようにしてもよい。また旧ＣＲＴＭ１００ａは、新ファームウェア全体の完全性を検証したが、新ＣＲＴＭ１００ｂ−１と新ＢＩＯＳ１１７ｂの完全性を個別に検証するようにしてもよい。
【００５９】
これまで本発明について図面に示した特定の実施の形態をもって説明してきたが、本発明は図面に示した実施の形態に限定されるものではなく、本発明の効果を奏する限り、これまで知られたいかなる構成であっても採用することができることはいうまでもないことである。
【符号の説明】
【００６０】
１０１  ブート・ブロック
１０３  システム・ブロック
１０５  ステージング・ブロック
【図１】
0005465738.tif 000002
【図２】
0005465738.tif 000003
【図３】
0005465738.tif 000004
【図４】
0005465738.tif 000005
【図５】
0005465738.tif 000006
【図６】
0005465738.tif 000007