JP4971466B2 - コンピューティング・デバイスの安全なブート - Google Patents

Description

本発明は、一般には、電子セキュリティに関する。より詳細には、本発明は、コンピューティング・デバイスを安全にブートすることに関する。

人々の日常生活においてますます多くのコンピューティング・デバイスが使用されるにつれて、セキュリティが、ユーザおよびコンテンツ・プロバイダに広く懸念されるようになっている。ウィルス、ワーム、トロイの木馬、個人情報窃盗、ソフトウェアおよびメディア・コンテンツ著作権侵害、およびデータ破壊の脅威を用いた恐喝が横行している。通常、これらの攻撃は、さもなければシステム、コンテンツ・プロバイダ、ユーザまたはアプリケーションにとって私的なものであるデバイス・リソースへのアクセスを露呈させるために悪意のあるソフトウェア・コードをインストールし実行することを伴う。

例えば、ハッカー・プログラムは、ハリウッド映画や音楽などのオーディオ／ビデオ・コンテンツを再生するために開発された消費者コンピューティング・デバイス内で実行されるとき、Ａ／Ｖコンテンツをセキュリティ保護するために使用された暗号化を破ることを潜在的に可能にし得る。したがって、こうしたデバイスには、ハイ・レベルのセキュリティが通常必要である。

オペレーティング・システムは、こうした攻撃から保護するためのいくつかのセキュリティ機能を提供し得る。しかし、オペレーティング・システムのセキュリティ機能は、日々生じる新しい攻撃に後れを取ることがよくある。さらに、コンピューティング・デバイスをブートするとき、セキュリティ機能は、まだ初期化されていないことがあり、迂回および／または改ざんに脆弱である。

これらの攻撃から保護する別のやり方は、メーカから出荷された後にいずれかの追加のソフトウェアがインストールされ、かつ／または実行されないようにコンピューティング・デバイスを完全に封印することである。しかし、こうした厳格な対策は、基礎をなすコンピューティング・デバイスの能力および柔軟性を厳しく制限する。それは、コンピューティング・デバイスのアップグレードを高価で難しいものにするだけでなく、デバイスの外部からソフトウェア・コードをダウンロードし実行することを必要とするますます増えているアプリケーションを利用することができない。さらに、迅速な技術進歩は通常、コンピューティング・デバイス内に元来組み込まれたアプリケーションまたは機能性を非常に短期間のうちに陳腐化させる。

したがって、現在のセキュリティ対策は、コンピューティング・デバイス内のアプリケーションおよびコンテンツを保護し、その一方でデバイスのソフトウェアおよび／またはファームウェアを更新する柔軟性を与える堅牢な解決策を提供していない。

デバイスのメモリ内にロードされたコード・イメージを検証するためにデバイス内部に埋め込まれたコードを実行するための方法および装置について、本明細書に述べられる。コード・イメージは、信頼できるコード・イメージであると検証された後に実行され得る。埋め込まれたコードは、デバイスのＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ：読取り専用メモリ）などの安全な記憶域に格納されてもよい。一実施形態では、コード・イメージの検証は、安全な記憶域内に格納された鍵に基づく。鍵は、各デバイスに一意であってもよい。鍵へのアクセスは、関連する安全な記憶域によって制御されてもよい。デバイスは、検証されたコード・イメージの実行の後に続いて動作環境の確立を完了してもよい。

一代替実施形態では、コード・イメージは、デバイスの動作環境を提供するオペレーティング・システム（ＯＳ：ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ）のカーネルを表してもよい。コード・イメージは、デバイスの大容量記憶装置からロードされてもよい。デバイスを一意に識別する、セキュアＲＯＭ内に格納された鍵を使用してうまく検証されると、コード・イメージは、デバイスの動作環境を確立するために、デバイスのメイン・メモリ内で実行されて、ＯＳのカーネルが設定され得る。一実施形態では、デバイスは携帯型デバイスである。

一代替実施形態では、デバイスに関連する大容量記憶装置を初期化して大容量記憶装置へのアクセスを可能にするために、デバイスのセキュアＲＯＭ（読取り専用メモリ）からの埋め込まれた第１の実行可能イメージが実行され得る。セキュアＲＯＭは、デバイスを一意に識別する一意識別子（ＩＤ）を格納してもよい。大容量記憶装置の初期化が成功すると、セキュアＲＯＭ内に埋め込まれた一意識別子（ＩＤ）を使用して、大容量記憶装置内に格納された第２の実行可能イメージが突き止められ検証され得る。うまく検証された後、第２の実行可能イメージは、デバイス上で低レベルのハードウェア初期化を実施するために実行され得る。第２の実行可能イメージは、デバイスのオペレーティング・システム（ＯＳ）のカーネル・イメージを検証しロードする第３の実行可能イメージを突き止め実行するためにうまく実行され得る。カーネル・イメージは、デバイスのＯＳの残りを初期化し構成するためにうまく実行され得る。

本発明の他の特徴は、添付の図面、以下の詳細な説明から明らかになる。

本発明は、限定するためではなく、例示するために、添付の図面の図中に示されている。図面では、同じ参照符号は、類似の要素を示す。

安全なブートのためのシステム・コンポーネントの一実施形態を示すブロック図である。 安全なブートを実行するシステム・コンポーネントの一実施形態を示すブロック図である。 安全なブートを実施するためのプロセスの一実施形態を示すフローチャートである。 ＵＩＤ（一意の識別子）およびシード文字列に基づいてコード・イメージから署名を生成するためのプロセスの一実施形態を示すフローチャートである。 デバイスを安全にブートするためのホストのネットワーク接続の一実施形態を示すブロック図である。 ホストからデバイスまで動作環境を安全に回復するためのプロセスの一実施形態を示すフローチャートである。 ホストからデバイスまで動作環境の最小の安全な回復を実施するためのプロセスの一実施形態を示す状態図である。 ホストからデバイスまでソフトウェア・コンポーネントを安全に復元するためのプロセスの一実施形態を示すフローチャートである。 ホストからデバイスまでアプリケーションを安全に更新するためのプロセスの一実施形態を示すフローチャートである。 検証されないコード・イメージを実行するためのプロセスの一実施形態を示すフローチャートである。 本明細書に述べられた諸実施形態に関連して使用され得る一般的なコンピュータ・システムの一例を示す図である。 本発明の一実施形態で使用され得るデータ処理システムの一例を示す図である。

コンピューティング・デバイスを安全にブートするための方法および装置について、本明細書に述べられる。以下の説明では、本発明の実施形態についての完全な説明を提供するために、複数の具体的な詳細が述べられる。しかし、本発明の実施形態は、これらの具体的な詳細なしに実施できることが当業者には明らかである。他の例では、この説明の理解を曖昧にしないために、よく知られているコンポーネント、構造および技術は、詳細には示されていない。

本明細書中の「一実施形態（ｏｎｅ ｅｍｂｏｄｉｍｅｎｔ、ａｎ ｅｍｂｏｄｉｍｅｎｔ）」への言及は、その実施形態に関連して述べられた特定の特徴、構造または特性が本発明の少なくとも１つの実施形態に含まれ得ることを意味する。本明細書の様々なところに語句「一実施形態では」が現れることは、必ずしもすべてが同じ実施形態に言及するものではない。

以下の諸図に示されたプロセスは、ハードウェア（例えば回路、専用論理など）、ソフトウェア（汎用コンピュータ・システムまたは専用マシンで実行されるものなど）、あるいは両方の組合せを備える処理論理によって実施される。下記ではプロセスについて、いくつかの順次オペレーションに関して述べられているが、述べられたオペレーションの一部は、異なる順序で実施され得ることを理解されたい。さらに、一部のオペレーションは、順次にではなく、並列に実施され得る。

用語「ホスト」および用語「デバイス」は、デバイスのフォーム・ファクタに対するホストの特定のフォーム・ファクタに具体的に言及するものではなく、データ処理システムに一般的に言及するものである。

一実施形態では、デバイスの安全なブートは、デバイス内の極めて重要なリソースが動作環境内で保護されることを保証するように設計されてもよい。一方、デバイスの安全なブートは、不要な管理、材料および／または実施コストを必要とせずに、デバイス内部で実行されるソフトウェアをそれぞれ異なるポリシーおよび手順の下で更新しインストールすることを可能にする柔軟性を提供することができる。一実施形態では、デバイスのブートのセキュリティは、デバイス内に一緒に組み込まれた、セキュアＲＯＭとも呼ばれるＲＯＭ（読取り専用メモリ）などの安全な記憶域内に格納されたコードおよびデータによって実施されてもよい。セキュアＲＯＭの中身は、デバイスの製造段階の間に格納されてもよい。セキュアＲＯＭは、デバイスを一意に識別するデバイスのＵＩＤ（一意識別子）に関連付けられてもよい。デバイス内で実行されるソフトウェア・コードの信頼の根は、ＵＩＤに基づいてセキュアＲＯＭによって署名されたコード・イメージから生じ得る。

一実施形態によれば、デバイスのセキュアＲＯＭは、信頼できるエンティティのルート証明書のフィンガープリントを含んでもよい。信頼できるエンティティによって証明されたコード・イメージは、フィンガープリントに基づいて、セキュアＲＯＭによる証明プロセスに従ってデバイス内で実行されると信頼され得る。一実施形態では、デバイスの安全なブートは、セキュアＲＯＭに従って信頼できるエンティティと結合されるとき、信頼できるソフトウェア・コードを回復してもよい。セキュアＲＯＭは、格納されたデバイスＵＩＤに基づいてフィンガープリントによって証明されたコード・イメージまで信頼を広げることができる。一実施形態では、セキュアＲＯＭは、外部接続からダウンロードされたコード・イメージを証明することによってアプリケーション・ソフトウェアの復元を可能にすることができる。別の実施形態では、セキュアＲＯＭは、外部接続によってダウンロードされた信頼できるソフトウェア・コードによって、デバイス内に格納されたユーザ・データのクリーン・アップを強制してもよい。

図１は、安全なブートのためのシステム・コンポーネントの一実施形態を示すブロック図である。システム１００は、デバイス内部の１つまたは複数のチップ内に常駐してもよい。一実施形態では、システム１００は、メモリ・コンポーネント１０３と結合されたチップ１０５を含んでもよい。チップ１０５は、ＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ：スタティック・ランダム・アクセス・メモリ）やＥＤＲＡＭ（Ｅｍｂｅｄｄｅｄ Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ：埋込みダイナミック・ランダム・アクセス・メモリ）などのＲＡＭ（ランダム・アクセス・メモリ）コンポーネント１１１を含むこともできる。コード・イメージは、デバイスによって実行される前にメモリ・コンポーネント１０３内にロードされてもよい。実行されるとき、コード・イメージは、ユーザ・アプリケーション、システム・アプリケーション、および／またはユーザまたはシステム・アプリケーションをサポートするデバイスの動作環境（例えばオペレーティング・システム）をイネーブルしてもよい。一実施形態では、メモリ・コンポーネント１０３は、ＤＤＲ（Ｄｏｕｂｌｅ Ｄａｔａ Ｒａｔｅ：ダブル・データ・レート）メモリを含む。チップ１０５は、コード１１５および関連するデータ１１７を格納するＲＯＭ １１３を含んでもよい。コード１１５は、暗号ハッシュ関数ＳＨＡ−１、ＳＨＡ−２２４、ＳＨＡ−２５６、ＳＨＡ−３８４およびＳＨＡ−５１２などのＳＨＡ（Ｓｅｃｕｒｅ Ｈａｓｈｉｎｇ Ａｌｇｏｒｉｔｈｍ：セキュア・ハッシュ・アルゴリズム）ハッシュ関数の実装を含んでもよい。さらに、コード１１５は、ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｔｄａｒｄ：高度暗号化規格）暗号化など、データ暗号化アルゴリズムの実装を含んでもよい。一実施形態では、コード１１５は、デバイスのハードウェア初期化に、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ：ユニバーサル・シリアル・バス）などの接続または通信インターフェースをサポートさせてもよい。コード１１５は、デバイスのクロック・レートを変更する命令を含んでもよい。本出願の全体にわたって、ＳＨＡとＡＥＳは、例示目的のためだけに例として用いられていることに留意されたく、他のハッシングおよび／または暗号化技術も使用され得ることが理解されよう。

一実施形態では、コード１１５は、メモリ・コンポーネント１０３やＲＡＭ １１１などのデバイス・メモリへのコード・イメージのロードを引き起こしてもよい。コード・イメージは、チップ１０５に結合された記憶コンポーネント１０９からロードされてもよい。記憶コンポーネント１０９は、ＮＡＮＤフラッシュ、ＮＯＲフラッシュまたは他の大容量記憶（例えばハード・ディスク）コンポーネントなど、フラッシュ・メモリであってもよい。別の実施形態では、コード・イメージは、デバイスの外部のソースから接続インターフェース１０１を介してロードされてもよい。接続インターフェース１０１は、ＵＳＢ接続、イーサネット（登録商標）接続または無線ネットワーク接続（例えばＩＥＥＥ ８０２．１ｘ）などに基づいてもよい。一実施形態では、コード１１５は、コード・イメージが信頼できるコードだけを含むことを検証した後、デバイス・メモリから記憶コンポーネント１０９にコード・イメージを格納させてもよい。

デバイスがデバイス・メモリ内にロードされたコード・イメージを実行し始め得る前に、コード１１５は、コード・イメージが信頼され得ることを保証するために、ロードされたコード・イメージへの検証オペレーションを実施してもよい。一実施形態では、コード１１５は、ＲＯＭ内のデータ・セクション１１７、ＵＩＤ １１９および／またはＧＩＤ（Ｇｌｏｂａｌ Ｉｄｅｎｔｉｆｉｅｒ：グローバル識別子）１２１など、チップ１０５内に含まれたデータに従って、ロードされたコード・イメージを検証してもよい。ＵＩＤ １１９は、各デバイスに一意であってもよい。一実施形態では、すべてのデバイスが、単一のＧＩＤ １２１に関連付けられる。一実施形態では、ＧＩＤは、コード検査を防ぐためにコード・イメージを暗号化するのに使用されてもよい。ＲＯＭ １１５のデータ・セクション１１７は、公開鍵証明書など、信頼できるエンティティからの署名に基づいてフィンガープリント１２３を格納してもよい。一実施形態では、別個のデバイスが、信頼できる同じエンティティに基づくフィンガープリント１２３を含んでもよい。

図２は、安全なブートを実行するシステム・コンポーネントの一実施形態を示すブロック図である。システム１００は、記憶コンポーネント１０９からＬＬＢ（Ｌｏｗ Ｌｅｖｅｌ Ｂｏｏｔ：低レベル・ブート）コード・イメージ２２９を、ＬＬＢ ２２５としてＲＡＭ １１１にロードしてもよい。ＬＬＢ ２２５は、システム１００の長期電力管理に関連してもよい。一実施形態では、ＬＬＢ ２２５は、システム１００のバージョンの識別を含んでもよい。コード・イメージＬＬＢ ２２５は、コード１１５の実行に基づいてロードされてもよい。一実施形態では、コード・イメージＬＬＢ ２２９は、コード１１５の実行によって、コード・イメージＬＬＢ ２２５に基づいてＲＡＭ １１１から格納されてもよい。

コード・イメージｉＢｏｏｔ ２２７は、一実施形態によれば、ＬＬＢ ２２５の実行に従って、コード・イメージｉＢｏｏｔ ２３１に基づいて記憶装置１０９からメモリ・コンポーネント１１１にロードされてもよい。コード・イメージｉＢｏｏｔ ２３１は、システム１００を収容するデバイスの動作環境を提供するオペレーティング・システムのためのハードウェア初期化を引き起こしてもよい。デバイスは、ブートが成功した後、動作環境に入ってもよい。動作環境は、デバイス内で実行される様々なユーザおよび／またはシステム・アプリケーションをサポートしてもよい。一実施形態では、コード・イメージｉＢｏｏｔ２３１は、デバイスの大容量記憶コンポーネントをイネーブルし、ユーザ・インターフェースのグラフィック・コンポーネントを初期化し、かつ／またはデバイスの画面コンポーネントなどをアクティブ化してもよい。コード・イメージｉＢｏｏｔ ２３１は、コード・イメージＬＬＢ ２２５の実行によって、コード・イメージｉＢｏｏｔ ２２７に基づいてＲＡＭ １１１から格納されてもよい。

一実施形態では、コード・イメージＫｅｒｎｅｌｃａｃｈｅ ２２３は、コード・イメージＫｅｒｎｅｌｃａｃｈｅ ２３３に基づいて記憶装置１０９からメモリ１０３にロードされてもよい。コード・イメージＫｅｒｎｅｌｃａｃｈｅ ２２３は、デバイスの動作環境をサポートするオペレーティング・システムのカーネルの一部であってもよい。一実施形態では、コード・イメージＫｅｒｎｅｌｃａｃｈｅ ２２３は、カーネルおよびオペレーティング・システム・コンポーネント２３５を記憶装置１０９からメモリ１０３にロードさせる。オペレーティング・システム・コンポーネントは、ユーザ・アプリケーション、ライブラリ、グラフィック・ユーザ・インターフェース・コンポーネントおよび／またはユーザ・データ２３５を含んでもよい。ユーザ・データは、デバイスのユーザに関連する音楽、画像、ビデオまたは他のデジタル・コンテンツを含んでもよい。例えば、こうしたユーザ・データは、制限された使用法を有するＤＲＭ（ｄｉｇｉｔａｌ ｒｉｇｈｔｓ ｍａｎａｇｅｍｅｎｔ：デジタル権利管理）に準拠したデータであってもよい。コード・イメージＫｅｒｎｅｌｃａｃｈｅ ２２３は、カーネルおよびオペレーティング・システム・コンポーネント２３５をメモリ１０３にロードすることを可能にしてもよい。一実施形態では、コード・イメージＫｅｒｎｅｌｃａｃｈｅ ２２３は、メモリ１０３内で実行される前に、検証プロセスに、カーネルが信頼できることを保証させてもよい。別の実施形態では、コード・イメージＫｅｒｎｅｌｃａｃｈｅ ２２３は、メモリ１０３内で実行される前に、オペレーティング・システム・コンポーネント２３５が信頼できることを検証プロセスに保証させてもよい。コード・イメージＫｅｒｎｅｌｃａｃｈｅ ２２３は、ＵＩＤ １１９またはフィンガープリント１２３に基づいて、オペレーティング・システム・コンポーネント２３５が信頼できると決定するために実行されてもよい。一実施形態では、コード・イメージＫｅｒｎｅｌｃａｃｈｅ ２２３は、ＧＩＤ １２１に従ってメモリ１０３内のオペレーション・システム・コンポーネント２３５の復号を引き起こしてもよい。一実施形態では、コード・イメージＫｅｒｎｅｌｃａｃｈｅ ２２３は、オペレーティング・システム・コンポーネント２３５をメモリ１０３から記憶装置１０９に格納するために実行されてもよい。コード・イメージＫｅｒｎｅｌｃａｃｈｅ ２２３は、記憶装置１０９に格納される前にオペレーティング・システム・コンポーネント２３５の暗号化を可能にしてもよい。

一実施形態では、ＵＩＤ １１９は、特権モードで実行されるいくつかのオペレーティング・システム・コンポーネントにアクセス可能であり得る。オペレーティング・システムのカーネルは、アプリケーションが特権モードで実行されているかどうかに応じて、アプリケーションによるＵＩＤ １１９へのアクセスをアプリケーションに拒否しまたは許可してもよい。一実施形態では、オペレーティング・システムのカーネルは、アプリケーションの対応するコード・イメージが適切に署名された署名を含んでいるかどうかに基づいて、アプリケーションが特権モードで実行され得るかどうか決定してもよい。ＤＲＭ（デジタル権利管理）システムは、ＵＩＤ １１９に基づいてオペレーティング・システム・コンポーネント２３５のユーザ・データへのアクセスを制御するために特権モードで実行されていることがある。アプリケーションは、ＤＲＭシステムを介してユーザ・データにアクセスしてもよい。一部の実施形態では、オペレーション・システムのネットワーク・ユーティリティに、特権が与えられてもよい。ネットワーク・ユーティリティは、デバイスが、ベース・バンド・チップなどのインターフェース・チップによって外部リソースに相互接続することを可能にしてもよい。別の実施形態では、特権モードで実行するために、ウィルス保護ソフトがオペレーティング・システムによって提供されてもよい。

したがって、ソフトウェア・コンポーネントが（例えば信頼ベンダによって、あるいはデバイスの製造やソフトウェア・コンポーネントのテストなどの特定の状況で提供された）特定の所定条件を満たさない限り、システム内で実行されるどんなソフトウェア・コンポーネントをも実行前に検証し、または認証しなければならない。一実施形態では、システム内の安全な記憶域の設定は、所定の条件に関連付けられてもよい。その結果、ＤＲＭ準拠データなど、どんなデータも、適切な検証または認証なしにはアクセスされず、または漏洩されない（ｃｏｍｐｒｏｍｉｓｅ）。

図３は、安全なブートを実施するためのプロセスの一実施形態を示すフローチャートである。例えば、プロセス３００は、図１のシステム１００によって実施されてもよい。一実施形態によれば、デバイスのブート・プロセスの間、プロセス３００の処理論理は、ブロック３０１で、ＲＯＭチップ内で命令を実行することによってデバイス内からコード・イメージを突き止めてもよい。命令は、図１のコード１１５内にあるようなＲＯＭチップのコード・セクションから読み出されてもよい。コード・イメージは、メモリ・コンポーネントまたはデバイスの記憶コンポーネントに格納されてもよい。メモリ・コンポーネントは、ＲＡＭであってもよい。記憶コンポーネントは、デバイスにアタッチされたフラッシュ・メモリまたは大容量記憶装置であってもよい。一実施形態では、コード・イメージが突き止められ得ない場合、ブート・プロセスは中断されてもよく、デバイスは、ブロック３０９で、ＤＦＵ（Ｄｅｖｉｃｅ Ｆｉｒｍｗａｒｅ Ｕｐｇｒａｄｅ：デバイス・ファームウェア・アップグレード）モードに入ってもよい。コード・イメージがうまく突き止められる場合、一実施形態によれば、プロセス３００の処理論理は、ブロック３０３で、コード・イメージをメモリにロードしてもよい。別の実施形態では、コード・イメージは、突き止められたときにはメモリ内に既にロードされていることがある。

一実施形態によれば、ブロック３０５で、プロセス３００の処理論理は、図１のＵＩＤ １１９など、デバイスに関連するＵＩＤに基づいて、ロードされたコード・イメージが信頼され得るかどうか検証できる。プロセス３００の処理論理は、コード・イメージからヘッダ値を抽出する。コード・イメージ内のヘッダ値の位置は、予め定められてもよい。一実施形態では、ヘッダ値は、コード・イメージ内の属性値対に事前設定された属性に基づいて抽出されてもよい。ヘッダ値は、よく知られているハッシュおよび暗号化アルゴリズムによって、デバイスのＵＩＤに従ってコード・イメージ上に署名された署名値を含んでもよい。一実施形態では、プロセス３００の処理論理は、ブロック３０５で、よく知られている同じハッシュおよび暗号化アルゴリズムによって、ＵＩＤに従ってコード・イメージから別の署名値を導出する。プロセス３００の処理論理は、コード・イメージが信頼できるかどうか検証するために、導出された署名値と抽出された署名値を比較する。一実施形態では、導出された署名値および抽出された署名が互いに一致する場合は、検証は成功であり得る。そうでない場合は、検証は失敗であり得る。検証が成功しない場合は、プロセス３００の処理論理は、ブロック３０９で、デバイスをＤＦＵモードに入らせてもよい。一実施形態では、プロセス３００の処理論理は、ブロック３０９でデバイスがＤＦＵモードに入る前に、メモリからコード・イメージを取り除いてもよい。

検証が成功の場合は、プロセス３００の処理論理は、ブロック３１１で、コード・イメージを実行し得る。一実施形態では、コード・イメージは、図２の２２５、２２７および２２３に示されるように、ＬＬＢ、ｉＢｏｏｔまたはＫｅｒｎｅｌｃａｃｈｅであってもよい。プロセス３００の処理論理は、ブロック３１１で、デバイスのブート・オペレーションを実施する。ブート・オペレーションは、製品識別、デバイス電力管理の開始、大容量記憶コンポーネントのイネーブル、ユーザ・インターフェースのグラフィック・コンポーネントの初期化、画面コンポーネントのアクティブ化、および／またはデバイスのハードウェア初期化などを含んでもよい。一実施形態では、ブート・オペレーションは、カーネル、ならびに図２の２３５に示されるような特定のオペレーティング・システム・コンポーネントを含めて、オペレーティング・システムをメモリにロードすることを含んでもよい。プロセス３００の処理論理は、検証の成功を示すためにメモリ内の信頼できるコード・イメージに信頼の標識を付けてもよい。一実施形態では、メモリ内に置かれた信頼の標識に関連するコード・イメージは、検証なしに、信頼できるコードとして実行されてもよい。ブロック３１３で、プロセス３００の処理論理は、デバイスが完全にブートされるかどうか決定し得る。デバイスは、完全にブートされる場合は、動作可能になり、ブロック３１５で、通常の動作モードに入り得る。一実施形態では、Ｋｅｒｎｅｌｃａｃｈｅ２２７は、デバイスが通常オペレーションに入った後、ユーザ・モードで実行されるユーザ・アプリケーションを開始してもよい。ユーザ・モードで実行されるアプリケーションは、図２のＵＩＤ １１９およびＧＩＤ １２１など、デバイス・ハードウェア関連の情報にアクセスし得ない。デバイスは、ブロック３１３でブート・オペレーションが失敗する場合、ＤＦＵモードに入ってもよい。

一実施形態によれば、ブロック３１３でプロセス３００の処理論理がデバイスのブート・プロセスが完了していないと決定する場合、ブロック３１７で、ブート・プロセスは継続し得る。プロセス３００の処理論理は、現在のコード・イメージの実行に基づいて、ブロック３１３で別のコード・イメージを突き止めてもよい。一実施形態では、コード・イメージＬＬＢを実行すると、図２に示されるようなコード・イメージｉＢｏｏｔが突き止められ得る。別の実施形態では、コード・イメージｉＢｏｏｔを実行すると、図２に示されるようなコード・イメージＫｅｒｎｅｌｃａｃｈｅが突き止められ得る。一部の実施形態では、コード・イメージＫｅｒｎｅｌｃａｃｈｅを実行すると、図２に示されるようなカーネルおよびオペレーティング・システム・コンポーネントを含むコード・イメージが突き止められ得る。プロセス３００の処理論理は、ブロック３１７で次のコード・イメージを突き止めた結果に従って、ブロック３１９にループ・バックしてブート・プロセスを続けてもよい。

図４は、ＵＩＤおよびシード文字列に基づいてコード・イメージから署名を生成するためのプロセスの一実施形態を示すフローチャートである。例えば、プロセス４００は、図１に示されるようなシステムによって実施されてもよい。一実施形態では、プロセス４００の処理論理は、図２に示されたＬＬＢ ２２５、ｉＢｏｏｔ ２２７またはＫｅｒｎｅｌｃａｃｈｅ ２２３など、コード・イメージ４１１にわたってハッシュ・オペレーション４０９を実施する。ハッシュ・オペレーションは、暗号ハッシュ関数ＳＨＡ−１、ＳＨＡ−２２４、ＳＨＡ−２５６、ＳＨＡ−３８４およびＳＨＡ−５１２などのＳＨＡ（セキュア・ハッシュ・アルゴリズム）ハッシュ関数に基づいてもよい。一実施形態では、ハッシュ・オペレーション４０９は、鍵の文字列４１３を生成してもよい。鍵文字列４１３は、２０バイトの長さを有してもよい。一実施形態では、プロセス４００の処理論理は、デバイスに関連する鍵文字列４１３、ＵＩＤ ４０１およびシード文字列４０７に基づいて署名４０５を生成するために、ブロック４０３で暗号化オペレーションを実施してもよい。一実施形態では、暗号化オペレーションは、ブロック４０３で、ＡＥＳ（高度暗号化規格）のアルゴリズムに基づいてもよい。プロセス４００の処理論理は、ブロック４０３で、鍵文字列４１３の２０バイトのうちから４バイトを廃棄するなど、鍵文字列４１３を切り捨ててもよい。一実施形態では、ブロック４０３で、ＡＥＳアルゴリズムは、１６バイトに基づく。ＵＩＤ ４０１は、図１に示されたＵＩＤ １１９としてデバイス内に格納されてもよい。シード文字列４０７は、デバイスに基づくシード生成関数によって生成されてもよい。一実施形態では、シード文字列４０７は、シード生成関数が同じデバイスに適用されるたびに同じであってもよい。

図５は、図１のシステムに従ってデバイスを安全にブートするためのホストのネットワーク接続の一実施形態を示すブロック図である。一実施形態では、デバイスは、ホストに接続することによってブートするためにＤＦＵモードに入ってもよい。デバイスは、ユーザからの開始に基づいてＤＦＵモードに入るように強制されてもよい。一実施形態では、デバイスは、デバイスのボタンを押下するなど、ユーザが所定の動作を実施することに応答してＤＦＵモードに入ってもよい。ユーザは、例えばユーザ・データのクリーン・アップ、ハードウェア・ドライバのアップグレード、ユーザ・アプリケーションのアップグレードおよび／または新しいアプリケーションのインストールなどを含めて、デバイスのためのシステム管理タスクを実施するためにＤＦＵモードに入ることをデバイスに要求してもよい。デバイスは、図３のブロック３０９に示されるように、ブート・シーケンスの少なくとも１つの段階でブートに失敗する場合、自動的にＤＦＵモードに入ってもよい。あるいは、デバイスは、破損したデータ、または損傷を受けたソフトウェア・コンポーネントが検出されるときなど、通常オペレーションの間にオペレーティング・システムに異常が生じる場合、ＤＦＵモードに入ってもよい。

一実施形態によれば、ネットワーク５００は、ホスト５０３に結合されたデバイス５０１を含んでもよい。デバイス５０１は、例えば、結合されたホスト５０３からオペレーティング・システム・コンポーネントを復元する復元デーモン・アプリケーションを実行するＡｐｐｌｅ Ｃｏｍｐｕｔｅｒ Ｉｎｃ．社からのｉＰｏｄなどのメディア・プレーヤーであってもよい。デバイス５０１は、ＴＣＰ／ＩＰプロトコルをサポートする接続インターフェースを介してホスト５０３に結合されてもよい。接続インターフェースは、ＵＳＢ、無線ネットワークまたはイーサネットなどに基づいてもよい。一実施形態では、ホスト５０３は、例えばＡｐｐｌｅ Ｃｏｍｐｕｔｅｒ Ｉｎｃ．社からのｉＴｕｎｅアプリケーションなどのアプリケーション・ソフトウェアを実行するＭａｃまたはＷｉｎｄｏｗｓ（登録商標）ベースのコンピュータであり得る。ホスト５０３は、広域ネットワーク（例えばインターネット）またはローカル・エリア・ネットワーク（例えばイントラネットやピア・ツー・ピア・ネットワーク）などのネットワーク５０５を介して中央サーバ５０７に接続されてもよい。一実施形態では、中央サーバ５０７は、公的にアクセス可能なｗｅｂサーバに基づいてもよい。あるいは、サーバ５０７は、イントラネットまたはローカル・サーバであってもよい。

図６は、ホストからデバイスまで動作環境を安全に回復するためのプロセスの一実施形態を示すフローチャートである。例えば、プロセス６００は、図１および／または図５に示されるようなシステムによって実施されてもよい。一実施形態では、プロセス６００の処理論理は、ブロック６０１で、デバイスが回復モードにあることを示すステータスをホスト・コンピュータに送ってもよい。デバイスは、コード・イメージの検証の失敗に応答して回復モードに入ってもよい。ホスト・コンピュータは、図５に示されるように、プロセス６００を実施するデバイスに結合されてもよい。一実施形態では、ステータスは、製品ＩＤおよび／またはベンダＩＤを含んでもよい。ホスト・コンピュータは、受信されたステータスに基づいて、接続されたデバイスを回復するためにコード・イメージを準備してもよい。一実施形態では、コード・イメージは、図５に示されたネットワーク５０５などのネットワークを介して接続されたホスト・コンピュータによって中央サーバ・コンピュータから取り出されてもよい。ブロック６０３で、一実施形態によれば、プロセス６００の処理論理は、ホスト・コンピュータからコード・イメージを受信して、図１に示されたメモリ１０３などのデバイスのメモリ・コンポーネントに入れてもよい。プロセス６００の処理論理は、ブロック６０５で、ホスト・コンピュータから、受信されたコード・イメージを実行する命令を受信してもよい。一実施形態では、プロセス６００は、ＭＡＣベースのコンピュータ内で実行されるｉＴｕｎｅなど、ホスト・コンピュータ上で実行される回復ソフトウェアによって制御されてもよい。

一実施形態によれば、ブロック６０７で、プロセス６００の処理論理は、デバイスのメモリ内で受信されたコード・イメージに伴う証明書を抽出してもよい。コード・イメージは、図２に示されるように、ＬＬＢ、ｉＢｏｏｔおよび／またはＫｅｒｎｅｌｃａｃｈｅであってもよい。コード・イメージは、ＲＳＡ（Ｒａｌｐｈ Ｓｈａｍｉｒ Ａｄｅｌｍａｎ）公開鍵暗号法など、公開鍵暗号法に従って暗号化されてもよい。証明書は、Ｘ．５０９規格に基づいた鍵を含んでもよい。ブロック６０９で、プロセス６００の処理論理は、図１に示されたコード１１５など、デバイスのセキュアＲＯＭに格納されたコードに従って証明書を検証してもよい。一実施形態では、プロセス６００の処理論理は、一連の証明書の最後の証明書としてルート証明書を用いて、抽出された証明書の検証のために一連の証明書を証明してもよい。プロセス６００の処理論理は、接続されたホスト・コンピュータから証明書を取り出してもよい。一実施形態では、ルート証明書は、図１に示されたフィンガープリント１２３など、デバイスのセキュアＲＯＭに格納されたフィンガープリントに基づいて検証されてもよい。ルート証明書は、Ａｐｐｌｅ Ｃｏｍｐｕｔｅｒ Ｉｎｃ．社によって発行されてもよい。検証が失敗する場合は、プロセス６００の処理論理は、ブロック６１３で、回復させるためにデバイスをＤＦＵモードに戻してもよい。

コード・イメージからの証明書がうまく検証される場合は、プロセス６００の処理論理は、ブロック６１５で、回復プロセスを継続して、検証された証明書に含まれた鍵に基づいてコード・イメージを復号してもよい。ブロック６１７で、プロセス６００の処理論理は、図１に示されたＵＩＤ １１９など、デバイスのセキュアＲＯＭに格納されたＵＩＤに基づいてコード・イメージからハッシュ署名を導出してもよい。一実施形態では、ハッシュ署名は、例えば図４に示されたプロセスに従って取得されてもよい。ブロック６１９で、プロセス６００の処理論理は、コード・イメージ内に、導出された署名を署名してもよい。一実施形態では、導出された署名は、コード・イメージのヘッダ値として署名されてもよい。プロセス６００の処理論理は、ブロック６２１で、例えば図１に示された記憶装置１０９など、デバイスの記憶装置内に署名付きのコード・イメージを格納してもよい。一実施形態では、署名付きのコード・イメージは、デバイス内の検証に失敗した別のコード・イメージを修復するために格納されてもよい。一実施形態では、コード・イメージは、デバイスの記憶装置に格納される前に実行されてもよい。別の実施形態では、コード・イメージは、うまく実行された後にデバイスの記憶装置に格納されてもよい。

図７は、ホストからデバイスまで動作環境の安全な回復を実施するためのプロセスの一実施形態を示す状態図である。例えば、状態７００は、図１および／または図５に示されるようなシステムの特定の動作状態を表し得る。一実施形態では、デバイスは、ブート・プロセスを開始するために、初期状態Ｂｏｏｔ ７０１に入ってもよい。デバイスのセキュアＲＯＭに格納された命令は、状態Ｂｏｏｔ ７０１の間に実行されてもよい。一実施形態では、状態Ｂｏｏｔ ７０１の間、図２に示されたＬＬＢ ２２９などの低レベルのブート・プログラムが、デバイス内で突き止められ得る。低レベル・ブート・プログラムは、突き止められ、デバイスのメモリ・コンポーネントにロードされてもよい。一実施形態では、突き止められた低レベル・ブート・プログラムは、図３のブロック３０５に示されるようなプロセスに従って、信頼できるコード・イメージであると検証されてもよい。低レベル・ブート・プログラムがうまく突き止められ検証される場合は、状態７００は、遷移成功７１１に従って、状態Ｂｏｏｔ ７０１から状態ＬＬＢ ７０３に入ってもよい。そうでない場合は、一実施形態によれば、状態７００は、デバイスがＤＦＵモードに入る間の遷移ＤＦＵ７１３を通って、状態Ｒｅｃｏｖｅｒｙ１ ７１７に入ってもよい。

状態Ｒｅｃｏｖｅｒｙ１ ７１７の間、デバイスは、図５に示されるような回復プロセスを実施するために、ホスト・コンピュータに結合されてもよい。一実施形態では、デバイスは、状態Ｒｅｃｏｖｅｒｙ１ ７１７に基づいてステータスを公開してもよい。ホスト・コンピュータは、デバイスから受信されたステータスに対応するコード・イメージを送信してもよい。一実施形態では、コード・イメージは、図２に示されるようなＬＬＢ ２２９であってもよい。デバイスは、図１のＵＩＤ １１９およびフィンガープリント１２３など、ＵＩＤおよびデバイスのセキュアＲＯＭ内に格納されたフィンガープリントに基づいて、受信されたコード・イメージが信頼できることを検証するために一連の証明を実施してもよい。一連の証明は、図６のブロック６０９で、プロセス６００に類似のプロセスに基づいて実施されてもよい。一実施形態では、コード・イメージがうまくロードされ検証される場合は、デバイスの状態は、遷移ロード７１５を通って、状態Ｒｅｃｏｖｅｒｙ１ ７１７から状態ＬＬＢ ７０３に遷移されてもよい。

一実施形態では、状態ＬＬＢ ７０１の間、デバイスは、デバイス内の図２に示されたｉＢｏｏｔ ２３１などの別のブート・イメージを突き止めるために、検証された低レベル・ブート・プログラム（例えば上述のＬＬＢまたは低レベル・ライブラリ）を実行してもよい。ブート・イメージは、状態ＬＬＢ ７０１の間、突き止められ、デバイスのメモリ・コンポーネントにロードされてもよい。一実施形態では、ブート・イメージは、図３のブロック３０５で述べられたようなプロセスに従って、信頼できるコード・イメージであると検証されてもよい。ブート・イメージがうまく突き止められ検証される場合は、状態７００は、状態ＬＬＢ ７０３から状態ｉＢｏｏｔ ７０５に入ってもよい。そうでない場合は、一実施形態によれば、状態７００は、デバイスがＤＦＵモードに入る間、状態Ｒｅｃｏｖｅｒｙ２ ７１９に入ってもよい。

状態Ｒｅｃｏｖｅｒ２ ７１９の間、デバイスは、図５に示されるような回復プロセスを実施するために、ホスト・コンピュータに結合されてもよい。一実施形態では、デバイスは、状態Ｒｅｃｏｖｅｒｙ２ ７１９に基づいてステータスを公開してもよい。ホスト・コンピュータは、状態Ｒｅｏｖｅｒｙ２ ７１９で、デバイスから受信されたステータスに対応するコード・イメージを送信してもよい。一実施形態では、コード・イメージは、図２に示されるようなｉＢｏｏｔ ２３１であってもよい。デバイスは、図１のＵＩＤ １１９およびフィンガープリント１２３など、ＵＩＤおよびデバイスのセキュアＲＯＭ内に格納されたフィンガープリントに基づいて、受信されたコード・イメージが信頼できることを検証するために一連の証明を実施してもよい。一連の証明は、図６のブロック６０９で、プロセス６００に類似のプロセスに基づいて実施されてもよい。一実施形態では、コード・イメージがうまくロードされ検証される場合、デバイスの状態は、状態Ｒｅｃｏｖｅｒｙ２ ７１９から状態Ｋｅｒｎｅｌｃａｃｈｅ７０７に遷移されてもよい。

一実施形態によれば、状態ｉＢｏｏｔ ７０５の間、デバイスは、デバイス内の図２に示されたＫｅｒｎｅｌｃａｃｈｅ ２３３などのカーネル・イメージを突き止めるために、検証されたブート・プログラムを実行してもよい。状態ｉＢｏｏｔ ７０５の間、カーネル・イメージが突き止められ、デバイスのメモリ・コンポーネントにロードされてもよい。一実施形態では、カーネル・イメージは、図３のブロック３０５で述べられたようなプロセスに従って、信頼できるコード・イメージであると検証されてもよい。カーネル・イメージがうまく突き止められ検証される場合は、状態７００は、状態ｉＢｏｏｔ ７０５から状態Ｋｅｒｎｅｌｃａｃｈｅ ７０７に入ってもよい。そうでない場合、一実施形態によれば、状態７００は、デバイスがＤＦＵモードに入る間、状態Ｒｅｃｏｖｅｒｙ３ ７２１に入ってもよい。

状態Ｒｅｃｏｖｅｒ３ ７２１の間、デバイスは、図５に示されるような回復プロセスを実施するために、ホスト・コンピュータに結合されてもよい。一実施形態では、デバイスは、状態Ｒｅｃｏｖｅｒｙ３ ７２１に基づいてステータスを公開してもよい。ホスト・コンピュータは、状態Ｒｅｏｖｅｒｙ３ ７２１でデバイスから受信されたステータスに対応するコード・イメージを送信してもよい。一実施形態では、コード・イメージは、図２のＫｅｒｎｅｌｃａｃｈｅ ２３３など、カーネル・イメージであってもよい。デバイスは、図１のＵＩＤ １１９およびフィンガープリント１２３など、ＵＩＤおよびデバイスのセキュアＲＯＭ内に格納されたフィンガープリントに基づいて、受信されたコード・イメージが信頼できることを検証するために、一連の証明を実施してもよい。一連の証明は、図６のブロック６０９で、プロセス６００に類似のプロセスに基づいて実施されてもよい。コード・イメージがうまくロードされ検証される場合は、一実施形態では、デバイスの状態は、状態Ｒｅｃｏｖｅｒｙ３ ７２１から状態Ｋｅｒｎｅｌｃａｃｈｅ７０７に遷移されてもよい。

一実施形態では、状態Ｋｅｒｎｅｌｃａｃｈｅ ７０７の間、デバイスは、図２の２３５などのオペレーティング・システム・コンポーネントを突き止めるために、検証されたカーネル・イメージを実行してもよい。突き止められたオペレーティング・システム・コンポーネントは、状態Ｋｅｒｎｅｌｃａｃｈｅ ７０７の間、検証されたカーネル・イメージの実行に従って信頼できると検証するために、デバイスのメモリ・コンポーネントにロードされてもよい。一実施形態では、カーネル・イメージは、図３のブロック３０５で述べられたようなプロセスに従って、オペレーティング・システム・コンポーネントが信頼できるかどうか決定してもよい。特権モードは、図２のＵＩＤ １１９またはＧＩＤ １２３など、デバイスのハードウェア・レベルのインターフェースへのアクセスのために、カーネル・イメージに基づいて信頼できるオペレーティング・システム・コンポーネントに割り当てられてもよい。状態Ｋｅｒｎｅｌｃａｃｈｅ ７０７の間、署名がなされていないオペレーティング・システム・コンポーネントに、ユーザ・モード特権が割り当てられてもよい。一実施形態では、オペレーティング・システム・コンポーネントは、デバイスのハードウェア・レベル・インターフェースにアクセスすることを許されないことがある。オペレーション・システムがデバイスのメモリにうまくロードされた後、状態７００は、状態Ｋｅｒｎｅｌｃａｃｈｅ ７０７から、通常の動作環境に対応する状態ＯＳ ７０９に遷移してもよい。ユーザ・アプリケーションは、状態ＯＳ ７０９の間、割り当てられたユーザ・モードで実行し始めてもよい。一実施形態では、状態Ｋｅｒｎｅｌｃａｃｈｅ ７０７にあるデバイスは、デバイスのオペレーティング・システム・コンポーネントを復元しまたは更新するために、ＤＦＵモードに入って、結合されたホスト・コンピュータからルート・イメージを受信してもよい。

図８は、ホストからデバイスまでソフトウェア・コンポーネントを安全に復元するためのプロセスの一実施形態を示すフローチャートである。例えば、プロセス８００は、図１および／または図５に示されるようなシステムによって実施されてもよい。一実施形態では、プロセス８００の処理論理は、ブロック８０１で、デバイスをブート・デバイスとして構成してもよい。ブート・デバイスは、ＤＦＵモードにあってもよい。ユーザは、ブート・デバイスをＤＦＵモードへと構成するために、デバイスの通常のブート間、デバイスのボタンを押してもよい。プロセス８００の処理論理は、損傷を受けたアプリケーション・ソフトウェアを修復し、古いアプリケーション・ソフトウェアを更新し、ファームウェア・コンポーネントをインストールし、またはデバイスに格納された既存のユーザ・データを管理するために、デバイス・ユーザによって意図的にアクティブ化されてもよい。ブロック８０３で、一実施形態によれば、プロセス８００の処理論理は、ホスト・コンピュータとのネットワーク接続を確立してもよい。デバイスとホスト・コンピュータは、図５に示されるようなネットワーク・インターフェースを介して接続されてもよい。Ａｐｐｌｅ Ｃｏｍｐｕｔｅｒ Ｉｎｃ．社からのｉＴｕｎｅなどの復元ソフトウェアが、デバイスと通信するためにホスト・コンピュータ上で実行されていることがある。プロセス８００の処理論理は、ブロック８０５で、ネットワーク接続を介して、復元モードにあるようなデバイスを識別するためのステータスをホスト・コンピュータに公開してもよい。復元モードのデバイスは、ＤＦＵモードにもあり得る。一実施形態では、ステータスは、デバイスＩＤおよび／または製品ＩＤなどの情報を含んでもよい。ステータスは、ホスト・コンピュータからの必要なコード・イメージの表示を含んでもよい。

一実施形態によれば、ブロック８０７で、プロセス８００の処理論理は、接続されたホスト・コンピュータからブート・イメージを受信してもよい。ブート・イメージは、図２に示されたＬＬＢ ２２９やｉＢｏｏｔ ２３１などのブート・ローダを含んでもよい。一実施形態では、ブート・イメージは、図２のＫｅｒｎｅｌｃａｃｈｅ ２３３など、カーネル・キャッシュを含んでもよい。ブート・イメージは、ブロック８０５で、ホスト・コンピュータに公開されたステータスに基づいて受信されてもよい。一実施形態では、ブート・イメージは、図１のメモリ１０３など、デバイスのメモリ・コンポーネントにロードされてもよい。プロセス８００の処理論理は、ブロック８０９で、接続されたホスト・コンピュータからルート・イメージを受信してもよい。ルート・イメージは、デバイスのオペレーティング・システムのストリップダウン版に基づくＲＡＭディスクであってもよい。一実施形態では、ルート・イメージは、復元アプリケーションを含んでもよい。

一実施形態によれば、ブロック８１１で、プロセス８００の処理論理は、接続されたホスト・コンピュータから、受信されたブート・イメージの実行のコマンドを受信してもよい。ブート・イメージは、ブート・ローダであってもよい。それに応答して、プロセス８００の処理論理は、ブロック８１３で、ブート・イメージが信頼できることを検証してもよい。一実施形態では、プロセス８００の処理論理は、図１のチップ１０５など、セキュアＲＯＭチップに基づいてブート・イメージが信頼され得るかどうか決定するために、図６に示されるようなプロセスを実施してもよい。一実施形態では、プロセス８００の処理論理は、ブロック８１５で、信頼できるブート・イメージを実行することによって、接続されたホスト・コンピュータから受信されたＫｅｒｎｅｌｃａｃｈｅが信頼できることを検証してもよい。プロセス８００の処理論理は、図１のフィンガープリント１２３など、デバイスに格納されたルート証明書フィンガープリントに基づいてＫｅｒｎｅｌｃａｃｈｅが信頼され得るかどうか決定するために、図６に示されるようなプロセスを実施してもよい。ブロック８１７で、プロセス８００の処理論理は、信頼できるＫｅｒｎｅｌｃａｃｈｅを実行することによって、ルート・イメージからの復元デーモン・アプリケーションが信頼できることを検証してもよい。一実施形態では、プロセス８００の処理論理は、ルート・イメージが信頼できるコード・イメージであることを検証することによって、復元デーモン・アプリケーションが信頼され得ると決定してもよい。プロセス８００の処理論理は、ルート・イメージに含まれた復元デーモン・アプリケーションが信頼され得るかどうか決定するために、図６に示されるようなプロセスを実施してもよい。

一実施形態によれば、ブロック８１９で、プロセス８００の処理論理は、ソフトウェア復元オペレーションを実施するために、復元デーモン・アプリケーションを介してホスト・コンピュータからコマンド呼出しを受信し実行してもよい。一実施形態では、ソフトウェア復元オペレーションは、大容量記憶装置のファイル・システムの分割およびフォーマット、デバイス・レベルの復元、または新しいファームウェアのデバイスへのロードを含んでもよい。処理論理は、デバイス内で復元デーモンを起動するために、ルート・イメージに含まれたＯＳを開始してもよい。一実施形態では、ＯＳの減少した部分または最小部分だけが開始される。このデーモン・アプリケーションは、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ：拡張可能マークアップ言語）プロトコルに基づいて、接続されたホスト・コンピュータ内で実行される復元ソフトウェアと通信してもよい。一実施形態では、復元デーモンは、ホスト・コンピュータ上で実行される復元ソフトウェアが、デバイスによって実行される任意のコマンドを発行することを可能にしてもよい。コマンドは、ＲＡＭディスクに含まれた任意のツールを実行し、かつ／またはライブラリ呼出しを行うことを含んでもよい。一実施形態では、コマンドは、大容量記憶装置に格納されたソフトウェアのセット全体およびデバイスのプログラマブルＲＯＭの置換えを引き起こしてもよい。ブロック８２１で、プロセス８００の処理論理は、接続されたホスト・コンピュータから、デバイスを再開するコマンドを受信してもよい。それに応答して、プロセス８００の処理論理は、デバイスを再設定してもよい。その後に、デバイスは、デバイスの大容量記憶装置に格納されたオペレーティング・システムからリブートしてもよい。

図９は、ホストからデバイスまでアプリケーションを安全に更新するためのプロセスの一実施形態を示すフローチャートである。例えば、プロセス９００は、図１および／または図５に示されるようなシステムによって実施されてもよい。プロセス９００の処理論理は、ブロック９０１で、ホスト・コンピュータとのネットワーク接続を確立してもよい。デバイスとホスト・コンピュータは、図５に示されるようなネットワーク・インターフェースを介して接続されてもよい。Ａｐｐｌｅ Ｃｏｍｐｕｔｅｒ Ｉｎｃ．社からのｉＴｕｎｅなどの更新ソフトウェアが、デバイスと通信するためにホスト・コンピュータ上で実行されていることがある。プロセス８００の処理論理は、ブロック８０３で、ネットワーク接続を介して、更新モードにあるようなデバイスを識別するためのステータスをホスト・コンピュータに公開してもよい。更新モードのデバイスは、ＤＦＵモードにもあり得る。一実施形態では、ステータスは、デバイスＩＤおよび／または製品ＩＤなどの情報を含んでもよい。ステータスは、デバイス内に現在常駐しているアプリケーションのバージョンＩＤの表示を含んでもよい。

ブロック９０５で、一実施形態によれば、プロセス９００の処理論理は、接続されたホスト・コンピュータからのコード・イメージを受信してもよい。コード・イメージは、ブロック９０３で、ホスト・コンピュータによって受信された、公開されたステータスからのバージョンＩＤに基づいて、アプリケーションの最新版に関連するソフトウェア・パッケージを含んでもよい。一実施形態では、コード・イメージは、図１に示されるようなメモリ１０３など、デバイスのメモリ・コンポーネントにロードされてもよい。ブロック９０７で、一実施形態によれば、プロセス９００の処理論理は、コード・イメージが信頼できることを検証してもよい。プロセス９００の処理論理は、図１に示されたチップ１０５内のフィンガープリント１２３など、セキュアＲＯＭチップ内のルート証明書のフィンガープリントに基づいてコード・イメージが信頼され得るかどうか決定するために、図６に示されるようなプロセスを実施してもよい。一実施形態では、プロセス９００の処理論理は、ブロック９０９で、検証されたコード・イメージを実行して、含まれたソフトウェア・パッケージからファイルをアンパックし、デバイスのファイル・システム内にそれらのファイルを置いてもよい。ソフトウェア・パッケージからのファイルは、新しいファイル、またはデバイスの既存ファイルの最新版であってもよい。プロセス９００の処理論理は、デバイスのファイル・システム内にファイルを置く前に、ファイルが漏洩されておらず、または破損されていないことを保証するために、ソフトウェア・パッケージからのファイルに対して保全性チェックを実施してもよい。一実施形態では、ファイルの保全性は、ファイルの中身へのハッシュによる署名に基づいてチェックされてもよい。ブロック９１１で、プロセス９００の処理論理は、デバイス内に格納されたオペレーティング・システムからリブートするために、デバイスを再設定してもよい。

図１０は、検証されないコード・イメージを実行するプロセスの一実施形態を示すフローチャートである。例えば、プロセス１０００は、図１に示されるようなシステムによって実施されてもよい。ブロック１００１で、プロセス１０００の処理論理は、図１のＵＩＤ １１９など、デバイス内のセキュアＲＯＭのＵＩＤへのアクセスをディセーブルしてもよい。一実施形態では、信頼できるコード・イメージは、実行されるとき、ＵＩＤへのアクセスをオフにするように構成されてもよい。別の実施形態では、デバイスのハードウェア・スイッチは、ＵＩＤへのアクセスをオフにする設定を含んでもよい。ＵＩＤのアクセス構成は、デバイスの診断またはテスト要件によって指定されてもよい。信頼できるコード・イメージは、図１のコード１１５など、デバイスのセキュアＲＯＭ内のコードによって検証されたブート・イメージであってもよい。一実施形態では、検証は、図６に示されたプロセスに類似のプロセスで実施されてもよい。ブート・イメージは、図２に示されるように、ＬＬＢ ２２５またはｉＢｏｏｔ ２２７であってもよい。ブロック１００３で、プロセス１０００の処理論理は、図１のＲＡＭ １１１など、デバイスのメモリ・コンポーネントにコード・イメージをロードしてもよい。一実施形態では、プロセス１０００の処理論理は、現在実行されている、信頼できるコード・イメージの構成に基づいて、コード・イメージをロードしてもよい。コード・イメージは、外部ネットワーク接続、またはデバイスに結合された大容量記憶装置からロードされてもよい。一実施形態では、コード・イメージは、デバイスの診断ソフトウェアを含んでもよい。

ブロック１００５で、プロセス１０００の処理論理は、コード・イメージを実行することにより、デバイス・ハードウェアにアクセスするためのプログラミング・インターフェースをアクティブ化してもよい。デバイス・ハードウェアは、デバイス・ハードウェア・パラメータ値を読み取りまたは設定することによってアクセスされてもよい。処理論理は、コード・イメージが漏洩されていないか（例えば破損していないか）どうか決定するために、ロードされたコード・イメージからハッシュ値を導出してもよい。この決定は、導出されたハッシュ値と、コード・イメージからのヘッダ値の比較に基づいてもよい。一実施形態では、プロセス１０００の処理論理は、ブロック１００７で、ＵＩＤが非アクティブであると決定してもよい。デバイス・ハードウェアにアクセスするためのプログラミング・インターフェースは、ＵＩＤがアクティブかどうか決定するために、図１のコード１１５など、セキュアＲＯＭ内のコードの実行を引き起こしてもよい。ブロック１００９で、プロセス１０００の処理論理は、デバイス・ハードウェアにアクセスせずに、コード・イメージの実行を続ける。一実施形態では、デバイス・ハードウェアへのアクセスは、関連するＵＩＤがアクティブかどうかに基づいて、デバイスのセキュアＲＯＭ内のコードによって制御されてもよい。別の実施形態では、ユーザ・データは、ＵＩＤがアクティブでない場合は、アクセス可能でないことがある。検証されないアプリケーションがデバイスにロードされ実行されるときでも、ＵＩＤがアクティブでない場合には、デバイス・ハードウェアまたはユーザの機密データは漏洩され得ない。

図１１は、本発明の一実施形態で使用され得るデータ処理システムの一例を示している。例えば、システム１１００は、図５に示されるようなホストを含んで実装されてもよい。図１１は、コンピュータ・システムの様々なコンポーネントを示しているが、こうした詳細は本発明に関係しないので、特定のアーキテクチュアまたはコンポーネントの相互接続のやり方を表すものではないことに留意されたい。より少ないコンポーネント、または恐らくより多くのコンポーネントを有するネットワーク・コンピュータおよび他のデータ処理システムも本発明で使用され得ることも理解されよう。

図１１に示されるように、データ処理システムの形のコンピュータ・システム１１００は、マイクロプロセッサ１１０５に結合されたバス１１０３と、ＲＯＭ（読取り専用メモリ）１１０７と、揮発性ＲＡＭ １１０９と、不揮発性メモリ１１１１とを含む。マイクロプロセッサ１１０５は、メモリ１１０７、１１０９、１１１１から命令を取り出し、上述のオペレーションを実施する命令を実行してもよい。バス１１０３は、これらの様々なコンポーネントを共に相互接続し、またこれらのコンポーネント１１０５、１１０７、１１０９、１１１１を表示コントローラおよび表示デバイス１１１３、ならびにマウス、キーボード、モデム、ネットワーク・インターフェース、プリンタ、および当技術分野でよく知られている他のデバイスであり得る入出力（Ｉ／Ｏ：ｉｎｐｕｔ／ｏｕｔｐｕｔ）デバイスなどの周辺デバイスにも相互接続する。一般に、入出力デバイス１１１５は、入出力コントローラ１１１７を介してシステムに結合される。揮発性ＲＡＭ（ランダム・アクセス・メモリ）１１０９は一般に、メモリ内のデータをリフレッシュし、または維持するために継続的に電力を必要とするダイナミックＲＡＭ（ＤＲＡＭ）として実装される。

大容量記憶装置１１１１は一般に、磁気ハード・ドライブ、磁気光ドライブ、光ドライブ、ＤＶＤ ＲＡＭ、フラッシュ・メモリ、またはシステムから電力が取り除かれた後でもデータ（例えば大量のデータ）を維持する他のタイプのメモリ・システムである。一般に大容量記憶装置１１１１はやはりランダム・アクセス・メモリであるが、これは必須ではない。図１１は、大容量記憶装置１１１１がデータ処理システム内のコンポーネントの残りに直接結合されたローカル・デバイスであることを示しているが、本発明は、モデム、イーサネット・インターフェースまたは無線ネットワークなどのネットワーク・インターフェースを介してデータ処理システムに結合されたネットワーク記憶デバイスなど、システムから離れた不揮発性メモリを使用してもよいことが理解されよう。バス１１０３は、当技術分野ではよく知られているように、様々なブリッジ、コントローラおよび／またはアダプタを介して互いに接続された１つまたは複数のバスを含んでもよい。

図１２は、本発明の一実施形態で使用され得る別のデータ処理システムの一例を示している。例えば、システム１２００は、図１に示されるようなシステムの一部として実装されてもよい。図１２に示されたデータ処理システム１２００は、１つまたは複数のマイクロプロセッサとすることもでき、またはチップ集積回路上のシステムとすることもできる処理システム１２１１を含み、このシステムは、処理システムによって実行するデータおよびプログラムを格納するためのメモリ１２０１をも含む。システム１２００は、オーディオ入出力サブシステム１２０５をも含み、このオーディオ入出力サブシステムは、例えば音楽を再生し、またはスピーカおよびマイクロホンを介して電話機能性を提供するために、マイクロホンとスピーカとを含んでもよい。

表示コントローラおよび表示デバイス１２０７は、ユーザへの視覚的なユーザ・インターフェースを提供し、このデジタル・インターフェースは、ＯＳ Ｘオペレーティング・システム・ソフトウェアを実行するとき、Ｍａｃｉｎｔｏｓｈコンピュータ上に示されるものに類似のグラフィカル・ユーザ・インターフェースを含んでもよい。システム１２００は、図１１のシステム１１００など、別のデータ処理システムと通信するために１つまたは複数の無線トランシーバ１２０３をも含む。無線トランシーバは、ＷｉＦｉトランシーバ、赤外線トランシーバ、Ｂｌｕｅｔｏｏｔｈトランシーバおよび／または無線携帯電話トランシーバであってもよい。追加のコンポーネント（図示せず）は、特定の実施形態ではシステム１２００の一部とすることもでき、また特定の実施形態では、図１２に示されるのより少ないコンポーネントをデータ処理システム内で使用することもできることが理解されよう。

データ処理システム１２００は、ユーザがシステムに入力を提供することを可能にするために設けられる１つまたは複数の入力デバイス１２１３をも含む。これらの入力デバイスは、キーパッド、キーボード、タッチ・パネルまたはマルチ・タッチ・パネルであってもよい。データ処理システム１２００は、ドック用のコネクタであり得るオプションの入出力デバイス１２１５をも含む。当技術分野においてよく知られているように、様々なコンポーネントを相互接続するために１つまたは複数のバス（図示せず）を使用してもよいことが理解されよう。図１２に示されたデータ処理システムは、手持ち式コンピュータ、携帯情報端末（ＰＤＡ：ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）、ＰＤＡのような機能性を有する携帯電話、携帯電話を含む手持ち式コンピュータ、ｉＰｏｄなどのメディア・プレーヤー、あるいは１つのデバイス内でＰＤＡおよび携帯電話と組み合わされたメディア・プレーヤーなど、これらのデバイスの側面または機能を組み合わせるデバイスであってもよい。他の実施形態では、データ処理システム１２００は、ネットワーク・コンピュータ、別のデバイス内の組込み処理デバイス、あるいは図１２に示されるのより少ないコンポーネント、または恐らくより多くのコンポーネントを有する他のタイプのデータ処理システムであってもよい。

本発明の少なくとも特定の実施形態は、携帯型音楽および／またはビデオ・メディア・プレーヤーなどのデジタル・メディア・プレーヤーの一部であってもよく、このデジタル・メディア・プレーヤーは、メディアを提示するためのメディア処理システム、メディアを格納するための記憶デバイスを含んでもよく、アンテナ・システムおよびメディア処理システムに結合された無線周波数（ＲＦ：ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）トランシーバ（例えば携帯電話用のＲＦトランシーバ）をさらに含んでもよい。特定の実施形態では、リモート記憶デバイス内に格納されたメディアは、ＲＦトランシーバを介してメディア・プレーヤーに送信されてもよい。メディアは、例えば、音楽または他のオーディオ、静止画、または動画のうちの１つまたは複数であってもよい。

携帯型メディア・プレーヤーは、カリフォルニア州ＣｕｐｅｒｔｉｎｏのＡｐｐｌｅ Ｃｏｍｐｕｔｅｒ Ｉｎｃ．社からのｉＰｏｄ（登録商標）やｉＰｏｄ Ｎａｎｏ（登録商標）メディア・プレーヤー上のクリック・ホイール入力デバイス、タッチスクリーン入力デバイス、押しボタン・デバイス、移動可能なポインティング入力デバイスまた他の入力デバイスなど、メディア選択デバイスを含んでもよい。メディア選択デバイスは、記憶デバイスおよび／またはリモート記憶デバイス内に格納されたメディアを選択するために使用されてもよい。携帯型メディア・プレーヤーは、少なくとも特定の実施形態では、表示デバイスを含んでもよく、この表示デバイスは、入力デバイスによって選択されており、またスピーカまたはイヤホンによって、または表示デバイス上に、あるいは表示デバイスとスピーカもしくはイヤホンの両方に提示されているメディアのタイトルまたは他の標識を表示するために、メディア処理システムに結合される。携帯型メディア・プレーヤーの例は、公開された米国特許出願第２００３／００９５０９６号および第２００４／０２２４６３８号に述べられており、両特許は、参照により本明細書に組み込まれる。

上記に述べられた内容の一部は、専用論理回路などの論理回路で、あるいはマイクロコントローラ、またはプログラム・コード命令を実行する他の形の処理コアで実装されてもよい。したがって、上記の議論によって教示されたプロセスは、これらの命令を実行するマシンに特定の機能を実施させるマシン実行可能命令などのプログラム・コードで実施されてもよい。この文脈では、「マシン」は、中間形式（すなわち「抽象的な」）命令をプロセッサ固有の命令（例えば「仮想マシン」（例えばＪａｖａ（登録商標）仮想マシン）、インタープリタ、共通言語ランタイム、高水準言語仮想マシンなどの抽象実行環境）に変換するマシン、ならびに／あるいは汎用プロセッサおよび／または専用プロセッサなど、命令を実行するように設計された半導体チップ（例えばトランジスタで実装された「論理回路」）に配置された電子回路であってもよい。上記の議論によって教示されたプロセスは、プログラム・コードの実行なしにプロセス（またはその一部）を実施するように設計された電子回路によって（マシンの代わりに、またはマシンと組み合わせて）実施することもできる。

本発明は、本明細書に述べられたオペレーションを実施するための装置にも関する。この装置は、必要な目的のために特別に構築されてもよく、あるいは、それは、コンピュータに格納されたコンピュータ・プログラムによって選択的にアクティブ化され、または再構成された汎用コンピュータを備えてもよい。こうしたコンピュータ・プログラムは、それだけに限らないが、フロッピー（登録商標）ディスク、光ディスク、ＣＤ−ＲＯＭおよび光磁気ディスク含めた任意のタイプのディスク、読取り専用メモリ（ＲＯＭ）、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気または光カード、あるいは電子命令を格納するのに適しており、それぞれがコンピュータ・システム・バスに接続された任意のタイプのメディアなど、コンピュータ読取り可能記憶媒体に格納されてもよい。

マシン読取り可能媒体は、マシン（例えばコンピュータ）によって読取り可能な形で情報を格納しまたは送信するための任意の機構を含む。例えば、マシン読取り可能媒体には、読取り専用メモリ（「ＲＯＭ」）、ランダム・アクセス・メモリ（「ＲＡＭ」）；磁気ディスク記憶媒体；光記憶媒体；フラッシュ・メモリ・デバイス；電気、光、音響または他の形の伝搬信号（例えば搬送波、赤外線信号、デジタル信号など）などが含まれる。

プログラム・コードを格納するために、製品が使用されてもよい。プログラム・コードを格納する製品は、それだけに限らないが、１つまたは複数のメモリ（例えば１つまたは複数のフラッシュ・メモリ、ランダム・アクセス・メモリ（スタティック、ダイナミックまたはその他））、光ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気または光カード、あるいは電子の命令を格納するのに適した他のタイプのマシン読取り可能媒体として具現化され得る。プログラム・コードは、（例えば通信リンク（例えばネットワーク接続）を介して）伝搬媒体内に具現化されたデータ信号を用いて、リモート・コンピュータ（例えばサーバ）から要求元コンピュータ（例えばクライアント）にダウンロードすることもできる。

上記の詳細説明は、コンピュータ・メモリ内のデータ・ビットに対するオペレーションのアルゴリズムおよび記号表現に関して提示されている。これらのアルゴリズムの説明および表現は、データ処理の分野の当業者によって、その仕事の内容を他の当業者に最も有効に伝えるために使用されるツールである。アルゴリズムは、本明細書では、また一般には、所望の結果をもたらす自己一貫性のあるオペレーション・シーケンスと考えられる。これらのオペレーションは、物理量の物理的な操作を必要とするオペレーションである。必ずしもではないが、通常、これらの量は、格納され、転送され、組み合わされ、比較され、他のやり方で操作することができる電気的または磁気的信号の形を取る。主として一般的に使用するために、これらの信号をビット、値、要素、記号、文字、用語、数字などと呼ぶことが時として好都合であることが分かっている。

しかし、これらのおよび類似の用語はすべて、適切な物理量と関連付けられるものであり、これらの量に適用された便宜的なラベルにすぎないことに留意されたい。上記議論から明らかであるように特に述べられていない限り、「処理（ｐｒｏｃｅｓｓｉｎｇ）」、「コンピューティング（ｃｏｍｐｕｔｉｎｇ）」、「計算（ｃａｌｃｕｌａｔｉｎｇ）」、「決定（ｄｅｔｅｒｍｉｎｉｎｇ）」または「表示（ｄｉｓｐｌａｙｉｎｇ）」などの用語を使用した議論は、説明全体を通して、コンピュータ・システムのレジスタおよびメモリ内の物理（電子）量として表されたデータを操作して、コンピュータ・システム・メモリまたはレジスタ、あるいは他のこうした情報記憶装置、伝送または表示デバイス内の物理量として同様に表された他のデータに変換するコンピュータ・システムまたは類似の電子コンピューティング・デバイスの動作およびプロセスを指すことが理解されよう。

本明細書に提示されたプロセスおよび表示は、どんな特定のコンピュータまたは他の装置にも本質的には関係ない。様々な汎用システムは、本明細書の教示に従ってプログラムと共に使用されてもよく、あるいは、述べられたオペレーションを実施するより専門の装置を構築することが好都合であると分かり得る。様々なこれらのシステムに必要な構造は、下記の説明から明らかになる。さらに、本発明について、特定のプログラミング言語に関して述べられていない。本明細書に述べられた本発明の教示を実施するために、様々なプログラミング言語が使用され得ることが理解されよう。

上記議論は、本発明のいくつかの例示的な実施形態について述べるものにすぎない。こうした議論、添付の図面および特許請求の範囲から、本発明の精神および範囲から逸脱せずに様々な修正が行われ得ることが当業者には容易に認識されよう。

１０１ 接続インターフェース； １０３ メモリ； １０５ チップ；
１０９ 記憶装置（例えばフラッシュ）； １１３ セキュアＲＯＭ；
１１５ コード； １１７ データ； １２３ フィンガープリント；
２３５ ＯＳコンポーネント。

Claims (8)

1. デバイスをブートさせるために、前記デバイスのメインメモリに、第１のヘッダ値を有する第１のコードイメージをロードするステップと、
   前記デバイスのシステムコードを実行し、前記第１のヘッダ値が、前記第１のコードイメージの全体についての第１の署名を有するか否かを、前記デバイスのＲＯＭ（読取り専用メモリ）内に格納されたキーを用いて検証するステップと、
   前記ロードされた前記第１のコードイメージの検証が成功した場合、前記デバイスの前記メインメモリにロードされ、検証された前記第１のコードイメージを実行するステップと、
   前記ロードされた前記第１のコードイメージの検証が成功しなかった場合、ホストより第２のコードイメージを受信するステップと、
   前記ホストからの前記第２のコードイメージの受信に応じて、前記ＲＯＭに根源がある一連の証明書に従って前記第２のコードイメージを認証するステップと、
   前記第２のコードイメージの認証が成功した場合、前記第２のコードイメージ全体に対する第２の署名を、前記キーを用いて前記第２のコードイメージの第２のヘッダ値として署名するステップと、
   前記第２のコードイメージを前記第２のヘッダ値と共に記憶するステップと、
   を有するコンピュータにて実行されることを特徴とする方法。
2. 前記デバイスのブートには第１の状態、第２の状態、及ぶ第３の状態を含む複数の状態があって、
   前記第１のコードイメージは第１の状態にて検証され、当該第１のコードイメージの検証が成功した場合に前記デバイスは前記第１の状態から前記第２の状態に移行し、
   前記第２のコードイメージが前記第３の状態にて認証され、前記第２のコードイメージの認証が成功した場合には、前記デバイスは前記第３の状態から前記第２の状態に移行し、前記デバイスのブートを継続する
   ことを特徴とする請求項１に記載の方法。
3. コンピュータが読み込み実行することで、前記コンピュータに、
   デバイスをブートさせるために、前記デバイスのメインメモリに、第１のヘッダ値を有する第１のコードイメージをロードするステップと、
   前記デバイスのシステムコードを実行し、前記第１のヘッダ値が、前記第１のコードイメージの全体についての第１の署名を有するか否かを、前記デバイスのＲＯＭ（読取り専用メモリ）内に格納されたキーを用いて検証するステップと、
   前記ロードされた前記第１のコードイメージの検証が成功した場合、前記デバイスの前記メインメモリにロードされ、検証された前記第１のコードイメージを実行するステップと、
   前記ロードされた前記第１のコードイメージの検証が成功しなかった場合、ホストより第２のコードイメージを受信するステップと、
   前記ホストからの前記第２のコードイメージの受信に応じて、前記ＲＯＭに根源がある一連の証明書に従って前記第２のコードイメージを認証するステップと、
   前記第２のコードイメージの認証が成功した場合、前記第２のコードイメージ全体の署名を、前記キーを用いて前記第２のコードイメージの第２のヘッダ値として署名するステップと、
   前記第２のコードイメージを前記第２のヘッダ値と共に記憶するステップ
   を実行させるためのプログラムを格納したコンピュータ可読記憶媒体。
4. 前記デバイスのブートには第１の状態、第２の状態、及ぶ第３の状態を含む複数の状態があって、
   前記第１のコードイメージは第１の状態にて検証され、当該第１のコードイメージの検証が成功した場合に前記デバイスは前記第１の状態から前記第２の状態に移行し、
   前記第２のコードイメージが前記第３の状態にて認証され、前記第２のコードイメージの認証が成功した場合には、前記デバイスは前記第３の状態から前記第２の状態に移行し、前記デバイスのブートを継続する
   ことを特徴とする請求項３に記載のコンピュータ可読記憶媒体。
5. デバイスをブートさせるために、前記デバイスのメインメモリに、第１のヘッダ値を有する第１のコードイメージをロードする手段と、
   前記デバイスのシステムコードを実行し、前記第１のヘッダ値が、前記第１のコードイメージの全体についての第１の署名を有するか否かを、前記デバイスのＲＯＭ（読取り専用メモリ）内に格納されたキーを用いて検証する手段と、
   前記ロードされた前記第１のコードイメージの検証が成功した場合、前記デバイスの前記メインメモリにロードされ、検証された前記第１のコードイメージを実行する手段と、
   前記ロードされた前記第１のコードイメージの検証が成功しなかった場合、ホストより第２のコードイメージを受信する手段と、
   前記ホストからの前記第２のコードイメージの受信に応じて、前記ＲＯＭに根源がある一連の証明書に従って前記第２のコードイメージを認証する手段と、
   前記第２のコードイメージの認証が成功した場合、前記第２のコードイメージ全体の第２の署名を、前記キーを用いて前記第２のコードイメージの第２のヘッダ値として署名する手段と、
   前記第２のコードイメージを前記第２のヘッダ値と共に記憶する手段と、
   を有することを特徴とする装置。
6. 電子デバイスであって、
   システムコードが埋め込まれていると共に、前記電子デバイスを一意に識別するためのキーを記憶しているＲＯＭ（読取り専用メモリ）と、
   第１のコードイメージを格納するための大容量記憶装置と、
   メインメモリと、
   前記ＲＯＭ、前記大容量記憶装置および前記メインメモリに接続されたプロセッサとを備え、
   前記プロセッサは、
   前記電子デバイスをブートさせるために、前記電子デバイスの前記メインメモリに、第１のヘッダ値を有する前記第１のコードイメージをロードし、
   前記ＲＯＭ内に記憶された前記システムコードを実行し、前記第１のヘッダ値が、前記第１のコードイメージの全体についての第１の署名を有するか否かを、前記キーを用いて検証し、
   前記ロードされた前記第１のコードイメージの検証が成功した場合、前記メインメモリ内の、検証された前記第１のコードイメージを実行し、
   前記ロードされた前記第１のコードイメージの検証が成功しなかった場合、ホストより第２のコードイメージを受信し、
   前記ホストからの前記第２のコードイメージの受信に応じて、前記ＲＯＭに根源がある一連の証明書に従って前記第２のコードイメージを認証し、
   前記第２のコードイメージの認証が成功した場合、前記第２のコードイメージ全体に対する第２の署名を、前記キーを用いて前記第２のコードイメージの第２のヘッダ値として署名し、
   前記第１のコードイメージの検証が成功しなかった場合の当該第１のコードイメージを修復するため、前記第２のコードイメージを前記第２のヘッダ値ともに前記大容量記憶装置に格納する
   ことを特徴とする電子デバイス。
7. デバイスをブートさせるために、オペレーティングシステム（ＯＳ）のカーネルイメージを位置づけるステップと、
   前記カーネルイメージの位置づけが成功した場合、前記カーネルイメージを実行し、前記デバイスに対する前記ＯＳのシステムコンポーネントをロードするステップとを有し、
   前記カーネルイメージを位置づけるステップは、
   第１のヘッダ値を有する第１のコードイメージを前記デバイスのメインメモリにロードするステップと、
   ここで、前記第１のコードイメージは前記デバイスの大容量記憶装置コンポーネントを有効にする、
   前記デバイスのシステムコードを実行し、前記第１のヘッダ値が、前記第１のコードイメージの全体についての第１の署名を有するか否かを、前記デバイスのＲＯＭ（読取り専用メモリ）内に格納されたキーを用いて検証するステップと、
   前記ロードされた前記第１のコードイメージの検証が成功した場合、前記デバイスの前記メインメモリにロードされ、検証された前記第１のコードイメージを実行するステップと、
   前記ロードされた前記第１のコードイメージの検証が成功しなかった場合、ホストより第２のコードイメージを受信するステップと、
   前記ホストからの前記第２のコードイメージの受信に応じて、前記ＲＯＭに根源がある一連の証明書に従って前記第２のコードイメージを認証するステップと、
   前記第２のコードイメージの認証が成功した場合、前記第２のコードイメージ全体に対する第２の署名を、前記キーを用いて前記第２のコードイメージの第２のヘッダ値として署名するステップと、
   前記認証が成功した前記第２のコードイメージを実行するステップと、
   前記第２のコードイメージを前記第２のヘッダ値と共に記憶するステップと、
   を有するコンピュータにて実行される方法。
8. データ処理システムであって、
   デバイスをブートするために、オペレーティングシステム（ＯＳ）のカーネルイメージを位置づける手段と、
   前記カーネルイメージの位置づけが成功した場合、前記カーネルイメージを実行し、前記デバイスに対する前記ＯＳのシステムコンポーネントをロードする手段とを有し、
   前記カーネルイメージを位置づける手段は、
   第１のヘッダ値を有する第１のコードイメージを前記デバイスのメインメモリにロードし、
   ここで、前記第１のコードイメージは前記デバイスの大容量記憶装置コンポーネントを有効にする、
   前記デバイスのシステムコードを実行し、前記第１のヘッダ値が、前記第１のコードイメージの全体についての第１の署名を有するか否かを、前記デバイスのＲＯＭ内に格納されたキーを用いて検証し、
   前記ロードされた前記第１のコードイメージの検証が成功した場合、前記デバイスの前記メインメモリにロードされ、検証された前記第１のコードイメージを実行し、
   前記ロードされた前記第１のコードイメージの検証が成功しなかった場合、ホストより第２のコードイメージを受信し、
   前記ホストからの前記第２のコードイメージの受信に応じて、前記ＲＯＭに根源がある一連の証明書に従って前記第２のコードイメージを認証し、
   前記第２のコードイメージの認証が成功した場合、前記第２のコードイメージ全体に対する第２の署名を、前記キーを用いて前記第２のコードイメージの第２のヘッダ値として署名し、
   前記認証が成功した前記第２のコードイメージを実行し、
   前記第２のコードイメージを前記第２のヘッダ値と共に記憶する
   ことを特徴とするデータ処理システム。

Images