JP4647300B2 - 特定の装置または装置のクラスにおいてのみソフトウェアの更新のインストールまたは稼動を確実に行えるようにする方法及びシステム - Google Patents

Description

本発明は一般にコンピューティング装置に関し、より詳細にはコンピューティング装置の不揮発性記憶域を更新することに関する。

ＰＤＡ、最新の携帯電話、ハンドヘルドおよびポケットサイズのコンピュータなどのモバイルコンピューティング装置は、重要で一般化したユーザツールになりつつある。一般にこうした装置は、バッテリ電力の消費を抑えながらかなり便利なほど小さくなったと同時に、より強力なアプリケーションを動作させることができるようになった。

こうした装置の製造の過程中、組み込まれたオペレーティングシステム画像は、一般に単一的（ｍｏｎｏｌｉｔｈｉｃ）な画像ファイルに組み込まれ、ＮＡＮＤまたはＮＯＲフラッシュメモリ、ハードディスクなど、各装置の不揮発性記憶域に格納される。その結果、こうした装置の更新は、折に触れて必要であり、または望ましい。装置の永続的なアプリケーション画像の更新は、アプリケーションがユーザによりアクセスできるファイルシステムに格納され、ユーザデータと混合される、一般にアプリケーションがコンピューティング装置にインストールされる方法とは異なることに留意されたい。

しかし、一部のメーカーは、装置ソフトウェアの更新へのアクセス、および装置が出荷時に備えていた最初の画像へのアクセスを制御することができることを望む。他にも理由はあるが特に、あるメーカーは別のメーカーの更新画像をその装置にインストールさせたくないことがこの理由として挙げられる。また、他のメーカーは、いくつかの画像の更新または新しい画像の代金を支払うことをいとわない顧客に支払いを請求できることを望み、別のメーカーは望まない。また別のメーカーは、新しい画像は新しいアプリケーションまたは特徴を含み得るため、いくつかの画像の更新またはこうした新しい画像の代金を支払うことをいとわない顧客に支払いを請求できることを望む。「更新」は、完全なアプリケーションまたは新しい特徴とすることができることに留意されたい。

最初の画像および／または更新画像へのアクセスを制御し、しかし最初の画像または更新に関するメーカーの特定の状況の組に応じて実施の可否が決まる柔軟な方法で制御する機構が必要である。

簡単に言えば、本発明は、どの装置が画像をインストールし、または動作させることができるかをメーカー、または他の最初の画像または更新画像のプロバイダが制御するシステムおよび方法を対象にしている。このために、本発明は、画像キーイング機構（ｉｍａｇｅ ｋｅｙｉｎｇ ｍｅｃｈａｎｉｓｍ）を提供し、それによって、最初の構成要素または更新構成要素、すなわち本明細書ではパッケージとも呼ぶキー付きの画像サブ構成要素をメーカーまたは他の更新プロバイダが指定した以外の装置にインストールしようと試みた場合、そのインストールは失敗する。さらに、例えばハードウェアＪＴＡＧプローブなど、他の何らかの手段を介してキー付き画像が装置に適用された場合でさえ、ソフトウェアは、無効な装置上では動作しない。このために、装置は、適切なキーの副署名（ｃｏｕｎｔｅｒｓｉｇｎａｔｕｒｅ）無しでは起動（ｂｏｏｔ）しない。画像のキーイングは、最初の製造画像および更新可能なパッケージに適用されることに留意されたい。

一実装形態では、パッケージは、装置に関連付けられている汎用一意識別子（ＵＵＩＤ）およびパッケージに基づいてキー付けされる。ＵＵＩＤは、ＵＵＩＤが装置または装置のクラスに対応するかどうかに応じて、パッケージに単一の装置または装置のクラスのキーを付けることができるようにする。ＵＵＩＤを使用すると、キーイングプロセスは、装置のＵＵＩＤを画像に確実に関連付けることができ、したがってインストーラ検査器（ｉｎｓｔａｌｌｅｒ ｖｅｒｉｆｉｅｒ）および／または起動時検査器（ｂｏｏｔ−ｔｉｍｅ ｖｅｒｉｆｉｅｒ）は、ＵＵＩＤに基づいてキーイングがその装置に適していることを確認することができる。次いでインストーラ検査器および／または起動時検査器は、装置がその画像に対して承認されているかどうかに応じて、画像の更新／起動を許可または拒否する。

パッケージにキーを付けるには、装置のＵＵＩＤが画像を有するサーバに伝達され、次いでサーバはハッシュアルゴリズムをＵＵＩＤおよびパッケージ関連のデータに適用し、その結果に署名する。署名は、画像の既知の場所に格納され、キー付きの画像が装置に提供される。

キー付きの画像がインストール時または起動時に確認されるように、インストールコードまたは起動前コードは、キーが付けられていない任意の画像を検出し、必要に応じてインストールまたは装置の起動を中止するように設計されている。これは、同じエンコードアルゴリズムを画像、およびプロバイダやメーカーなどのサーバで画像にキーを付けるために使用されたＵＵＩＤに適用することによって達成される。

一実装形態では、画像のキーイングは任意選択であり、したがってソフトウェアベンダーおよび／またはメーカーが画像にキーをつけるかどうかを決定することができる。任意選択でキーが付けられたシステムを有するために、システムは、特定の画像または画像の一部にキーを付ける要求を表す機構を有する。キー付きの画像についての要求は、同じパッケージ内からのものでも、または同じ装置の異なるパッケージ内からのものでもよい。パッケージのプロバイダはパッケージにキーを付けることができ、またはメーカーは、そのパッケージのプロバイダでない場合でさえ、パッケージにキーを付けることができることに留意されたい。

一実装形態で、ハッシュに使用されるパッケージデータは、パッケージのインストール後に装置上で維持されるパッケージの説明に対応する。マニフェスト（ｍａｎｉｆｅｓｔ）ファイルは、パッケージ識別子、バージョン番号、およびパッケージ内のファイルのリストを含むことによってそのパッケージの中身をシステムに説明するためのパッケージの付属物であり、ハッシュのためのパッケージ関連のデータを提供する。

パッケージにキーが付けられ、パッケージが装置で取得されると、装置は、インストールされるパッケージにキーを付ける要求をパッケージが有しているかどうかを決定する。要求は、パッケージ内からのもの、または別の、前にインストールされたパッケージからの要求である場合がある。キーイング要求がある場合、ハッシュを計算するアルゴリズムは、パッケージの中身および装置ＵＵＩＤに再適用され、その結果がサーバ側で決定され、パッケージに格納されている結果と比較される。その結果が一致した場合、キーの署名が有効であることがわかり、インストールが可能となる。

例えばハードウェアＪＴＡＧプローブの使用による、またはバスを介したフラッシュ内のデータの物理的操作によるなど、標準の画像更新機構以外の手段を介して画像が決して悪意をもって更新されないようにするために、起動時実施機構を使用することもできる。起動時チェックプロセスは、キーが無効である、または見当たらないことを見つけると、起動プロセスを中止する。

他の利点は、次の詳細な説明を図面と併せ読めば明らかになる。

（オペレーティング環境の例）
図１は、プロセッサ１２２、メモリ１２４、ディスプレイ１２６、および物理キーボードまたは仮想キーボードである、またはその両方を表し得るキーボード１２８を含む、こうしたハンドヘルドコンピューティング装置１２０の機能的な構成要素を示している。マイクロフォン１２９は、音声入力を受信するためにある。メモリ１２４は、一般にＲＡＭなどの揮発性メモリ、およびＲＯＭ、ＰＣＭＣＩＡカードなどの不揮発性メモリを含む。Ｍｉｃｒｏｓｏｆｔ社のＷｉｎｄｏｗ（登録商標）オペレーティングシステムまたは他のオペレーティングシステムなど、オペレーティングシステム１３０は、メモリ１２４に存在し、プロセッサ１２２上で実行される。

１つまたは複数のアプリケーションプログラム１３２は、メモリ１２４にロードされ、オペレーティングシステム１３０上で動作する。アプリケーションの例には、電子メールプログラム、スケジューリングプログラム、ＰＩＭ（個人情報管理）プログラム、文書処理プログラム、スプレッドシートプログラム、インターネットブラウザプログラムなどがある。ハンドヘルドパーソナルコンピュータ１２０は、プロセッサ１２２上で実行されるメモリ１２４にロードされた通知マネージャ１３４を含んでいてもよい。通知マネージャ１３４は、例えばアプリケーションプログラム１３２からの通知要求を処理する。また、後述するように、ハンドヘルドパーソナルコンピュータ１２０は、ハードウェアドライバなどのネットワーキングソフトウェア１３６、および電話をかけることも含めて、ハンドヘルドパーソナルコンピュータ１２０をネットワークに接続するのに適した無線およびアンテナなどのネットワーク構成要素１３８を含む。

ハンドヘルドパーソナルコンピュータ１２０は、１つまたは複数のバッテリとして実装される電源１４０を有する。電源１４０は、ＡＣアダプタや動力付きドッキングクレードル（ｐｏｗｅｒｅｄ ｄｏｃｋｉｎｇ ｃｒａｄｌｅ）など、内蔵バッテリに優先する、またはそれを再充電する外部電源をさらに含むことができる。

図１に示されるハンドヘルドパーソナルコンピュータ１２０の例は、１つまたは複数の発光ダイオード（ＬＥＤ）１４２および音声生成器１４４の３種類の外部通知機構を備えるように示されている。これらの装置は、電源１４０に直接結合することができ、したがって稼動されると、ハンドヘルドパーソナルコンピュータプロセッサ１２２および他の構成要素がバッテリ電源を保持するためにシャットダウンする場合でさえ、通知機構によって指示されたある期間の間、オンのままである。ＬＥＤ１４２は、ユーザが行動を起こすまで無期限にオンのままであることが好ましい。最新バージョンの音声生成器１４４は、今日のハンドヘルドパーソナルコンピュータバッテリにあまりにたくさんの電力を使いすぎるため、システムの残りがオフになったとき、または稼動後のある有限の期間にオフになるよう構成されていることに留意されたい。

基本的なハンドヘルドパーソナルコンピュータを示しているが、実質的には、携帯電話など、データ通信を受信し、プログラムで使用するためにデータを何らかの方法で処理することができる任意の装置は、本発明の実施の目的上同等であることに留意されたい。

（装置固有の更新）
本発明は一般に、組み込み型装置の不揮発性メモリ、例えばフラッシュメモリに最初のソフトウェアまたはソフトウェアの更新が書き込まれるものを含めて、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）ＣＥベースの装置などの小さいモバイルコンピューティング装置に格納されるソフトウェアをインストールし、かつ／または更新することを対象としている。それにもかかわらず、本発明は、総体的にコンピューティングにとっての利点を提供し、したがって他のコンピューティング装置、および様々なタイプのメモリおよび／またはハードディスクドライブなど他のタイプの記憶媒体を含めて、他のタイプの記憶域に適用することができる。簡潔にするために、「フラッシュ」という用語は、以下装置の更新可能な記憶域を参照して使用されるが、任意の記憶機構が同等であることを理解されたい。さらに「画像」という用語は一般に、既存の画像の一部しか更新されない場合でさえ、最初のソフトウェアインストール画像、および画像へのその後のソフトウェアの更新の概念を含む。

ソフトウェア更新は、ある組のソフトウェアへの完全な更新、および／または前の更新または画像に対する変更のみを含み得る自己完結型の安全なエンティティである。ソフトウェア更新は、拡張可能なコードおよびデータを含むことができる。本発明のキーイング関連プロセスおよび機構を説明するために、最初の製造画像、および製品が販売された後でフィールドにインストールされた更新可能な画像構成要素は、同様に扱われ、以下、総称的に「画像エンティティ」と呼ばれる。画像エンティティは、画像全体については画像、または画像のサブ構成要素については画像サブ構成要素／パッケージとすることができる。

本発明の態様によれば、インストールが従来の手段を介して試行されるとき、キー付きのソフトウェア画像が許可されていない装置にインストールされるのを防ぐ画像キーイング方法およびシステムが提供される。さらに、この方法およびシステムは、例えばハードウェアのハッキングを介するなど、他の何らかのやり方でインストールされたキー付きソフトウェアが許可されていない装置で動作するのを防ぐ。本発明は、最初の製造画像および更新可能なパッケージに適用される。容易に理解できるように、キーイングは、装置のメーカー／ＯＥＭ／ソフトウェアベンダーが、最初の製造画像および／または更新可能なパッケージをインストールすること、または動作させることができる装置のアレイを厳重に制御できるようにする。

図２に概略が示されているように、ある画像内の．ＣＡＢ圧縮済みファイルなどのパッケージ２０２は、パッケージ２０２が装置に有効な例えば更新などの画像であることを確認するために使用される少なくとも１つの署名を含む署名アレイ２０４を有する。第２の署名、または副署名は、存在する場合、キー２０６であり、これは、特定の装置にその更新を関連付けるために使用される。この副署名を一般に、本明細書では「キー」と呼ぶ。例えばＯＥＭなど装置に関するそのキー情報を有しているパッケージおよびエンティティを最初に作成したプロバイダは、パッケージにキーを付けることができる。キー２０６は、後述するように、パッケージおよび装置ＩＤに関する情報を使用して構築される。

上述したように、キーイング処理は、画像にそのためのキーが付けられる装置を一意に識別する能力に依存する。このために、各装置は、汎用一意識別子（ＵＵＩＤ）２０８を提供する必要がある。適切に機能するように、このＵＵＩＤは、他の任意の機構から画像をそこにインストールすることができ、しかしそこで設定することはできない装置の組にわたって、ハードウェア生成され、永続的な、保証された一意のものとするべきである。さらに装置は、要求されるといつでも、要求されたときにＵＵＩＤを取得し、提供する責任を負う装置上のシステムソフトウェアを介して同じＵＵＩＤ値を戻すことができる必要がある。装置は一般に、すでに装置ＩＤなどのＵＵＩＤを有しているが、セキュリティ上の理由で、装置ＩＤが許可されていない構成要素からアクセスできないようにすることが望ましいことに留意されたい。

理解できるように、ＵＵＩＤ２０８は、装置ごとにわずか１つのパッケージという粒度に対応するキーをパッケージに付けることができるようにする。しかし、必要に応じて、ＵＵＩＤを装置のクラスに使用することができる。例えばメーカーは、単一の顧客についてこうした多くの装置を構築することができ、ＵＵＩＤを、１つの装置ではなく、その顧客に販売された装置のクラスに適用することができる。例えばこれは、装置のクラスにＵＵＩＤの最上位ビットを共有させ、最下位ビットはそのクラス内の装置の識別に使用することによって達成することができる。次いで、各ＵＵＩＤの最上位ビットのみを、キーイングのためにクラスＵＵＩＤとして使用される。更新が許可されるかどうかを決定するときに、チェック機構は、装置ＵＵＩＤおよびクラスＵＵＩＤを使用して更新を許可するかどうかを決定することができることに留意されたい。その結果、メーカーは、キー付きの更新を個々に要求するよう各装置に要求するのではなく、単一のキー付き更新を同じクラスの複数の装置にインストールすることを許可することができる。本明細書では簡潔にするために、ＵＵＩＤを、主に単一の装置に関して説明するが、概念は、複数の装置のクラス間でＵＵＩＤを共有することに等しいことを理解されたい。

こうしたＵＵＩＤを使用すると、キーイングプロセスは、装置のＵＵＩＤを画像に確実に関連付けることができ、したがってインストーラ検査器および／または起動時検査器は、キーイングがその装置のＵＵＩＤに適していることを確認することができる。次いでインストーラおよび／または起動時検査器は、信頼の連鎖に関して後述するように、起動前検証コードがハードウェアにとって安全であることを条件に、装置がその画像について許可されているかどうかに応じて、画像の更新／起動を許可または拒否する。

キー付きの画像がインストール時または起動時に確認されるように、インストールコード２１０、または起動前コード２１２は、キーが付けられていない任意の画像を検出し、必要に応じてインストールまたは装置の起動を中止するように設計されている。これは、同じエンコードアルゴリズムを画像、および画像のプロバイダによって使用されたＵＵＩＤに適用し、その結果が例えばプロバイダのサーバによって画像に格納されているキーと一致することを確認することによって達成される。このように、キーが付けられていない画像、または別の装置のキーが付けられた画像が検出されると、画像は最初にインストールできない、またはインストールプロセスが回避され、ハードウェアＪＴＡＧプローブなどの別の機構を使用して画像をフラッシュする場合、画像は動作しない。

一実装形態で、画像のキーイングは任意選択であり、したがってソフトウェアベンダーおよび／またはメーカーが画像にキーをつけるかどうかを決定することができる。任意選択でキーが付けられたシステムを有するために、システムは、特定の画像または画像の一部にキーを付ける要求を表す機構を有する。キー付きの画像についての要求は、同じ画像内からのものでも、または同じ装置の異なる画像サブ構成要素内からのものでもよい。例えばこのことは、メーカーがその画像のプロバイダではない場合でさえ、メーカーが画像にキーを付けることができるようにすることに留意されたい。

キーイング署名は、画像の所有者、またはキーイング要求を発行したエンティティによって署名することができる。この重複は、装置上のソフトウェアを生成している別のエンティティは制御をしていない画像のキーを確実に要求することができ、また画像の所有者はその画像の更新制御を決して失わないようにする。さらに、容易に理解できるように、ベンダーは、内的に、ビルドシステムにおいて作成者およびＯＥＭとしての役割を果たすことができる。したがって例えば、画像がビルドラボを離れる前に、ビルドラボは、ＯＥＭとして働き、ビルドにキーを付ける。次いでパッケージは、パッケージにそのためのキーが付けられた装置に結合され、別の装置にフラッシュすることができない。他にも利点はあるが、このことは日々のビルドの漏洩を防ぐ。

例えば要求があり次第適切にキーが付けられた画像を提供するために、キーを付けるべき画像は、まずサーバ２２０に格納される。装置のＵＵＩＤは、安全な機構を介してサーバに伝達され、次いで画像にキーを付けるために使用される。例えば装置の所有者は、更新を要求したとき、ＵＵＩＤを確実に送信することができる。または装置のメーカーは、更新を受信することを許可されたＵＵＩＤの内部データベースを維持することができる。機密データへの他の制御されたアクセスと同様、サーバ２２０への認証されたアクセス、ＵＵＩＤ交換のセキュリティ、およびサーバ側の処理は、キーイングプロセスが安全であり、交換を妨害することができないことを確実にするための必要条件である。

サーバ２２０が装置ＵＵＩＤを取得し、画像にアクセスできるようになると、一実装形態では、サーバは、ハッシュアルゴリズムを両方のエンティティに適用して、例えば連結を介して単一のエンティティを取得し、これに署名されるようにすることができる。これは本質的に、次の式として表すことができる。

Sign_key ( Hash ( Hash(pkg data) | Hash (device ID) ) )
ハッシュ結果から署名が生成されると、署名は、画像内の既知の場所に格納され、次いでキー付きの画像が装置にダウンロードされる用意がなされる。

ハッシュに使用されるパッケージデータは、パッケージの中身の実際のハッシュを基にすることができるが、後述するように、パッケージは、インストール後の装置によって保持されず、したがってこれは問題を引き起こし、キーイング機構が妨害を受けやすくなる。パッケージデータとして中身を使用する代わりに、インストール後に維持されるパッケージの説明は、ハッシュするのにより望ましいエンティティであり、一実装形態では、パッケージの中身の代わりに使用される。より詳細には、それは、パッケージの付属物であり、そのパッケージの中身をシステムに説明するマニフェストファイル２３０とともに、画像をパッケージ内に準備することができる。マニフェストファイル２３０は、パッケージ識別子、バージョン番号、およびパッケージ内のファイルのリストを含む。さらに、マニフェストファイル２３０は、図２のインストール済みのマニフェストファイル２３０ｉによって表されるように、パッケージのインストール後、装置上に留まる。これは、パッケージ自体がインストール後に破棄された場合でさえ、起動時にそのハッシュを取得することができることを意味する。その結果、マニフェストファイル２３０は、パッケージデータとしての上記式においてハッシュして、パッケージを表すのに優れたエンティティとして働き、次いでパッケージは、上述したように、結果が署名された状態で装置ＵＵＩＤのハッシュと組み合わされる。

キーが付けられると、パッケージは装置にダウンロードされる。装置は、インストールされるパッケージにキーを付ける要求をパッケージが有しているかどうかを決定する。要求は、パッケージ内からのもの、または別の、前にインストールされたパッケージからの要求である場合がある。また、同時にインストールされる他の任意のパッケージからの要求もあり得る。キーイング要求がある場合、ハッシュを計算する同じアルゴリズムは、画像および装置ＵＵＩＤに再適用され、その結果がサーバ側で決定され、パッケージに格納されている結果と比較される。その結果が一致した場合、キーの署名が有効であることがわかる。画像の従属関係の要件が満たされた、画像が完全で適切であるなど、他の画像の検証チェックが成功したと仮定すると、画像は装置にインストールされる。

インストール時にパッケージに適切にキーが付けられたことを確認する１つの利点は、インストールまたは更新をキャンセルすることができることである。それをインストールする前に更新をキャンセルすると、ユーザには起動可能な装置が残る。当然、装置は、ユーザがインストールしようとしていた更新は有していないが、少なくともその前の状態に起動する。容易に理解できるように、起動時のみに適したキーイングをチェックすることによってのみ保護を行うことができるとしたら、ユーザが誤った更新をインストールするなどのシナリオは、結果的にそれが再フラッシュされない限り起動しない装置がユーザに残されることになる。

第２の実施機構を使用することもできる。より詳細には、例えばハードウェアＪＴＡＧプローブの使用による、またはバスを介したフラッシュ内のデータの物理的操作によるなど、標準の画像更新機構以外の手段を介して画像が決して悪意をもって更新されないようにするために、起動プロセス中に画像のキーイングをチェックするプロセスを適用することもできる。例えば、キー付きのパッケージに対応する各プログラムが起動する前など、確認をどこかで別のときに行うことが可能であるが、簡潔にするために、本明細書では、実施を、起動時の確認に関して説明することに留意されたい。

起動時チェックプロセスは、例えばブートローダ内などにある起動前機関（ｐｒｅ−ｂｏｏｔ ａｕｔｈｏｒｉｔｙ）が、インストーラ検査器によって行われるように、画像のキーを検証し、キーが無効である、または見当たらないことを見つけると、起動プロセスを中止するように設計されることを要求する。ハードウェアレベルの攻撃から保護するために、起動前機関２１２は、置き換えることができない／無効にすることができないように、例えば読み取り専用ＲＯＭなどでハードウェア保護する必要がある。というのは、ＲＯＭ内のブートローダは、装置へのハードウェアアクセスでハッカーによって置き換えることができるからである。これは、後述する信頼の連鎖の説明の一部であり、例えば携帯電話用に設計されているものと同様に、ＣＰＵの起動の前にブートローダへの署名を確認する安全なブート機能を備えるＣＰＵを使用して達成することができる。信頼の連鎖は、ＣＰＵベースの安全な起動が、オペレーティングシステム下で動作しているアプリケーションを通過するようにする。

図２は、メモリレイアウト２４０の例を示しており、コード２３２ｉを含むあるパッケージバージョンＶ１の中身、マニフェスト２３０ｉ、および場合によっては後述するキー情報ファイル２３４ｉがＩｍａｇｅＦＳと呼ばれるシステムパーティション２３６にインストールされている。留意すべきことは、この実装形態の例では、パッケージを、ＮＫ領域またはパーティションとして知られる別のカーネルパーティションにもインストールできる。

図２に示すように、パッケージ２０２などの各パッケージは、キーを付けることができる、つまり関連の副署名２０６を有することができる。上述したように、副署名は、装置ＩＤのハッシュおよびパッケージ関連のデータのハッシュ、例えばパッケージ情報を含むマニフェストファイルである。その結果、パッケージが装置に結合されるだけではなく、同じ装置上でさえ、そのパッケージからのキーを別のパッケージに使用することができない。

キーイングの保護を実施するために、インストール時または起動時、装置は、サーバ２２０と同様に、パッケージマニフェストファイル２３０ｉをハッシュし、そのハッシュをＵＵＩＤ２０８のハッシュと連結する。結果は、例えばパブリックキーで署名されるなど、ハッシュされ、副署名として使用される。

一実装形態では、副署名は、ＰＫＣＳ７署名である。署名の証明書連鎖を構築し、検証するのに必要な証明書は、ＰＫＣＳ＃７データ構造内にある。キー署名が署名される必要がある証明書は、キーヤーがパッケージの所有者である場合はパッケージのマニフェストに、またはキーヤーがキーイングを要求しているエンティティである場合はキー情報ファイルに格納することができる。

キー情報ファイル２３４は、これが正しいファイルタイプであることを確認するために、このファイルタイプのみに使用されるマジックナンバーを含むバイナリファイル形式である。キー情報ファイルは、構造のサイズ、要求の数、パブリックキーアレイへのインデックス、および証明書の数も含む。一実装形態では、キーイング署名を見つけるためにアレイ内のすべてのキーが走査され、キーイング署名は、認証されていない属性を介して識別することもできる。

キー情報ファイルは、装置上の任意のパッケージにキーを付ける要求のリストを含むシステムファイルである。パッケージを装置にインストールするとき、画像内のキー情報ファイルが列挙される。これは、新しいパッケージ内のキー情報ファイル２３４ｉ、キー情報ファイル２３８ｉなど前にインストールされた１つまたは複数の他のパッケージに対応する現在の画像内の任意のキー情報ファイル、およびインストールされるパッケージの組内の他のパッケージからの任意のキー要求を含む。現在の画像内の任意のキー情報ファイル、または新しい更新パッケージ要求のキー情報ファイルがパッケージにキーを付けることを要求している場合、そのパッケージにキーを付ける必要がある。結果として、パッケージを提供したソフトウェアベンダーがパッケージにキーを付けることを要求しない場合でも、メーカーはパッケージにキーを付けることを要求することができる。キー情報ファイルは、パッケージにキーを付けないことを要求するのではなく、パッケージにキーを付けることを要求することができるだけなので、競合するキーイング要求はあり得ないことに留意されたい。例えばベンダーは、特定のパッケージに決してキーを付けないことを要求するキー情報ファイルを含むことができない。したがってパッケージは、最初にパッケージを作成したエンティティ、または装置のキー情報を有しているエンティティによってのみキーを付けることができる。

図２に示すように、署名は、一実装形態においてｗｉｎｃｅｒｔＡｒｒｙという名前の証明書２０４のアレイ内の署名済みファイルに保持される。パッケージに装置のキーを付けるために使用される副署名２０６は、保護された属性付きの署名を含む。この保護された属性は、新しい認証済みの属性である。パッケージが有効な署名を含んでいるかどうかを決定するために、証明書アレイ２０４が列挙され、アレイ内の各要素は、認証済み属性２０６があるかどうかチェックされる。この属性が見つかった場合、これはキーイング署名である。

各署名を検証するために、証明書アレイ内の副署名２０６は、例えば２３４や２３８ｉなど、パッケージ２０２にキーを付けるべきであると伝えるキー情報ファイルからの証明書と比較される。パブリックキーファイルは、パッケージ内のパッケージマニフェストにあり、そうでない場合はパッケージ自体に添付されている可能性がある。署名のいずれかが検証され、動作する場合、パッケージ２０２は、装置に適用される。署名がいずれも検証されない場合、適したユーザインターフェースダイアログなどを介してユーザにエラーが通知される。

図３は、パッケージを装置にインストールするとき、キーイング情報の確認のために行われ得る様々なステップ例を示しており、ステップ３００で始まり、キー情報ファイルが列挙される。ステップ３０２は、このパッケージについてキーイングを求める任意のキー情報ファイル要求があるかどうかを評価する。ない場合、ステップ３０４で示すように追加のキーイング作業は不要であり、プロセスは終了する。そうでない場合、キーイングが要求され、証明書アレイ内の署名の組がステップ３０６および３０８を介して検証される。ステップ３１０で、組が任意の有効な署名を含んでいない場合、パッケージの検証は、有効なキーを有していないため、ステップ３１２で失敗する。

例えば圧縮済みＣＡＢファイルなどのパッケージはインストール後は保持されないため、マニフェストファイルではなくパッケージがハッシュ計算で使用される代替の一実装形態では、署名およびパッケージのハッシュは、インストール後に保持される必要があることに留意されたい。したがって、任意選択のステップ３１４で示すように、この代替の実装形態では、有効な署名が新しいパッケージから抽出され、それをシステム上のファイルに書き込むことによって格納される。この代替の実装形態では、特定のパッケージのキーイング情報を確認し、パッケージ更新を実行した後、更新アプリケーションは、パッケージのハッシュをプレーンテキストでパッケージのインストール時の他のハッシュと同じファイルに書き込むことができる。例えば［ＧＵＩＤ］．ｐｋｉなど、こうしたパッケージキーイング情報ファイルは、パッケージハッシュがもはやアクセス可能でない場合、起動時確認に必要である。

キー情報ファイルは、更新プロセスにおいて通常のファイルとして働く。更新内のキー情報ファイルまたはその欠乏は、パッケージに元々あったものを何でも置き換える。パッケージが元々キーを付けられておらず、パッケージ作成者またはＯＥＭがパッケージにキーを付けることを決定した場合、パッケージは、パッケージにキーを付けることを要求しているキー情報ファイルを含むパッケージで更新することができる。また、パッケージにキーを付けることを宣言するキー情報ファイルを含むパッケージをキー情報ファイルを含まないパッケージで更新することもできる。これは、パッケージがもはやキーを付けられることを要求していないことを意味する。しかしこれは、特定のパッケージにキーを付けることを要求する、他の何らかのパッケージに対応する他のキー情報ファイルが装置にないことを保証しているのではないことに留意されたい。

本発明の一態様によれば、上述したように、キーイングを要求する各パッケージのキーイング情報は、図４のフロー図に概略を示すように、起動時にすべてのキー情報ファイルとも照合される。一実装形態では、ステップ４００の任意のキー情報ファイルがステップ４０２および４０８のキーイングが必要であると示したパッケージごとに、ステップ４０４の同じ評価が行われる。つまりマニフェストファイルのハッシュおよびＵＵＩＤが取得され、署名され、キーと比較される。比較が任意のパッケージについて有効ではない場合、４０６で装置は起動しないか、そうでない場合４１０で装置は起動する。

装置マニフェストファイルがハッシュ計算に使用されない代替の一実装形態では、インストール時、署名が新しいパッケージから抽出され、ファイルとしてファイルシステムに入れられたことを思い出されたい。この場合、署名に加えてパッケージのハッシュが格納される。パッケージデータがマニフェストファイルのハッシュである場合でさえ、起動時の確認のために署名を格納する必要がある。パッケージにキーを付ける必要があるかどうかを決定するために、起動時にキー情報ファイルが走査され、次いで抽出された署名を含む対応するファイルが走査され、開かれ、署名の内容が確認される。

キー情報ファイルは、署名も含んでいることに留意されたい。すべてが有効である場合のみ、装置が起動する。さらに、ＲＡＭシャドウイング問題を扱うために、キー情報ファイルおよび署名が起動時に開かれ、ファイル属性がチェックされることに留意されたい。このファイルがＲＯＭ内にない場合、またはＩｍａｇｅＦＳ内のシステムファイルではない場合、起動確認機構は、ファイルの削除を試みる。システムファイルではない、またはＲＯＭ内にはないようなファイルを削除できない場合、装置は起動しない。

（信頼の連鎖）
上述したように、真のセキュリティのために、起動前検証コードは、ハードウェアにとって安全である必要があり、そうでない場合、例えば、ハードウェアハッカーは、検証コードを上書きすることができることになる。こうした真のセキュリティは、ＣＰＵがセキュリティで保護された起動機能を有していることに依存する。というのは、ＣＰＵが安全に起動する場合、信頼されたコードを開始することができる。その後、信頼の連鎖の概念は、推移性を前提として、他の構成要素にこうした確認機構を提供することができる。つまり、ユーザが構成要素Ａを信頼し、構成要素Ａが構成要素Ｂを信頼し、構成要素Ｂが構成要素Ｃを信頼した場合、ユーザは、構成要素Ｃを信頼することができる。したがって、本発明の構成要素では、最初のプログラムローダを信頼することができることをユーザがわかっており、最初のプログラムローダは、マスタブートレコードおよびＮＫ領域が信頼されることを確認することができ、例えばその中のセキュリティローダなど、ＮＫ領域は、他の構成要素が信頼されることを確認した場合、ユーザはこれらの構成要素を信頼することができる。

したがって、本発明では、信頼の連鎖は、図５のブロック５０２に示した最初のプログラムローダの保護に依存する。このために、ＣＰＵは、最初のプログラムローダの署名を検証することができる安全な起動機能を有することができる。署名が有効でない場合、装置は起動しない。これは、ＣＰＵの安全な起動機能に依存する。

ＣＰＵがそれによって最初のプログラムローダの署名を確認する正確な機能は、ＣＰＵに依存し、メーカーによって異なるが、一般にリセットベクトルでのコードが正しい署名を含んでいない場合、ＣＰＵは起動しない。

図５に示すように、最初のプログラムローダ５０２は、画像更新内の署名付きの構成要素の残り、つまりマスタブートレコード５０６、更新ローダコード５０８、およびＮＫコード５１０に署名することが許可されたルート証明書のリスト５０４を含む。このリスト内のルート証明書は信頼することができる。というのは、これらは、最初のプログラムローダ画像５０２に含まれており、ＣＰＵ自体によって確認されたからである。

ルート証明書リスト５０４は、ＮＫパーティション内のベンダー提供のパッケージ内のファイル上の署名を確認するためのオペレーティングシステムベンダー証明書、およびマスタブートレコード、更新ローダコード、および予備の領域上の署名を確認するための少なくとも１つのＯＥＭ提供の証明書を含んでいなければならない。マスタブートレコード５０６を保護するために、最初のプログラムローダ５０２は、パブリックキーで署名されたマスタブートレコード５０６全体のハッシュを使用してマスタブートレコード５０６上の署名を検証する。

マスタブートレコード５０６は、セキュリティディレクトリも含むことができる。セキュリティディレクトリ５０６は、図５のマスタブートレコード５０６内に組み込まれている、そうでない場合はどこかにある新しい構造である。セキュリティディレクトリ５０６は、内部署名されていない既存のパーティションの検証に使用される署名のアレイを含む。セキュリティディレクトリ内の署名は、予備領域に署名するために使用される。

更新ローダ５０８を保護するために、最初のプログラムローダ５０２は、本質的にＭＢＲが検証されたのと同じ方法で、パブリックキーで署名されたＵＬ全体のハッシュを使用して更新ローダ５０８上の署名を検証する。更新ローダ５０８の検証の別の選択肢は、ＮＫパーティションについて後述するものなど、内部署名によるものであり、例えば更新ローダ５０８は、１つのカタログファイルを含むことができ、カタログファイルは、ＵＬ更新ローダ５０８内のすべてのファイルを含む。ファイルごとにハッシュが計算され、カタログファイル内のハッシュと照合される。カタログファイル内の署名は、ルートが最初のプログラムローダ５０２内にある証明書連鎖によって確認される。

ＮＫパーティションを保護するために、ＮＫパーティションは、制御が最初のプログラムローダ５０２からＮＫパーティション内のカーネルに転送される前に、最初のプログラムローダ５０２によって検証される。

上述したように、ＮＫパーティションは、パッケージで構成され、各パッケージのマニフェストファイルは、ファイル名およびハッシュの署名済みリストを含む単一のカタログファイルへのポインタを含んでいる。ＮＫパーティションを保護するために、各マニフェストファイルおよびカタログが列挙される。カタログで指定されたファイルごとにハッシュが計算され、カタログ内のハッシュを確認するために使用される。カタログファイル内の署名は、証明書連鎖によって確認され、署名は、証明書連鎖を支持するＰＫＣＳ＃７署名ブロックであるものとする。ルート証明書は、最初のプログラムローダのルート証明書リスト５０４になければならない。次いでＮＫパーティション内のファイルが列挙され、保護プロセスは、ファイルがカタログによってカバーされていることを検証する。署名のうちのいずれも一致していない場合、またはカタログのうちの１つに列挙されていない任意のファイルがある場合、パーティションの署名チェックは失敗し、装置は起動しない。

制御が最初のプログラムローダ５０２からカーネルに転送されると、システムは、カーネルの制御下で動作している。これ以降は、ＩＭＧＦＳパーティション５１２を保護するために、信頼の連鎖ベースの保護プロセスは、安全なローダの一部として行われる署名検証、および安全なローダに関連付けられており、システム内のモジュールの大部分を構成するマルチストリームｒｅｌｍｅｒｇｅモジュール（ｍｕｌｔｉ−ｓｔｒｅａｍ ｒｅｌｍｅｒｇｅ ｍｏｄｕｌｅ）に対応する署名形式の確認も含めて署名検証を行う証拠生成器（ｅｖｉｄｅｎｃｅ ｇｅｎｅｒａｔｏｒ）に依存する。

装置上で定義される他の任意のパーティションは、無線および他の予備のパーティションを含めて、これらのセキュリティチェックに従う必要がある。より詳細には、テストコード、無線スタックなど、ＯＥＭ固有のパーティションを有するＯＥＭは、これらのパーティションを署名によって検証する必要がある。予備のセクションの署名は、セキュリティディレクトリ内にあり、ＰＫＣＳ＃７署名ブロックであり、最初のプログラムローダのルート証明書リスト５０４内のルートまで連鎖するものとする。

（結論）
上記の詳細な説明からわかるように、キーイングを使用して最初の画像および／または更新画像へのアクセスを制御する機構が提供される。この機構は、柔軟性があり、インストール、および起動時実施に適用することによって、容易に打ち破ることができない。

本発明は、様々な変更および代替の構成の余地はあるが、そのいくつかの実施形態の例を図に示しており、上記で詳述している。しかし、本発明を開示された特定の形に限定する意図はなく、逆に本発明は、本発明の意図および範囲内に含まれるすべての変更、代替構成、および均等物をカバーするものとする。

本発明を組み込むことができるコンピュータシステムを表す概略ブロック図である。 本発明の一態様による、特定の装置にインストールし、そこで動作するようにキーが付けられたパッケージを表すブロック図である。 本発明の一態様による、その装置に適切なキーに基づいて装置にキー付きのパッケージをインストールするかどうかを決定するロジックを表すフロー図である。 本発明の一態様による、その装置が１つまたは複数のキー付きパッケージを有しているかどうかに基づいて装置を起動するかどうかを決定するロジックを表すフロー図である。 本発明の一態様による信頼の連鎖の概念を表すブロック図である。

符号の説明

１２２ プロセッサ
１２４ メモリ
１２６ タッチ画面付きディスプレイ
１２８ キーボード
１２９ マイクロフォン
１３６ ネットワークＳＷ
１３８ ネットワーク構成要素
１４０ 電源
１４４ 音声生成器
２０２ パッケージ
２０４ 証明書アレイ
２０６ キー（副署名）
２１２ 起動検査器
２１０ インストール検査器
２２０ サーバ
２３０ マニフェスト
２３０ｉ マニフェスト
２３４ キー情報ファイル
５０４ ルート証明書リスト
５０６ マージ済みセキュリティディレクトリ（Ｓｅｃｕｒｉｔｙ Ｄｉｒｅｃｔｏｒｙ ｍｅｒｇｅｄ）
５０８ 更新ローダ

Claims (16)

1. 複数の装置とサーバとを備えるコンピューティング環境において、前記サーバに格納された画像を、前記複数の装置のうち該画像のインストールを許可された装置のクラスに提供することを制御するための方法であって、
   前記複数の装置のうちの特定の装置が前記サーバからパッケージを受信するステップであって、前記パッケージは、前記特定の装置がインストールしようとする画像のデータと、前記画像のプロバイダによって前記画像のインストールが許可されている装置のクラスを識別するクラス識別子に関連付けられた第１の署名とを含み、前記第１の署名は、前記サーバが、前記画像のデータに対して所定のハッシュアルゴリズムを適用して前記画像に対する第１のハッシュを取得し、前記クラス識別子に前記所定のエンコードアルゴリズムを適用して前記クラス識別子に対する第２のハッシュを取得し、前記第１および第２のハッシュの全体に対して署名をすることによって生成されており、前記クラス内の装置は前記クラス識別子を共通に有する、ステップと、
   前記特定の装置内の実施機構が、前記パッケージに含まれる前記画像のデータに前記所定のハッシュアルゴリズムと同じハッシュアルゴリズムを適用して前記画像に対する第３のハッシュを取得し、前記特定の装置が有するクラス識別子に前記所定のアルゴリズムと同じハッシュアルゴリズムを適用して前記クラス識別子に対応する第４のハッシュを取得し、前記第３のハッシュと前記第４のハッシュの全体に対して署名をすることによって、第２の署名を生成するステップと、
   前記特定の装置内の実施機構が、前記第１の署名と前記第２の署名が一致するかどうかを判断するステップであって、前記第１の署名と前記第２の署名が一致するとき、前記特定の装置は、前記画像のプロバイダによって前記画像のインストールが許可されている装置であるステップと、
   前記第１の署名と前記第２の署名が一致すると判断されたとき、前記画像を前記特定の装置のメモリ上にインストールするステップと
   を含むことを特徴とする方法。
2. 前記受信するステップの前に、前記特定の装置が、前記特定の装置が有する前記クラス識別子と前記特定の装置を識別する識別子とを含む、汎用一意識別子（ＵＵＩＤ）を前記サーバに提供するステップをさらに含むことを特徴とする請求項１に記載の方法。
3. 前記パッケージは、前記パッケージの内容を説明するマニフェストファイルをさらに含むことを特徴とする請求項１に記載の方法。
4. 前記実施機構は、前記特定の装置のインストーラ内に実装されることを特徴とする請求項１に記載の方法。
5. 前記特定の装置に前記画像がインストールされたあと、起動プロセス中に、前記実施機構が、前記特定の装置を起動する起動ローダコードの有効性を確認するステップ、および前記起動ローダコードにおいて、前記実施機構を実装している前記インストーラの有効性を確認するステップをさらに含むことを特徴とする請求項４に記載の方法。
6. 前記実施機構は、前記受信したパッケージに、前記第２の署名を生成することにより前記パッケージに対してキー付けすべきことを示すキーイング要求が含まれているかどうかに応じて動作することを特徴とする請求項１に記載の方法。
7. 前記実施機構は、前記キーイング要求が、前記特定の装置にすでにインストールされている画像を含む別のパッケージに含まれているかどうかに応じて動作することを特徴とする請求項６に記載の方法。
8. 前記実施機構は、前記キーイング要求が、前記特定の装置にデータをインストールするために処理される別のパッケージに含まれているかどうかに応じて動作することを特徴とする請求項６に記載の方法。
9. 請求項１に記載の方法を実行するプログラムを記録したことを特徴とするコンピュータ可読な記録媒体。
10. プロセッサとシステムメモリとを備えたコンピューティング装置であって、
    該コンピューティング装置と接続されたサーバから、前記メモリ上にインストールしようとする画像のデータと、前記画像のプロバイダによって前記画像のインストールが許可されているコンピューティング装置で構成される装置のクラスを識別するクラス識別子に関連付けられた第１の署名とを含むパッケージを受信するための手段であって、前記第１の署名は、前記サーバが、前記画像のデータに対して所定のハッシュアルゴリズムを適用して前記画像に対する第１のハッシュを取得し、前記クラス識別子に前記所定のエンコードアルゴリズムを適用して前記クラス識別子に対する第２のハッシュを取得し、前記第１および第２のハッシュの全体に対して署名をすることによって生成されている、手段と、
    前記パッケージに含まれる前記画像のデータに前記所定のハッシュアルゴリズムと同じハッシュアルゴリズムを適用して前記画像に対する第３のハッシュを取得し、該コンピューティング装置が有するクラス識別子に前記所定のアルゴリズムと同じハッシュアルゴリズムを適用して前記クラス識別子に対応する第４のハッシュを取得し、前記第３のハッシュと前記第４のハッシュの全体に対して署名をすることによって、第２の署名を生成し、前記第１の署名と前記第２の署名を比較して一致するかどうかを判断し、一致するとき該コンピューティング装置は前記画像のプロバイダによって前記画像のインストールが許可されているとして、前記画像を前記メモリ上にインストールする実施機構と を備えたことを特徴とするコンピューティング装置。
11. 前記パッケージはさらに、前記パッケージの内容を説明するマニフェストファイルを含むことを特徴とする請求項１０に記載のコンピューティング装置。
12. 前記実施機構は、前記第１の署名と前記第２の署名の比較に基づいて前記画像のインストールを防ぐまたは可能にすることによって、前記画像が動作することを防ぐ、または前記画像が動作できるようにするインストール時検査器を含むことを特徴とする請求項１０に記載のコンピューティング装置。
13. 前記実施機構は、前記第１の署名と前記第２の署名の比較に基づいて該コンピューティング装置が起動するのを防ぐまたは起動できるようにする起動時検査器を含むことを特徴とする請求項１０に記載のコンピューティング装置。
14. 前記実施機構は、前記受信したパッケージに、前記第２の署名を生成することにより前記パッケージに対してキー付けすべきことを示すキーイング要求が含まれているかどうかに応じて動作することを特徴とする請求項１０に記載のコンピューティング装置。
15. 前記実施機構は、前記キーイング要求が、該コンピューティング装置にすでにインストールされている画像を含む別のパッケージに含まれているかどうかに応じて動作することを特徴とする請求項１４に記載のコンピューティング装置。
16. 前記実施機構は、前記キーイング要求が、該コンピューティング装置にデータをインストールするために処理される別のパッケージに含まれているかどうかに応じて動作することを特徴とする請求項１４に記載のコンピューティング装置。

Images