オプショナルなコンポーネントを伴うセキュアブートの方法
【課題】装置がオプショナルなコンポーネントを有する場合でも、更新された証明書のセットを装置毎にカスタマイズして作成することなく、証明書を更新できるようにする。
【解決手段】サーバ１１８は、当該装置でアクティブ化可能なソフトウェアの候補全てを含む、更新された証明書のセットを作成する。そして携帯装置１１０は、サーバ１１８からそのセットを受信し、携帯装置１１０でアクティブ化するソフトウェアに対応する更新された証明書を検索する。
【解決手段】サーバ１１８は、当該装置でアクティブ化可能なソフトウェアの候補全てを含む、更新された証明書のセットを作成する。そして携帯装置１１０は、サーバ１１８からそのセットを受信し、携帯装置１１０でアクティブ化するソフトウェアに対応する更新された証明書を検索する。
【発明の詳細な説明】
【背景技術】
【０００１】
例えば、“the Trusted Computing Group's (TCG) Mobile Trusted Module (MTM) documents TCG Mobile Reference Architecture version 1.0 12 June 2007”、および、“TCG Mobile Trusted Module Specification version 1.0 12 June 2007”のような先導的な先行文献は、装置をどのようにして、保証され、また、信頼された方法で起動するかを記述している。これらの方法は、信頼性や安全性がブートプロセスの間保持されるということを確実にするため徹底的に見直されてきており、その結果、安全にブートができる装置の実装を要求する人々に有用な基準を提供している。このセキュアブートプロセスのキーコンポーネントは、RIM証明書である。これは、現在期待されるプラットフォームの状態がどのようなものであるべきかを定義する署名つきの構造体である。プラットフォームの状態は、プラットフォーム設定レジスタ(PCRs)の集合に対するハッシュによって表され、各ＰＣＲは一般に定義されたハッシュ値を含む。これらのPCRは、完全性測定（integrity measurement）情報として用いられるものであり、期待される装置の状態を定義するためにRIM証明書に記録されていてもよい。さらに、RIM証明書はまた、もし現在の状態が検証される場合に、拡張されるべきPCRを特定する。この拡張の処理では、指定されたPCRの値を取得し、RIM証明書内で定義される新たな既知の値と以前のPCR値とを連結させた値に基づいて新たなハッシュ値を算出する。TCGによって定義される典型的なセキュアブートシーケンスは、コアコンポーネントの初期化および自己検証から開始する。ここで、コアコンポーネントとは、検証および測定の信頼性のルート(RTV+RTM)、MTM自体、および関連するコアMTMインタフェースコンポーネント等である。次に、ファームウェアの他の部分をサポートする追加コンポーネントが、信頼された方法で起動される。ここで信頼された方法とは、例えば、各追加コンポーネントの起動時に、先にブートされた他のコンポーネントによって検証されることである。そして、最後に、オペレーティングシステムが、クライアントアプリケーションに対して、MTMサービスへとアクセスする安全で信頼されたパスを提供するために起動される。
【０００２】
TCG仕様書は、携帯電話などの携帯端末ではリソースが限られていることを認識した上での監査機能を提供している。仕様書では、これらの監査の形態はMTMではオプショナルであると定義されているが、これは下記に示す問題を生じる。
【０００３】
TCG仕様書において、RIM証明書は更新することができる。しかし、TCG仕様書は、1つ以上のオプショナルなコンポーネントを有するシステムにおいてRIM証明書を更新する方法を示していない。
【０００４】
ここでオプショナルなコンポーネントとは、例えば、ユーザが追加契約した後にアクティブ化できるアプリケーションソフトウェアのことである。ここで、「アクティブ化された(または有効化された)」とは、そのアプリケーションソフトウェアの状態を、ユーザが実行可能な状態に変化させることである。そのソフトウェアがアクティブ化されていなければ、たとえそのアプリケーションソフトウェアがコンピュータに事前にインストールされているか、またはサーバからダウンロードされていても、ユーザはそのアプリケーションソフトウェアを使用することができない。
【０００５】
上述のように、オプショナルなコンポーネントがアクティブ化されているか否かは、例えば、各ユーザの決定による。よって、更新されたRIM証明書をコンピュータに送信するサーバは、アクティブ化されているコンポーネントに対応する更新された証明書を送信するために、各コンピュータにおいてどのコンポーネントがアクティブ化されているかを知っていなければならない。
【０００６】
しかし、コンピュータ毎にカスタマイズされたセットを作成するのは煩雑で、費用もかかる。
【０００７】
Zimmerらによる米国特許出願公開第2005/0138414号明細書では、オプショナルなコンポーネントを伴う検証されたブート方法が開示されているが、この課題の解決方法は教示されていない。
【０００８】
Schellらによる米国特許第6477648号明細書では、検証に失敗する可能性のあるオプショナルなコンポーネントを伴う検証されたブート方法が開示されているが、この課題の解決方法は教示されていない。
【０００９】
そこで、装置がオプショナルなコンポーネントを有する場合でも、更新された証明書のセットを装置毎にカスタマイズして作成することなく、証明書を更新する装置およびサーバが必要である。
【００１０】
［発明の概要］
この課題を解決するために、本発明によると、サーバに接続可能な装置は、各々が1つの証明書に割り当てられる複数のソフトウェアと、前記複数のソフトウェアに関連付けられ、かつ各々が前記複数のソフトウェア各々の検証に用いられる複数の証明書とを格納する格納手段と、前記複数のソフトウェアの1つを、前記装置で実行可能な前記複数のソフトウェアのうちの有効な1つのソフトウェアとして、前記装置に設定する設定手段と、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書を用いて、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証し、前記検証の後に、前記複数のソフトウェアのうちの前記有効かつ検証されたソフトウェアを実行する実行手段と、前記複数の証明書のうち、何れが前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに対応するかを検出することなく、更新すべきと前記サーバによって判定された所定の証明書に対応する複数の更新された証明書を前記サーバから受信する受信手段と、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書に対応する1つの更新された証明書を、前記受信した複数の更新された証明書から選択する選択手段とを備え、前記実行手段は前記1つの最新かつ選択された証明書を用いて前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証する。
【００１１】
この構成により、装置は、サーバがどの更新された証明書が有効なコンポーネントに対応するかを検出することなく生成した、更新された証明書を受信する。そして、装置は受信した更新された証明書から、更新対象の最新の証明書を選択する。よって、本発明の本態様によると、サーバが送信する証明書のセットをカスタマイズすることなく、証明書を適切に更新することが可能である。
【発明を実施するための最良の形態】
【００１２】
本発明の第1の態様によると、サーバに接続可能な装置は、各々が1つの証明書に割り当てられる複数のソフトウェアと、前記複数のソフトウェアに関連付けられ、かつ各々が前記複数のソフトウェア各々の検証に用いられる複数の証明書とを格納する格納手段と、前記複数のソフトウェアの1つを、前記装置で実行可能な前記複数のソフトウェアのうちの有効な1つのソフトウェアとして、前記装置に設定する設定手段と、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書を用いて、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証し、前記検証の後に、前記複数のソフトウェアのうちの前記有効かつ検証されたソフトウェアを実行する実行手段と、前記複数の証明書のうち、何れが前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに対応するかを検出することなく、更新すべきと前記サーバによって判定された所定の証明書に対応する複数の更新された証明書を前記サーバから受信する受信手段と、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書に対応する1つの更新された証明書を、前記受信した複数の更新された証明書から選択する選択手段とを備え、前記実行手段は前記1つの更新され選択された証明書を用いて前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証する。
【００１３】
本発明の第2の態様によると、前記サーバは、前記複数の更新された証明書を前記装置およびもう1つの別の装置に共通して送信する。
【００１４】
本発明の第3の態様によると、前記複数の更新された証明書は、前記複数のソフトウェアのうちの前記1つの有効なソフトウェアとは異なる、前記複数のソフトウェアのうちの1つのソフトウェアに関連する証明書に対応する更新された証明書を含む。
【００１５】
本発明の第4の態様によると、前記装置はさらに、前記1つの更新された証明書に基づき、前記複数のソフトウェアのうちの前記1つの有効なソフトウェアに関連する証明書を更新する更新手段を備え、前記実行手段は、前記更新手段が更新した証明書を用いて前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証する。
【００１６】
本発明の第5の態様によると、前記更新手段は、選択されなかった更新された証明書に対応する証明書を更新することなく、前記選択されなかった更新された証明書を、前記受信した複数の更新された証明書から削除する。
【００１７】
本発明の第6の態様によると、前記装置はさらに、前記装置の固有鍵である装置鍵を格納する装置鍵格納手段を備え、前記更新手段は、前記装置鍵を用いて前記1つの更新された証明書を変換し、前記変換された1つの更新された証明書で前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書を上書きすることにより、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書を更新する。
【００１８】
本発明の第7の態様によると、前記装置は、さらに、1つの証明書に対応する更新された証明書が、前記受信した複数の更新された証明書に含まれていないとき、前記1つの証明書が無効であると判定する無効化判定手段と、前記格納手段に格納されている前記1つの証明書を無効化する無効化手段とを備える。
【００１９】
この構成により、当該装置は、受信した更新された証明書の中に、当該証明書の最新版が含まれているか否かをチェックすることによって、どの証明書を無効化するべきか判定する。
【００２０】
本発明の本態様によると、当該装置はコンポーネント(およびそのコンポーネントに対応する証明書)を、その証明書を更新すると同時に無効化することができる。よって、本発明の本態様では、無効化リストなどの追加情報を送信することなく証明書を無効化することができる。
【００２１】
本発明の第8の態様によると、前記装置はさらに、前記設定手段が前記装置に、前記複数のソフトウェアのうちの1つを前記複数のソフトウェアのうちの前記有効な1つのソフトウェアとして設定したとき、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを示す許可フラグを格納するフラグ格納手段を備え、前記選択手段は、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書に対応する1つの更新された証明書を、前記フラグ格納手段に格納されている前記許可フラグに基づいて、前記受信した複数の更新された証明書から選択する。
【００２２】
本発明の第9の態様によると、前記装置はさらに、前記無効化手段が前記格納手段に格納されている前記1つの証明書を無効化するときに、カウンタ値をインクリメントするカウンタと、カウンタ値がインクリメントされたとき、前記許可フラグを含む管理情報に前記インクリメントされたカウンタ値を設定するカウンタ値設定手段と、前記管理情報に設定された前記カウンタ値を用いて前記管理情報が改竄されているか否かを判定する判定手段とを備える。
【００２３】
本発明の第10の態様によると、前記装置はさらに、前記許可フラグと前記カウンタ値とを含む前記管理情報の暗号技術的ハッシュ値を算出する算出手段と、前記算出された暗号技術的ハッシュ値に対応する検証値を格納する値格納手段と、前記選択手段が前記1つの更新された証明書を選択するために前記管理情報を用いる前に、前記格納された検証値と前記算出された暗号技術的ハッシュ値とを比較することにより、前記管理情報が改竄されているか否かを検証する検証手段を備える。
【００２４】
本発明の第11の態様によると、前記装置はさらに、前記複数のソフトウェアと前記複数の証明書の間のマッピングを示すマッピングデータを格納するマッピングデータ格納手段と、前記マッピングデータの暗号技術的ハッシュ値を算出する算出手段と、前記算出された暗号技術的ハッシュ値に対応する検証値を格納する値格納手段と、前記選択手段が前記1つの更新された証明書を選択する前に、前記格納された検証値と前記算出された暗号技術的ハッシュ値とを比較することにより、前記マッピングデータが改竄されているか否かを検証する検証手段を備え、前記選択手段は、前記マッピングデータに基づき前記1つの更新された証明書を選択する。
【００２５】
本発明の第12の態様によると、前記装置はさらに、前記無効化手段が前記格納手段に格納されている前記1つの証明書を無効化するときに、カウンタ値をインクリメントするカウンタと、カウンタ値がインクリメントされたとき、前記マッピングデータに前記インクリメントされたカウンタ値を割り当てるカウンタ値割り当て手段とを備え、前記算出手段は、前記マッピングデータと前記マッピングデータに割り当てられた前記カウンタ値とを用いて前記暗号技術的ハッシュ値を算出する。
【００２６】
＜本実施形態の概要＞
本実施形態は、ソフトウェアの検証に用いられる証明書を更新することができるシステムに関する。装置が1つ以上のオプショナルなコンポーネントを有する場合、どのコンポーネントをアクティブ化するかは、ユーザの決定次第である。よって通常、サーバは、アクティブなコンポーネントに対応する更新された証明書を送信するために、各装置においてどのコンポーネントがアクティブ化されているかを知っていなければならない。そしてサーバは、各装置のアクティブなコンポーネントに対応する、更新された証明書のカスタマイズされたセットを、各装置に送信する。
【００２７】
しかし、装置毎にカスタマイズされたセットを作成するのは煩雑で、費用もかかる。よって、本実施形態は、装置毎にカスタマイズされたセットを作成することなく、証明書を更新するシステムを示す。
【００２８】
さらに、従来技術においては、オプショナルなコンポーネントを無効化することができない。したがって、インストール後に脆弱であることが判明しても、オプショナルなコンポーネントを無効化することは不可能であった。コンポーネントを無効化するためには通常、無効なコンポーネントを示す無効化リストが各装置に送信される。しかし、例えば携帯電話システムにおいて、ユーザに無効化リストのダウンロードを強いることは、そのダウンロードにさえ通信費がかかることから、困難である。この通信費をユーザではなく製造業者が負担することも可能だが、この費用のために無効化リストのダウンロードまたは送信が困難になっていることには変わりはない。
【００２９】
よって、本発明は、コンポーネントを簡単かつ合理的に無効化できるシステムを示す。
【００３０】
本実施形態において、サーバは、当該装置でアクティブ化可能なソフトウェアの候補全てを含む、更新された証明書のセットを作成する。そして装置は、サーバからそのセットを受信し、装置でアクティブ化するソフトウェアに対応する更新された証明書を検索する。この構成により、サーバは、更新された証明書のセットを各装置用にカスタマイズする必要がない。
【００３１】
この構成により、本発明の本態様によると、サーバが送信する証明書のセットをカスタマイズすることなく、証明書を適切に更新することが可能である。
【００３２】
さらに、ソフトウェアを無効化するために、サ―バは無効なソフトウェアに対応する証明書をセットから除外する。また、受信したセットに1つ以上の証明書が含まれていないことが分かった場合は、装置はその証明書が無効であると判断する。装置は、無効な証明書を削除することでコンポーネントを無効化する。証明書が削除されると、その証明書に対応するコンポーネントの検証は必ず失敗する。その結果、そのコンポーネントもまた無効化される。
【００３３】
この構成により、本実施形態では、無効化リストなどの追加情報を送信することなく、コンポーネント（およびそのコンポーネントに対応する証明書）を無効化することができる。
【００３４】
本発明は、セキュアブートを実行するシステム内でオプショナルもしくは失敗のコンポーネントをサポートするためのシステムに関する。後述する追加のRIM証明書およびデータテーブルを提供することにより、セキュアブートをサポートする装置の開発者は、起動に失敗したコンポーネント柔軟に扱うシステムや、セキュアブートによってもたらされる信頼された環境内で、コンポーネントの状態を報告できる装置を生産できる。さらに、アクティブなオプショナルなコンポーネントのリストを備えることで、システムが、外部関係者によって有効化および無効化される可能性のあるコンポーネントも処理できるようになる。本実施形態は、装置内の少なくとも1つのコンポーネントがオプショナルなコンポーネントであり、そのコンポーネントおよびそのコンポーネントのブート時よりも前にブートした他のコンポーネントを検証するために証明書を用いるシステムを想定している。よって、通常のシステムでは、あるコンポーネントのブートプロセスの失敗が、その失敗したコンポーネントの後にブートする他のコンポーネントに影響を与える。これは、その失敗したコンポーネントがオプショナルなコンポーネントであり、他のコンポーネント自体は有効だとしても起こることである。この問題を避けるために、本実施形態では、以下に説明するように、失敗RIM証明書および成功RIM証明書を用いている。
【００３５】
この構成もまた、従来技術よりも新しい技術である。しかしながら、証明書の更新および無効化に関する本発明の一部は、上記に示した課題を扱わないシステムにも適用できる。
【００３６】
セキュアブートをサポートする装置の、オプショナルなコンポーネントの取り扱いを含む、コンポーネントを更新および無効化するための新しいシステムおよび方法を説明する。本願を完全に理解するため、以下、具体的な詳細を多数挙げて説明する。他の例では、周知の構造および装置をブロック図に示し、説明を簡単にするため、具体的な詳細は説明していない。しかしながら、当業者であれば、改良により、またはそのような具体的な説明なくとも、本願を実施することができるのは明らかである。好適な実施形態の説明により、クレームの範囲が限定されるものではない。
【００３７】
＜本実施形態の詳細＞
図1は、携帯装置のライフサイクルを示す。工場(100)で、初期化プロセス(102)において、各装置でどのオプショナルなコンポーネントが利用可能であるかを示す情報と共にオプショナルなコンポーネントのセットをインストールする。携帯装置が携帯電話販売店(106)またはオンラインストア等の他の販売業者に出荷されると、顧客はオプショナルなコンポーネントに対応する様々なオプションの購入(108)が可能になる。これで携帯装置(110)が使用できる状態になり、その装置の使用期間中、オプショナルなコンポーネントおよび必須のコンポーネント用の証明書(112)が全装置に送信される（114）。さらに、その装置の所有者は、携帯通信事業者または他の装置管理団体が提供するサーバ(118)を介して契約オプションのセットを明示的に更新し(116)、ある特定の装置で利用可能なオプショナルなコンポーネントを更新することが可能である。オプショナルなコンポーネントの管理に係る各プロセスの動作を以下に説明する。
【００３８】
図2は、本発明の一態様、具体的には、システム内のオプショナルなコンポーネントの作成および維持の方法、および、携帯装置110の構成を示す。重要な機能要素およびデータの項目は以下の通りである。まず、データ構造は全て、完全性保護(200)されており、好適な実施形態において、これは署名されたハッシュを用いることで達成されている。このデータ構造は、まず、成功RIM証明書202および失敗RIM証明書204である。成功RIM証明書は、全てのコンポーネントが適切に動作している場合の、セキュアブート中に予想されるプラットフォームの状態を記述したものであり、失敗RIM証明書は、1つ以上のコンポーネントが適切に動作しなかった場合の、セキュアブート中に予想されるプラットフォームの状態を記述したものである。ラベル-証明書対応テーブル206は、信頼されたコンポーネントの状態を特定の成功RIM証明書202または失敗RIM証明書204に対してマッピングし、オプショナルコンポーネント制御テーブル208は、どのオプショナルな信頼コンポーネントがアクティブで、どれが非アクティブかを記述し、デフォルトオプショナルコンポーネント制御テーブル210は、携帯電話の初回ブート時、または万一オプショナルコンポーネント制御テーブル208が破損した場合等に、オプショナルコンポーネント制御テーブル208を初期化する際に用いられる。好適な実施形態において、このテーブルの構造はオプショナルコンポーネント制御テーブル208の構造と同様である。このオプショナルコンポーネント制御テーブル208を初期化するため、イニシャライザ(226)が、デフォルトオプショナルコンポーネント制御テーブル210に基づいて、オプショナルコンポーネント制御テーブル208を作成する。このプロセスの詳細は後に説明する。
【００３９】
証明書更新部(212)は、携帯電話通信塔から無線ネットワークを通じて送出され、更新受信部(214)により装置が受信（216）する証明書リストを処理することにより、成功RIM証明書202および失敗RIM証明書204を最新の状態に保つ。このプロセスの詳細は後に説明する。当業者であれば、メモリカードやその他の有線または無線の送信手段を介する等、他にも更新を可能にする方法があることがわかるであろう。
【００４０】
契約更新部（218）は、装置上のウェブブラウザ(220)に、サーバ(224)にあるオプショナルなコンポーネントの維持ペ―ジにアクセスするよう要求することで、オプショナルコンポーネント制御テーブル208をアクティブな状態、および非アクティブな状態に保つ。好適な実施形態において、ウェブブラウザ(220)からサーバ(224)への接続には、通信路を攻撃から守るためにセキュアソケットレイヤ(SSL)を用いる(222)。このプロセスの詳細は後に説明する。
【００４１】
図3は、RIM証明書300、従来技術により定義されるRIM証明書の拡張である成功RIM証明書202および失敗RIM証明書204の詳細を示す。オプショナルなコンポーネントをサポートできるようにするため、mapLabeltoCertTableSize 306およびmapLabeltoCertTable 308が証明書に加えられ、extensionDigest 304のエントリは、これらの追加されたデータの暗号技術的ハッシュ値を含む。この拡張されたRIM証明書の例は1つだけでよく、また実施の形態ではこれらのテーブルをRTV+RTMが自己検証に使用する単一のRIM証明書に付加する。しかし、従来技術のこの態様は、ここでは述べない。
【００４２】
技術分野の当業者は、RIM証明書300を使用することなく、mapLabeltoCertTable 308の完全性を利用可能にし、維持する他の方法、例えば、署名者および装置の両方に既知の秘密鍵を使用したデジタル署名など、他の方法があることを理解できるであろう。
【００４３】
図4は、論理的識別子および1つ前に起動するソフトウェアコンポーネントから実際のRIM証明書までのマッピングを示すデータエントリを持つthe Map label to Cert table 308のフォーマットを示す。第1列の、論理証明書ラベル400は、RIM証明書のための特定の役割を示す識別子であり、システムの他の部分がRIM証明書を要求するために使用する識別子である。第2列の、依存する信頼コンポーネントの状態402には、どの信頼コンポーネントエラー状態のセットに対して各行が有効であるかを示すフラグが並べられている。第3列の、依存する信頼コンポーネントのマスク404には、どのコンポーネントの状態をチェックするべきかを示すフラグが並べられている。実施の形態では、これらの２つの列は、ビットマップを使用して実装される。最後に、RIM証明書ラベル406の列には、RIM証明書データベースから成功RIM証明書202または失敗RIM証明書204を検索するために用いられる実際のRIM証明書ラベルが保持されている。この値は、TCGで定義されるRIM証明書のlabelフィールド302を表す。
【００４４】
携帯装置の所有者、プロバイダー、製造業者等の外部関係者によって選択的にアクティブ化される可能性のあるこれらの信頼コンポーネントを管理するため、その装置は、どのオプショナルな信頼コンポーネントがアクティブで、どれが非アクティブであるかを示すリストを維持する。図5は、オプショナルコンポーネント制御構造体208におけるこのデータの好適な実施形態を示す。RIMProtectValue(502)は、ロールバックまたはリフラッシュの攻撃からの構造体の保護を支援するため、構造体作成時のTCG Mobile Trusted Module仕様書が定義するcounterRIMProtect単調カウンタのコピーである。その下に来るのは各行が2つのフィールドをもつテーブルである。最初のフィールドは、オプショナルな信頼コンポーネントの論理証明書ラベル（504）であり、ここではmapLabeltoCertTable(308)内の論理証明書ラベル(400)に用いられるものと同一のコンポーネント識別子が用いられている。次は、論理証明書ラベル(504)によって特定されるオプショナルな信頼コンポーネントが有効化されているか否かを示すフラグ(506)であり、有効化されている場合はTRUEに、有効化されていない場合はFALSEに設定される。この値のペアは、システム内の各オプショナルな信頼コンポーネントに対し繰り返され、-1の論理証明書ラベル(508)、および、非アクティブにするために通常はFALSEに設定されるフラグ(510)によりテーブルを終了する。この値のペアのセットの集合は、論理証明書ラベルテーブル(514)として知られている。最後に、オプショナルコンポーネント制御構造体内の上記データ全てを改竄から保護するために、PDCS v1.5アルゴリズムにしたがって生成され、下記図6で説明する通りに作成された外部プロセスからは利用できない秘密鍵を使って署名された暗号署名(512)がある。当該技術分野の当業者は、各オプショナルなコンポーネントの状態の完全性を利用可能にし、維持できる他の方法を理解するだろう。
【００４５】
図19は、本発明の別の態様、つまり、装置のユーザによるオプショナルなコンポーネントの維持を可能にするサーバ(224)の構造体が、その装置上で有効化または無効化されることを示す。重要な機能要素およびデータ項目は以下の通りである。秘密生成部(1902)、ページ生成部(1908)、オプション処理部(1916)、暗号化部(1920)、およびトランザクションコミッタ(1926)の5つのブロックは、外部装置へのインターフェースポイントであり、情報の伝達は左から右へ進む。まず、秘密生成部(1902)が、Diffe-Hellman等の、双方向通信プロトコル(1900)を用いて共有鍵(1904)を確立する。次に、携帯装置が契約維持ウェブページを要求する(1906)。その結果、ページ生成部(1908)がページを作成し、ページ生成部(1908)が現在のオプショナルなコンポーネントの状態を顧客オプション維持部(1910)に要求し、顧客オプション維持部(1910)が現在の状態を知るために顧客オプションデータベース(1912)に問い合わせを行う。装置のユーザが生成されたウェブページとの交信を終えると、完了メッセージがサーバに送信され(1914)、オプション処理部(1916)が、顧客オプション維持部(1910)にその新たなオプションを通知し、顧客オプションデータベース(1912)内でトランザクションを開始する。そのオプションはオプショナルコンポーネント制御構造体生成部(1918)に送られ、そこでオプショナルコンポーネント更新構造体（1800）にフォーマットされる。暗号化部(1920)が、共有鍵(1904)でこの構造体を暗号化し、その構造体を携帯装置に返す(1922)。最後に、装置が全ての内部構造体を更新し終えると、トランザクションコミッタ(1926)が完了メッセージを受信し(1924)、顧客オプション維持部(1910)に、顧客オプションデータベース(1912)内で進行中のトランザクションを完了しなければならないことを通知する。
【００４６】
図6は、本発明のオプショナルコンポーネント制御構造体の初期作成を示す。図示されたプロセスは、TCG Mobile Trusted Module仕様書に初期ブート用に詳述されている通り、ひとたびMTMが初期起動すると起こる、装置を初めてブートする時のプロセスである。また、そのドキュメントに詳述されているように、初期ブートは携帯装置のライフサイクルにおいて他の時点でも起こりえるため、図6は必要に応じた構造体の再作成も示す。まず、一連の初期ブートにおいてMTMおよび信頼性のルートを確立して初期化するために十分な初期化を行った後に、MTMからのオプショナルコンポーネント制御構造体に署名するための秘密鍵が要求される(600)。好適な実施形態において、秘密鍵はRSAキーペアの秘密鍵を示す。この要求の成功または失敗がチェックされ(602)、MTMが要求された鍵を発見できなかったときは、MTM内で秘密鍵を作成する(604)。この鍵は、TPMメイン仕様書パート2に定義されている使用法タイプであるTPM_KEY_SIGNINGで作成されなければならない。また、好適な実施形態において、この鍵のアルゴリズムは1024ビット長のTPM_ALG_RSAであり、TPM_SS_RSASSAPKCSA1v15_SHA1署名スキームとともに使用できる。しかし、秘密鍵が見つかったときは(602)、鍵を作成する必要がなく、その代わりに、既存の、有効に署名されたオプショナルコンポーネント制御構造体(208)があるか否かを確認するためのチェックを行う(606)。構造体がある場合は、構造体を再作成すると例えば変更されたオプションを上書きする可能性があることから、構造体は再作成する必要がなく、TCG Mobile Reference Architectureに定められているように、初期ブート手順が他の処理と共に進む。オプショナルコンポーネント制御構造体(208)がない場合は、MTMがRIM証明書を保護するために管理する単調カウンタが要求され(610)、オプショナルなコンポーネントのデフォルト状態情報が要求される(612)。新たなオプショナルコンポーネント制御構造体(208)が作成され、単調カウンタがRIMProtectValueフィールド(502)に、また、オプショナルなコンポーネントおよびその状態がフィールド504およびフィールド506に挿入され、テーブルターミネータ508および510が作成される。次に、この新たな構造体が、先に作成または取得された鍵を用いた暗号署名の要求と共に、MTMに送られる（616）。この署名プロセスにより、暗号署名(512)が作成される。これで、所望の、改竄できないオプショナルコンポーネント制御構造体(208)が格納された。これで、オプショナルコンポーネント制御構造体(208)の作成プロセスが完了し、初期ブート手順が、TCG Mobile Reference Architectureに定められている通り、他の処理と共に進む(620)。
【００４７】
図7は、TCG Mobile Reference Architecture version 1.0 revision 1のセクション6.3.4.2に記載されているRIM更新のタスクに必要な、本発明の追加的な処理を示す。その仕様書は、RIM_Authがどのように検証されるか、外部RIM_Certがどのように自身のCounterBootstrapをチェックさせるか、そしてどのように内部RIM証明書が作成され、ソフトウェアがインストールされるかを説明している。図7に示すプロセスは、内部RIM証明書を作成するべきか否か、またソフトウェアをインストールするべきか否かを判定するCounterBootstrapチェックの後に実行される。まず、オプショナルコンポーネント制御構造体をMTMから取得する(700)。次に、データが依然として有効で、かつ改竄されていないことの検証を可能にするために、暗号署名512の作成に用いられる秘密鍵の公開部分がMTM102から取得され(702)、現在のcounterRIMProtect単調カウンタがMTM102から取得される(704)。署名を検証して当該データが改竄されていないことを確かめ、現在のcounterRIMProtect単調カウンタを、この構造体に格納されているRIMProtectValue502と比較する(706)。その格納された値が、現在の単調カウンタ値よりも大きいか、または同じである場合、オプショナルコンポーネント制御構造体は最新であり、この構造体にリフラッシュやロールバック攻撃が起こっていないことを示している。その2つのチェックの結果が、署名が正しくないか、または現在の単調カウンタの値が構造体内のRIMProtectValue502よりも大きいことを示す場合は（708）、このRIM更新プロセスは失敗し（712）、インストールされたプログラムもRIM証明書も変更されない。しかしながら、そのチェック結果が、オプショナルコンポーネント制御構造体が有効であることを示す場合は、更新する対象の外部RIM証明書を取得する(710)。外部RIM証明書からの証明書ラベルは、mapLabeltoCertTable 308内にRIM証明書ラベル406とラベル付けされている第4列を検索するために用いられ（714）、このラベルに対する対応論理証明書ラベル400は適合する行の第1列をチェックすることにより発見される(716)。テーブル内にそのラベルが見つからないときは、このRIM証明書はオプショナルなコンポーネント用ではなく、必須コンポーネント用であるので、TCG Mobile Reference Architectureで説明されている通りにインストールしてもよい(720)。
【００４８】
しかし、対応する論理証明書ラベル400が見つかった場合、このラベルは、論理証明書ラベル504のオプショナルコンポーネント制御構造体のテーブル208を検索するために用いられる(718)。対応するエントリが見つからないときは(722)、このRIM証明書は外部から有効化または無効化できるものではないので、TCG Mobile Reference Architectureで説明されている通りにインストールしてもよい(720)。対応するエントリが見つかった場合は、有効フラグ506を取得し(724)、チェックする(726)。有効化されている場合は、外部RIM証明書を、TCG Mobile Reference Architectureで説明されている通りにインストールしてもよい(720)。有効化されていない場合は、この証明書が制御するコンポーネントはアクティブ化を許可されていないため、外部RIM証明書はインストールされない(728)。
【００４９】
図8は、本発明の、TCG Mobile Reference Architectureのセクション6.3.4.2で説明されているRIM無効化のタスクに必要な、追加の処理を示す。その仕様書には、RIM_Authがどのように検証されるか、RIM_Cert有効性リストがどのようにチェックされ、新たな有効性リスト上の対応する外部RIM_Certを有しない全ての内部RIM_Certが削除されるか、残りの全ての内部RIM_Certがどのように再有効化されるか、また、counterRIMProtect単調カウンタがどのように更新されるかが説明されている。図8が示すプロセスにより、counterRIMProtect単調カウンタが更新され、残りの全ての内部RIM_Certが再有効化される。まず、オプショナルコンポーネント制御構造体(510)をMTM102から取得する(800)。次に、データが依然として有効で、かつ改竄されていないことの検証を可能にするために、暗号署名512の作成に用いられる秘密鍵の公開部分をMTMから取得し(802)、かつ現在のcounterRIMProtect単調カウンタをMTMから取得する(804)。署名を検証して(806)当該データが改竄されていないことを確かめ、現在のcounterRIMProtect単調カウンタを、オプショナルコンポーネント制御構造体(510)に格納されているRIMProtectValue502と比較する。その格納された値が、現在の単調カウンタ値よりも大きいか、または同じである場合、オプショナルコンポーネント制御構造体は最新であり、その構造体にリフラッシュやロールバック攻撃が起こっていないことを示している。その2つのチェックの結果が、署名が正しくないか、または現在の単調カウンタの値がオプショナルコンポーネント制御構造体(510)内のRIMProtectValue502よりも大きいことを示す場合は(808)、このRIM無効化プロセスは失敗し(810)、インストールされたプログラムもRIM証明書も変更されない。しかしながら、そのチェック結果が、オプショナルコンポーネント制御構造体が有効であることを示す場合は、オプショナルコンポーネント制御構造体(510)内のRIMProtectValue502を、804で取得したcounterRIMProtect単調カウンタの現在の値に1を足したものに設定する（812）。暗号署名は、802で取得した秘密鍵で署名されたPKCS v1.5アルゴリズムにしたがって生成される(814)。次に、TCG Mobile Reference Architectureに説明されているタスクを実行する。既存の内部RIM証明書が、インクリメントされたRIMProtectカウンタ値で再有効化され(816)、RIM証明書およびオプショナルコンポーネント制御構造体(208)をロールバックやリフラッシュ攻撃から保護するために、counterRIMProtect単調カウンタの値がインクリメントされる(818)。最後に、残りの無効化機能をTCG Mobile Reference Architecture仕様書に説明されているように実行する。
【００５０】
図9は、オプショナルなコンポーネントのアクティブ化および非アクティブ化を制御する携帯装置(900)とサーバ(904)の間の通信処理を示す。加えて、携帯装置(900)のMobile Trusted Module (902)から、携帯装置(900)が要求するサービスも示す。まず、ユーザが、サーバに格納されている契約維持オプションを要求する(906)。好適な実施形態において、これは、サーバとSSL(セキュアソケットレイヤ)セッションを確立することによって実行する。そしてサーバは、装置のIDおよび信頼性を検証するために、TCG仕様書アーキテクチャの概要で定義されているような装置の認証を行う(908)。装置は、MTM902からサーバへのレポートを可能にするために、MTM902へ認証の要求を転送する(910)。MTM902から、装置を介してサーバへ確認メッセージを返す(912、914)。認証が成功し完了すると、好適な実施形態においては、顧客はDiffie-Hellman鍵交換によってサーバとの間で共有秘密を確立する(916、918)。次にサーバが、特定された装置に適した、カスタマイズされたオプショナルなコンポーネントのページを送信する（920）。好適な実施形態において、これは、HTMLベースのページであり、どのオプションを装置に追加するか、または削除するかを選択するために装置のユーザが交信する(922)。所望の変更がなされた後、装置は、各オプショナルなコンポーネントの新しい有効な状態または無効な状態を含む、交信完了を示すメッセージを送信する(924)。好適な実施形態において、これは、POSTによって、先に送信されたカスタマイズされたオプションページ(920)内に記述されているHTTPSページに実行される。他の好適な実施形態において、装置は装置のユーザが行った変更毎に別々のメッセージを送信する。他の好適な実施形態において、装置は、AJAXベースのメカニズムを用いて変更が行われる毎にすぐに、別々のメッセージを送信し、ユーザは、一旦変更を終えると完了メッセージを送信するオプションを選択する。サーバは、サーバの顧客データベースを適切に更新してから、装置に、916および918で確立された鍵で暗号化された、新たな更新されたコンポーネントのセットを送信する(926)。これらのステップは、図19の項目1914、1916、1918、1920および1922に対応する。好適な実施例において、そのデータは論理証明書ラベルテーブル（514）と同様のフォーマットで記述される。つまり、論理証明書ラベル(504)と有効フラグ(506)との複数のペアと有し、-1(508)とFALSE(510)との一組のペアで終了する。これは図18に示されており、オプショナルなコンポーネント更新構造体(1800)は、上述のような論理証明書ラベルテーブル(514)、およびデータが送信中に破損していないことを保証するテーブルのハッシュ(1802)を有する。装置はこのメッセージを復号し(928)、テーブルのハッシュ(1802)を検証する。それが成功すると、有効なコンポーネントまたは無効なコンポーネントを確実に正しく構成するようにオプションの処理を開始する。
【００５１】
装置の次のタスクは、現在の全ての内部RIM証明書をスキャンし、オプショナルコンポーネント更新構造体(1800)内のオプショナルなコンポーネントの状態のリストに従って、どの内部RIM証明書が無効化されたコンポーネントに使用されているかを判定することである。以下に、このタスクの実行方法を説明する。まず、装置が、現在装置上にある各内部RIM証明書に対し(936)、無効なコンポーネントを表しているか否かを判定する(930)。各内部RIM証明書からの証明書ラベルは、mapLabeltoCertTable 308内にRIM証明書ラベル406とラベル付けされている第3列を検索するために用いられ、適合する行の第1列をチェックすることにより、このラベルに対する対応論理証明書ラベル400が発見される。928で復号された更新されたオプションを、更新された論理証明書ラベル504が存在するか否かを確認するためにチェックし、もしあれば、有効フラグ506をチェックする。ない場合は、この内部RIM証明書は922で無効化されたオプショナルなコンポーネント用であるので、この証明書は削除される(932)。その他全ての状況では、RIM証明書は維持され、インクリメントされたRIMProtectカウンタと共に再インストールされる。全ての既存のRIM証明書がチェックされると、MTM902からの現在のRIMProtectカウンタ値が要求され(938)、MTM902から装置にこの値が返される(940)。新たなオプショナルコンポーネント制御構造体が、940で読み出されたRIMProtectカウンタ値よりも1つ大きな値と、928からの更新されたオプション情報とを用いて作成される(924)。MTM902に対し、図6に示した方法により生成された署名鍵を用いてデータに署名するよう要求する(944)。MTM902が署名を返し(946)、装置が新たなオプショナルコンポーネント構造体を作成し、以前の構造体を上書きして格納する(948)。
【００５２】
これで装置は、必要に応じ、外部RIM証明書および更新されたコンポーネントを、アクティブ化されたオプショナルなコンポーネント用に受信できる状態になった。そうして、装置はこれらのコンポーネントをサーバに要求する(950)。好適な実施形態において、装置からの通知を受信した(924)後にどのコンポーネントが有効化されたかに関する記録はサーバが有するため、装置は、送信開始の簡単な要求を送信する必要がある。サーバは、更新されたコンポーネントを送信する(952)。好適な実施形態において、送信および更新をインストールする(954)方法はTCG Mobile Reference ArchitectureのRIM更新で説明されている通りである。他の好適な実施形態において、サーバは、全てのコンポーネントに対する更新された証明書およびソフトウェアを送信し、図7に記載の処理により、無効なコンポーネント用の外部RIM証明書がインストールされないことを保証する。この実施形態において、有効なオプショナルなコンポーネント用の更新された証明書は、常に更新された証明書に含まれている。よって、携帯装置ではどのようなオプショナルなコンポーネントも有効化できる。そしてサーバは、携帯装置でどのオプショナルなコンポーネントが有効かを検知することなく、更新された証明書を作成できる。これにより、サーバに係るコストおよび負荷を減らすことができる。ロールバックやリフラッシュ攻撃から保護するために、装置はMTM902に対しRIMProtect単調カウンタのインクリメントを要求し（956）、MTM902は動作の成功を応答する(958)。これで、オプショナルなコンポーネントに関連する、装置の全ての情報、具体的には、オプショナルコンポーネント制御構造体(208)、適切な成功RIM証明書(202)および失敗RIM証明書(204)、ならびにcounterRIMProtect単調カウンタが成功裏に更新され、装置がサーバに対し、処理の完了を通知する(960)。最後に、確実に新たに有効化されたコンポーネントが動作し、無効なコンポーネントが動作をストップするように、装置が再ブートする（962）。
【００５３】
図10はこの実施形態のセキュアブートプロセスを示す。このセキュアブートプロセスは、オプショナルコンポーネント制御構造体(208)が有効であることを検証するための動作を含む。この処理は、引用した特許出願に記載のようにネクストコンポーネントテーブルおよびラベル-証明書対応テーブルの検証後に行われる。まず、オプショナルコンポーネント制御構造体（208）上の署名を検証するための秘密鍵の公開部分を取得する(1000)。鍵が見つからない場合は(1002)、エラーが起こり、適切な対応が取られる（1004）。好適な実装形態において、これをきっかけとして、図6に示されるようにデフォルトのオプショナルコンポーネント制御構造体（208）が再作成される。鍵がある場合は、オプショナルコンポーネント制御構造体（208）を要求する(1006)。構造体が存在しない場合は(1008)、エラーが起こり、適切な対応が取られる(1004)。ここで、counterRIMProtect単調カウンタ値を取得し(1010)、オプショナルコンポーネント制御構造体(208)を検証する(1012)。これは、改竄を検知するために、算出された署名が格納されている署名に適合すること、および、格納されているRIMProtectValue(502)が呼び出された単調カウンタ値よりも大きいかまたは同じであることをチェックすることの両方を含む。これが失敗した場合は(1014)、エラーが起こり、適切な対応が取られる(1004)。これが成功した場合は(1014)、オプショナルコンポーネント制御構造体（208）は有効であり、引用した特許公報に記載されているようにセキュアブートプロセスを続行する（1016）。
【００５４】
オプショナルコンポーネント制御構造体（208）内のカウンタの使用方法において、現在のcounterRIMProtect単調カウンタが4にインクリメントされた場合を説明する。この値4は、オプショナルコンポーネント制御構造体(208)のRIMProtectValueフィールド（502）にも格納され、秘密鍵で署名される。ここで、攻撃者がこの構造体を保存して、図9で説明したプロセスで全てのオプショナルなコンポーネントを無効化した場合、counterRIMProtect単調カウンタを5にインクリメントされ、この5の値は、オプショナルコンポーネント制御構造体(208)のRIMProtectValueフィールド（502）にも格納され、秘密鍵で署名される。しかし、ユーザが無効なコンポーネントを使用しようと、4の値のRIMProtectValue（502）を伴う古いオプショナルコンポーネント制御構造体(208)をコピーバックし、装置をリブートした場合、図10で説明したチェックがこれを検出する。オプショナルコンポーネント制御構造体(208)の検証(1012)は、格納されている4の値のRIMProtectValue（502）と、5の値のRIMProtectValueを比較することを含む。その結果、格納された値の方が低いので、検証は失敗し（1014）、エラーが発生する（1004）。
【００５５】
上述のように、図5〜図10はオプショナルコンポーネント制御構造体(208)がRIMProtectValue（502）および暗号署名（512）を有する場合の好適な実施形態を示しているが、以下に、オプショナルなコンポーネントの、有効な状態、または無効な状態を維持するための他の好適な実施形態を説明する。
【００５６】
図11は、先に説明したオプショナルコンポーネント制御構造体（208）の簡易版であるオプショナルコンポーネント制御構造体(1100)における、このデータの好適な実施形態を示す。上述のように、各行に2つのフィールドをもつテーブルがあり、最初のフィールドは、オプショナルな信頼コンポーネントの論理証明書ラベル（504）であり、ここではmapLabeltoCertTable(308)内の論理証明書ラベル(400)に用いられるものと同一のコンポーネント識別子が用いられている。次は、論理証明書ラベル(504)によって特定されるオプショナルな信頼コンポーネントが有効か否かを示すフラグ(506)であり、有効な場合はTRUEに、無効な場合はFALSEに設定される。この値のペアは、システム内の各オプショナルな信頼コンポーネントに対し繰り返され、-1の論理証明書ラベル(508)、および非アクティブにするために通常はFALSEに設定されるフラグ(510)によりテーブルを終了する。この値のペアのセットの集合は、論理証明書ラベルテーブル(514)として知られている。
【００５７】
図12は、オプショナルコンポーネント制御構造体(1100)の完全性を維持するために用いられるオプショナルコンポーネント制御RIM証明書の好適な実施形態を示す。このRIM証明書は、装置内で作成されることから、TCG Mobile Trusted Module仕様書に定義されるように、常に内部RIM証明書である。単一の装置の中に、そのような証明書は1つのみしかないことから、label(1202)は固定ストリングであり、好適な実施形態において「OCC_RIMC」に設定される。先の実施形態において、ロールバックまたはリフラッシュの攻撃からの保護にはRIMProtectValue(502)が用いられたが、ここではreferenceCounter(1204)を用いる。このフィールドは、TCG Mobile Trusted Module仕様書に定義されるように、MTMにより管理される。このRIM証明書は、決してMTM API MTM_VerifyRIMCertAndExtendには送られないため、state（1206）はTPM_PCR_SELECTIONが空になるように設定され、measurementPCRIndex(1208)の値は0に設定される。measurementValue(1210)は、オプショナルコンポーネント制御構造体(1100)のハッシュを格納する。好適な実施形態では、この値の生成にSHA-1アルゴリズムを用いる。このハッシュに署名する必要はない。フィールドextensionDigestSize(1212)は0に設定され、extentionDigest(1214)は表示されない。他の好適な実施形態において、フィールドを0に設定したmeasurementValue(1210)のハッシュを格納する代わりに、extentionDigest(1214)がオプショナルコンポーネント制御構造体(1100)のハッシュを格納し、extensionDigestSize(1212)がこのハッシュの大きさをバイト単位で保持する。最後に、integrityCheckSize(1216)およびintegrityCheck(1218)が、TCG Mobile Trusted Module仕様書に定義されるように、完全性チェック情報を格納する。
【００５８】
図13は、本発明のオプショナルコンポーネント制御構造体の、初期作成を示す。図示されたプロセスは、初期ブート用のTCG Mobile Trusted Module仕様書に詳述されている通り、ひとたびMTM 102が初期起動すると起こる、装置を初めてブートする時のプロセスである。また、そのドキュメントに詳述されているように、初期ブートは携帯装置のライフサイクルにおいて他の時点でも起こりえるため、図13は必要に応じた構造体の再作成も示す。まず、一連の初期ブートにおいてMTMおよび信頼性のルートを確立して初期化するために十分な初期化を行った後に、既存のオプショナルコンポーネント制御構造体(1100)が存在するか否かを確認するチェックを行う(1300)。構造体が既にあるときは(1302)、その構造体のハッシュを算出し(1304)、オプショナルコンポーネント制御RIM証明書（1200）を呼び出す(1306)。呼び出しが成功し、measurementValue(1210)に格納されたハッシュ値が1304で算出したハッシュ値と等しい場合、MTM_VerifyRIMCertがTPM_SUCCESSを返し、構造体が最新でかつ改竄されていないことを確認した場合は(1308)、TCG Mobile Reference Architectureに定義されているように、他の処理と共にその初期ブート手順を続ける(1320)。1302または1308何れかのチェック結果が失敗である場合は、オプショナルコンポーネント制御構造体（1100）およびオプショナルコンポーネント制御RIM証明書を再作成するか、または初めて作成する。まず、デフォルトのオプショナルコンポーネント制御構造体(1100)を作成し（1310）、その構造体のハッシュを算出する（1312）。次に、measurementValue(1210)を1312で算出したハッシュ値に設定して、署名されていないオプショナルコンポーネント制御RIM証明書（1200）を作成する(1314)。この署名されていない証明書を用いてMTM API MTM_InstallRIMを呼び出すことにより(1316)、MTMはMTM API MTM_InstallRIMを、有効な内部RIM証明書を作成するためのテンプレートとして用いる。有効な内部RIM証明書は、現在のcounterRIMProtect値をreferenceCounterフィールド(1204)に挿入し、TCG Mobile Trusted Module仕様書に定義されているように秘密内部鍵を用いてintegrityCheckData(1218)を生成することで作成される。これら2つの新たな構造体が格納され(1318)、TCG Mobile Reference Architectureに定められている通り、初期ブート手順が他の処理と共に続く(1320)。
【００５９】
図14は、本発明の、Mobile Reference Architecture version 1.0 revision 1のセクション6.3.4.2に記載されているRIM更新のタスクに必要な、本発明の追加的な処理を示す。その仕様書は、RIM_Authがどのように検証されるか、外部RIM_Certがどのように自身のCounterBootstrapをチェックさせるか、そしてどのように内部RIM証明書が作成され、ソフトウェアがインストールされるかを説明している。図14に示すプロセスは、内部RIM証明書を作成するべきか否か、またソフトウェアをインストールするべきか否かを判定するCounterBootstrapチェックの後に実行される。まず、オプショナルコンポーネント制御構造体をMTM102から取得する(1400)。次に、その構造体のハッシュを算出し(1402)、オプショナルコンポーネント制御RIM証明書（1200）を呼び出す(1404)。この呼び出しに失敗した場合、つまり、measurementValue(1210)に格納されたハッシュ値が1402で算出したハッシュ値と等しくない場合、またはMTM_VerifyRIMCertがTPM_SUCCESS以外の値を返し、この構造体が最新でないか、改竄されていることを示す場合は(1406)、更新処理は失敗である（1408）。しかしながら、全ての検査で問題がなければ、更新する対象の外部RIM証明書を取得する(1410)。外部RIM証明書からの証明書ラベルは、mapLabeltoCertTable 308内のRIM証明書ラベル406とラベル付けされている第4列を検索するために用いられ(1412)、適合する行の第1列をチェックすることにより(1414)、このラベルに対する対応論理証明書ラベル400が発見される。テーブル内にそのラベルが見つからないときは、このRIM証明書はオプショナルなコンポーネント用ではなく、必須コンポーネント用であるので、TCG Mobile Reference Architectureで説明されている通りにインストールしてもよい(1418)。
【００６０】
しかし、対応する論理証明書ラベル400が見つかった場合、このラベルは、論理証明書ラベル504のオプショナルコンポーネント制御構造体のテーブル1100を検索するために用いられる(1416)。対応するエントリが見つからないときは(1420)、このRIM証明書は外部から有効化または無効化できるものではないので、TCG Mobile Reference Architectureで説明されている通りにインストールしてもよい(1418)。対応するエントリが見つかった場合は、有効フラグ506を取得し(1422)、チェックする(1424)。有効化されている場合は、外部RIM証明書を、TCG Mobile Reference Architectureで説明されている通りにインストールしてもよい(1418)。有効化されていない場合は、この証明書が制御するコンポーネントはアクティブ化を許可されていないため、外部RIM証明書はインストールされない(1426)。
【００６１】
図15は、本発明の、TCG Mobile Reference Architectureのセクション6.3.4.5で説明されているRIM無効化のタスクに必要な、追加の処理を示す。その仕様書には、RIM_Authがどのように検証されるか、RIM_Cert有効性リストがどのようにチェックされ、新しい認証リスト上に対応する外部RIM_Certを有しない全ての内部RIM_Certがどのように削除されるか、残りの全ての内部RIM_Certがどのように再有効化されるか、また、counterRIMProtect単調カウンタがどのように更新されるかが説明されている。図15が示すプロセスにより、counterRIMProtect単調カウンタが更新され、残りの全ての内部RIM_Certが再有効化される。まず、オプショナルコンポーネント制御構造体をMTMから取得する(1500)。次に、その構造体のハッシュを算出し(1502)、オプショナルコンポーネント制御RIM証明書（1200）を呼び出す(1504)。この呼び出しに失敗した場合、つまり、measurementValue(1210)に格納されたハッシュ値が1502で算出したハッシュ値と等しくない場合、またはMTM_VerifyRIMCertがTPM_SUCCESS以外の値を返し、この構造体が最新でないか、改竄されていることを示す場合は（1506）、RIM無効化処理は失敗であり（1508）、インストールされたプログラムもRIM証明書も変更されない。
【００６２】
チェックの結果、オプショナルコンポーネント制御構造体（1100）が有効であることを示している場合は、MTMは、1504で取得した既存の証明書を用いてMTM API MTM_InstallRIMを呼び出して、referenceCounterフィールド(1204)に挿入された、インクリメントされたcounterRIMProtect値を伴う新しい内部RIM証明書を作成するためのテンプレートとして使用し、TCG Mobile Trusted Module 仕様書に説明されているように、秘密内部鍵を用いてintegrityCheckData(1218)を生成する。
【００６３】
次に、TCG Mobile Reference Architecture仕様書に説明されているタスクを実行する。既存の内部RIM証明書はインクリメントされたRIMProtectカウンタ値で再有効化され(1512)、counterRIMProtect単調カウンタがインクリメントされ、信頼されたコンポーネントのRIM証明書およびオプショナルコンポーネント制御RIM証明書（1200）の両方をロールバックまたはリフラッシュの攻撃から保護する。最後に、残りの無効化機能をTCG Mobile Reference Architecture仕様書に説明されている通りに実行する（1516）。
【００６４】
図16は、オプショナルコンポーネントのアクティブ化および非アクティブ化を制御する携帯装置(1600)とサーバ(1604)の間の通信処理を示す。加えて、携帯装置(1600)上のMobile Trusted Module(1602)から、携帯装置(1600)が要求するサービスも示す。この通信シーケンスの最初の部分に参照符号1606〜1636を付しており、これは、図9のステップ906〜936に相当する。よって、本ステップの説明はその部分を参照する。
【００６５】
まず、ユーザが、サーバに格納されている契約維持オプションを要求する(1606)。好適な実施形態において、これは、サーバとSSL(セキュアソケットレイヤ)セッションを確立することによって実行する。そしてサーバは、装置のIDおよび信頼性を検証するために、TCG仕様書アーキテクチャの概要で定義されているような装置の認証を行う(1608)。装置は、MTM1602からサーバへの報告を可能にするため、MTM1602に要求を転送する(1610)。MTM1602から、装置を介してサーバへ確認メッセージを返す(1612、1614)。認証が成功し完了すると、好適な実施形態においては、顧客はDiffie-Hellman鍵交換によって、サーバとの間で共有秘密を確立する(1616、1618)。次にサーバが、特定された携帯電話に適した、カスタマイズされたオプショナルなコンポーネントのページを送信する（1620）。好適な実施形態において、これは、HTMLベースのページであり、どのオプションを装置に追加するか、または削除するかを選択するために装置のユーザが交信する(1622)。所望の変更がなされた後、装置は、各オプショナルなコンポーネントの新しい有効な状態または無効な状態を含む、交信完了を示すメッセージを送信する(1624)。好適な実施形態において、これは、POSTによって先に送信されたカスタマイズされたオプションページ(1620)内に記述されているHTTPSページに実行される。他の好適な実施形態において、装置は装置のユーザが行った変更毎に別々のメッセージを送信する。他の好適な実施形態において、装置は、AJAXベースのメカニズムを用いて変更が行われる毎にすぐに、別々のメッセージを送信し、ユーザは、一旦変更を終えると完了メッセージを送信するオプションを選択する。サーバは、サーバの顧客データベースを適切に更新してから、携帯装置に、1616および1618で確立された鍵で暗号化された、新たな更新されたコンポーネントのセットを送信する(1626)。好適な実施例において、図5に示されるように、そのデータは論理証明書ラベルテーブル（514）と同様のフォーマットで記述される。つまり、論理証明書ラベル(504)と有効フラグ(506)との複数のペアを有し、-1(508)とFALSE(510)との一組のペアで終了する。これは図18に示されており、オプショナルなコンポーネント更新構造体(1800)は、上述のような論理証明書ラベルテーブル(514)、およびデータが送信中に破損していないことを保証するテーブルのハッシュ(1802)を有する。装置はこのメッセージを復号し(1628)、テーブルのハッシュ(1802)を検証する。それが成功すると、有効なコンポーネントおよび無効なコンポーネントを確実に正しく構成するようにオプションの処理を開始する。
【００６６】
まず、装置が、現在装置上にある各内部RIM証明書に対し(1636)、無効なコンポーネントを表しているか否かを判定する(1630)。各内部RIM証明書からの証明書ラベルは、mapLabeltoCertTable 308内にRIM証明書ラベル406とラベル付けされている第3列を検索するために用いられ、適合する行の第1列をチェックすることにより、このラベルに対する対応論理証明書ラベル400が発見される。1628で復号された更新されたオプションは、更新された論理証明書ラベル504があるか否かを確認するためにチェックされ、もしあれば、有効フラグ506がチェックされる。ない場合は、この内部RIM証明書は1622で無効化されたオプショナルなコンポーネント用であるので、この証明書は削除される(1632)。その他全ての状況では、RIM証明書は維持され、インクリメントされたRIMProtectカウンタを伴って再インストールされる(1634)。
【００６７】
全ての既存のRIM証明書がチェックされると、新しいオプショナルコンポーネント制御構造体(1100)を作成し(1638)、その構造体のハッシュを算出する（1640）。次に、measurementValue(1210)を1640で算出したハッシュ値に設定して、署名されていないオプショナルコンポーネント制御RIM証明書（1200）を作成する(1642)。この署名されていない証明書を用いてMTM API MTM_InstallRIMを呼び出すことにより(1644)、MTMはMTM API MTM_InstallRIMを、有効な内部RIM証明書を作成するためのテンプレートとして用いる。有効な内部RIM証明書は、現在のcounterRIMProtect値をreferenceCounterフィールド(1204)に挿入し、TCG Mobile Trusted Module仕様書に定義されているように秘密内部鍵を用いてintegrityCheckData(1218)を生成することで作成される。そして、MTMは携帯装置に署名された構造体を返す(1646)。この新たな構造体は格納され(1648)、その後ステップ1650〜1662が、図9のステップ950〜962と同じように実行される。よって、本ステップの説明はその部分を参照する。
【００６８】
これで装置は、必要に応じ、外部RIM証明書および更新されたコンポーネントを、アクティブ化されたオプショナルなコンポーネント用に受信できる状態になった。そうして、装置はこれらのコンポーネントをサーバに要求する(1650)。好適な実施形態において、装置からの通知を受信した後に(1624)どのコンポーネントが有効化されたかに関する記録はサーバが有するため、装置は、送信開始の簡単な要求を送信する必要がある。サーバは、更新されたコンポーネントを送信する(1652)。好適な実施形態において、送信および更新をインストールする(1654)方法はTCG Mobile Reference ArchitectureのRIM更新で説明されている通りである。他の好適な実施形態において、サーバは、全てのコンポーネントに対し更新された証明書およびソフトウェアを送信し、図14に記載の処理により、無効なコンポーネント用の外部RIM証明書がインストールされないことを保証する。この実施形態において、有効なオプショナルなコンポーネント用の更新された証明書は、常に更新された証明書に含まれている。よって、携帯装置ではどのようなオプショナルなコンポーネントも有効化できる。そしてサーバは、携帯装置でどのオプショナルなコンポーネントが有効かを検知することなく、更新された証明書を作成できる。これにより、サーバに係るコストおよび負荷を減らすことができる。ロールバックやリフラッシュの攻撃から保護するために、装置はMTM1602に対しRIMProtect単調カウンタをインクリメントするように要求し（1656）、MTM1602は動作の成功を応答する(1658)。これで、オプショナルなコンポーネントに関連する、装置の全ての情報、具体的には、オプショナルコンポーネント制御構造体(208)、適切な成功RIM証明書(202)および失敗RIM証明書(204)、ならびにcounterRIMProtect単調カウンタが成功裏に更新され、装置がサーバに対し、処理の完了を通知する(1660)。最後に、確実に新たに有効化されたコンポーネントが動作し、無効なコンポーネントが動作をストップするように、装置が再ブートする(1662)。
【００６９】
図17は、この実施形態のセキュアブートプロセスを示す。このセキュアブートプロセスは、オプショナルコンポーネント制御構造体(1100)が有効であることを検証するための動作を含む。この処理は、引用した特許出願に説明されているネクストコンポーネントテーブルおよびラベル-証明書対応テーブルの検証後に行われる。まず、オプショナルコンポーネント制御構造体RIM証明書（1200）を探す(1700)。RIM証明書が見つからない場合は(1702)、エラーが起こり、適切な対応が取られる(1704)。好適な実現例において、これをきっかけとして、図13に示されるようにデフォルトのオプショナルコンポーネント制御構造体（1100）および適合するオプショナルコンポーネント制御構造体RIM証明書（1200）が再作成される。RIM証明書がある場合は、オプショナルコンポーネント制御構造体(1100)も取得する。また、構造体が見つからない場合は(1708)、エラーが起こり、適切な対応が取られる(1704)。SHA-1を用いる好適な実施形態において、この構造体のためのハッシュ値を算出し、その結果をmeasurementValueフィールド(1210)のオプショナルコンポーネント制御構造体RIM証明書（1200）に格納されているハッシュ値と比較する。それらの値が異なる場合は(1714)、エラーが起こり、適切な対応が取られる(1704)。最終的な検証はMTMによって行われる。オプショナルコンポーネント制御構造体RIM証明書（1200）が、パラメータとしてMTM API MTM_VerifyRIMCertに送られる（1716）。MTM API MTM_VerifyRIMCertは、RIM証明書上の署名が有効であること、および、referenceCounter(1204)に格納されている値がMTMにより維持され、指示されている単調カウンタの値よりも大きいかまたは同じであることを検証する。MTMが、有効化失敗を示すエラーを返した場合は(1718)、エラーが起こり、適切な対応が取られる(1704)。成功を返した場合は、引用した特許公報に記載されているようにセキュアブートプロセスの続行が可能である(1720)。
【００７０】
本発明は上記の実施の形態に基づいて述べられているが、本発明は明らかにそのような実施の形態に限定されるものではない。下記のケースもまた本発明に含まれる。
【００７１】
(1)上述の実施の形態では、検証は証明書(RIM証明書)内でハッシュ値を使用することにより実行された。しかしながら、ハッシュ値を使用しない他の検証方法が本発明に適用されても良い。
【００７２】
従来のチェックサムや、コンポーネントから抽出される別のデータ(例えば、コンポーネントから抽出される第一所定ビット)が、検証を実行するために使用されても良い。また、証明書は、完全性チェック値を含むデータグループに置き換えられても良い。
【００７３】
さらに、検証方法は、コンポーネントから抽出される値と期待される値が等しいか否かをチェックすることに限定されない。例えば、コンポーネントのサイズを確認し、もしサイズが所定量より大きいか、または小さいなら、コンポーネントは検証されたと判断されるとしてもよい。これらの検証方法は、ハッシュ値と、その期待値とを比較するほど厳密なものではないが、高速に実行される。
【００７４】
(2)上述の実施形態において、サーバは、全てのコンポーネントに対して更新された証明書およびソフトウェアを送信する。しかしながら、サーバは1つ以上の無効化された証明書に対応する1つ以上の更新された証明書を除外してもよい。この構造により、サーバは、証明書を一組のみ送信することで、証明書の更新および無効化を行うことができる。
【００７５】
さらに、証明書のうち少なくとも1つが更新されない場合は、サーバは、1つ以上の更新されていない証明書に対応する1つ以上の更新された証明書を除外してもよい。この場合、どの証明書が無効化されたかを示す情報を送信することが望ましい。これは、更新されていない証明書が図15の手順において無効化された証明書と間違われる可能性があるためである。
【００７６】
(3)上記の各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。前記ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記憶されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
【００７７】
(4)上記の各装置を構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記憶されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。
【００７８】
さらに、各装置を構成する構成部品の各ユニットは、個別のチップとして、又は、一部若しくは全てを含む単一のチップとして作られても良い。
【００７９】
さらに、ここでは、LSIが述べられているが、集積化の程度の違いにより、指定IC、LSI、スーパーLSI、ウルトラLSIが使用される場合もある。
【００８０】
さらに、回路の集積化の手段は、LSIに限定されるものではなく、専用回路、若しくは汎用プロセッサによる実装も利用できる。さらに、LSIが製造された後にプログラム可能なフィールドプログラムゲートアレイ(FPGA)を使用することもまた可能であり、またLSI内で回路セルの接続及び設定を再構成可能なリコンフィギュアラブルプロセッサも使用可能である。
【００８１】
さらに、もしLSIに置き換わる集積回路技術が半導体技術若しくは他の派生する技術の進歩を通じて現われるのであれば、その技術は当然に構成要素の集積化を実現するために使用することができる。バイオ技術の適用が予想される。
【００８２】
(5)上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。前記ＩＣカードまたは前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。前記ＩＣカードまたは前記モジュールは、上記の超多機能ＬＳＩに含まれるとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、前記ＩＣカードまたは前記モジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
【００８３】
(6)本発明は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、前記コンピュータプログラムからなるデジタル信号であるとしてもよい。
【００８４】
また、本発明は、前記コンピュータプログラムまたは前記デジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Blu-ray Disc）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されている前記デジタル信号であるとしてもよい。
【００８５】
また、本発明は、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
【００８６】
また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記憶しており、前記マイクロプロセッサは、前記コンピュータプログラムにしたがって動作するとしてもよい。
【００８７】
また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を、前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
【００８８】
(7)本技術分野の当業者にとっては、説明した実施の形態の、本発明固有の教示及び利点から原理的に離れることのない多くの変形がありえることを容易に理解することができるだろう。また、上記変更及び実施の形態の任意の組み合わせは、本発明の範囲内に含まれる。
【図面の簡単な説明】
【００８９】
後述の好適な実施形態の詳細な説明を以下の図面と共に考察することで、本発明のよりよい理解が得られる。
【図１】図1は、オプショナルコンポーネント制御構造体に係る携帯装置のライフタイムおよび外部との相互関係を示す。
【図２】図2は、オプショナルコンポーネント制御テーブルおよび関連データを維持するためのキーコンポーネントを表すブロック図である。
【図３】図3は、オプショナルなコンポーネントをサポートするために必要とされるテーブルを表す追加のデータを含むRIM証明書を示す。
【図４】図4は、RIM証明書に付加されたラベル-証明書対応テーブルを示す。
【図５】図5は、カウンタ値、証明書識別子およびその状態を示すテーブル、およびオプショナルなコンポーネントの状態を表す暗号署名を含むオプショナルコンポーネント制御構造体を示す。
【図６】図6は、本発明のオプショナルコンポーネント制御構造体の、初期化プロセスを示すフローチャートである。
【図７】図7は、本発明のオプショナルコンポーネント制御構造体を用いた、外部RIM証明書の更新プロセスを示すフローチャートである。
【図８】図8は、本発明のオプショナルコンポーネント制御構造体を用いた、内部RIM証明書の無効化プロセスを示すフローチャートである。
【図９】図9は、本発明のオプショナルコンポーネント制御構造体を更新するための、サーバとの交信プロセスを示すシーケンス線図である。
【図１０】図10は、本発明のオプショナルコンポーネント制御構造体の検証を含むセキュアブートの強化を示すシーケンス線図である。
【図１１】図11は、カウンタ値、証明書識別子およびその状態を示すテーブル、およびオプショナルなコンポーネントの状態を表す暗号署名を含むオプショナルコンポーネント制御構造体を示す。
【図１２】図12は、オプショナルコンポーネント制御構造体RIM証明書を示す。
【図１３】図13は、本発明のオプショナルコンポーネント制御構造体の、初期化プロセスを示すフローチャートである。
【図１４】図14は、本発明のオプショナルコンポーネント制御構造体を用いた、外部RIM証明書の更新プロセスを示すフローチャートである。
【図１５】図15は、本発明のオプショナルコンポーネント制御構造体を用いた、内部RIM証明書の無効化プロセスを示すフローチャートである。
【図１６】図16は、本発明のオプショナルコンポーネント制御構造体を更新するための、サーバとの交信プロセスを示すシーケンス線図である。
【図１７】図17は、本発明のオプショナルコンポーネント制御構造体の検証を含むセキュアブートの強化を示すシーケンス線図である。
【図１８】図18は、サーバから携帯装置へ送られるオプショナルコンポーネント更新構造体を示す。
【図１９】図19は、顧客装置によるオプショナルコンポーネント制御オプションの維持をサポートするための、サーバ内のキーコンポーネントを表すブロック図である。
【背景技術】
【０００１】
例えば、“the Trusted Computing Group's (TCG) Mobile Trusted Module (MTM) documents TCG Mobile Reference Architecture version 1.0 12 June 2007”、および、“TCG Mobile Trusted Module Specification version 1.0 12 June 2007”のような先導的な先行文献は、装置をどのようにして、保証され、また、信頼された方法で起動するかを記述している。これらの方法は、信頼性や安全性がブートプロセスの間保持されるということを確実にするため徹底的に見直されてきており、その結果、安全にブートができる装置の実装を要求する人々に有用な基準を提供している。このセキュアブートプロセスのキーコンポーネントは、RIM証明書である。これは、現在期待されるプラットフォームの状態がどのようなものであるべきかを定義する署名つきの構造体である。プラットフォームの状態は、プラットフォーム設定レジスタ(PCRs)の集合に対するハッシュによって表され、各ＰＣＲは一般に定義されたハッシュ値を含む。これらのPCRは、完全性測定（integrity measurement）情報として用いられるものであり、期待される装置の状態を定義するためにRIM証明書に記録されていてもよい。さらに、RIM証明書はまた、もし現在の状態が検証される場合に、拡張されるべきPCRを特定する。この拡張の処理では、指定されたPCRの値を取得し、RIM証明書内で定義される新たな既知の値と以前のPCR値とを連結させた値に基づいて新たなハッシュ値を算出する。TCGによって定義される典型的なセキュアブートシーケンスは、コアコンポーネントの初期化および自己検証から開始する。ここで、コアコンポーネントとは、検証および測定の信頼性のルート(RTV+RTM)、MTM自体、および関連するコアMTMインタフェースコンポーネント等である。次に、ファームウェアの他の部分をサポートする追加コンポーネントが、信頼された方法で起動される。ここで信頼された方法とは、例えば、各追加コンポーネントの起動時に、先にブートされた他のコンポーネントによって検証されることである。そして、最後に、オペレーティングシステムが、クライアントアプリケーションに対して、MTMサービスへとアクセスする安全で信頼されたパスを提供するために起動される。
【０００２】
TCG仕様書は、携帯電話などの携帯端末ではリソースが限られていることを認識した上での監査機能を提供している。仕様書では、これらの監査の形態はMTMではオプショナルであると定義されているが、これは下記に示す問題を生じる。
【０００３】
TCG仕様書において、RIM証明書は更新することができる。しかし、TCG仕様書は、1つ以上のオプショナルなコンポーネントを有するシステムにおいてRIM証明書を更新する方法を示していない。
【０００４】
ここでオプショナルなコンポーネントとは、例えば、ユーザが追加契約した後にアクティブ化できるアプリケーションソフトウェアのことである。ここで、「アクティブ化された(または有効化された)」とは、そのアプリケーションソフトウェアの状態を、ユーザが実行可能な状態に変化させることである。そのソフトウェアがアクティブ化されていなければ、たとえそのアプリケーションソフトウェアがコンピュータに事前にインストールされているか、またはサーバからダウンロードされていても、ユーザはそのアプリケーションソフトウェアを使用することができない。
【０００５】
上述のように、オプショナルなコンポーネントがアクティブ化されているか否かは、例えば、各ユーザの決定による。よって、更新されたRIM証明書をコンピュータに送信するサーバは、アクティブ化されているコンポーネントに対応する更新された証明書を送信するために、各コンピュータにおいてどのコンポーネントがアクティブ化されているかを知っていなければならない。
【０００６】
しかし、コンピュータ毎にカスタマイズされたセットを作成するのは煩雑で、費用もかかる。
【０００７】
Zimmerらによる米国特許出願公開第2005/0138414号明細書では、オプショナルなコンポーネントを伴う検証されたブート方法が開示されているが、この課題の解決方法は教示されていない。
【０００８】
Schellらによる米国特許第6477648号明細書では、検証に失敗する可能性のあるオプショナルなコンポーネントを伴う検証されたブート方法が開示されているが、この課題の解決方法は教示されていない。
【０００９】
そこで、装置がオプショナルなコンポーネントを有する場合でも、更新された証明書のセットを装置毎にカスタマイズして作成することなく、証明書を更新する装置およびサーバが必要である。
【００１０】
［発明の概要］
この課題を解決するために、本発明によると、サーバに接続可能な装置は、各々が1つの証明書に割り当てられる複数のソフトウェアと、前記複数のソフトウェアに関連付けられ、かつ各々が前記複数のソフトウェア各々の検証に用いられる複数の証明書とを格納する格納手段と、前記複数のソフトウェアの1つを、前記装置で実行可能な前記複数のソフトウェアのうちの有効な1つのソフトウェアとして、前記装置に設定する設定手段と、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書を用いて、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証し、前記検証の後に、前記複数のソフトウェアのうちの前記有効かつ検証されたソフトウェアを実行する実行手段と、前記複数の証明書のうち、何れが前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに対応するかを検出することなく、更新すべきと前記サーバによって判定された所定の証明書に対応する複数の更新された証明書を前記サーバから受信する受信手段と、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書に対応する1つの更新された証明書を、前記受信した複数の更新された証明書から選択する選択手段とを備え、前記実行手段は前記1つの最新かつ選択された証明書を用いて前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証する。
【００１１】
この構成により、装置は、サーバがどの更新された証明書が有効なコンポーネントに対応するかを検出することなく生成した、更新された証明書を受信する。そして、装置は受信した更新された証明書から、更新対象の最新の証明書を選択する。よって、本発明の本態様によると、サーバが送信する証明書のセットをカスタマイズすることなく、証明書を適切に更新することが可能である。
【発明を実施するための最良の形態】
【００１２】
本発明の第1の態様によると、サーバに接続可能な装置は、各々が1つの証明書に割り当てられる複数のソフトウェアと、前記複数のソフトウェアに関連付けられ、かつ各々が前記複数のソフトウェア各々の検証に用いられる複数の証明書とを格納する格納手段と、前記複数のソフトウェアの1つを、前記装置で実行可能な前記複数のソフトウェアのうちの有効な1つのソフトウェアとして、前記装置に設定する設定手段と、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書を用いて、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証し、前記検証の後に、前記複数のソフトウェアのうちの前記有効かつ検証されたソフトウェアを実行する実行手段と、前記複数の証明書のうち、何れが前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに対応するかを検出することなく、更新すべきと前記サーバによって判定された所定の証明書に対応する複数の更新された証明書を前記サーバから受信する受信手段と、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書に対応する1つの更新された証明書を、前記受信した複数の更新された証明書から選択する選択手段とを備え、前記実行手段は前記1つの更新され選択された証明書を用いて前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証する。
【００１３】
本発明の第2の態様によると、前記サーバは、前記複数の更新された証明書を前記装置およびもう1つの別の装置に共通して送信する。
【００１４】
本発明の第3の態様によると、前記複数の更新された証明書は、前記複数のソフトウェアのうちの前記1つの有効なソフトウェアとは異なる、前記複数のソフトウェアのうちの1つのソフトウェアに関連する証明書に対応する更新された証明書を含む。
【００１５】
本発明の第4の態様によると、前記装置はさらに、前記1つの更新された証明書に基づき、前記複数のソフトウェアのうちの前記1つの有効なソフトウェアに関連する証明書を更新する更新手段を備え、前記実行手段は、前記更新手段が更新した証明書を用いて前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証する。
【００１６】
本発明の第5の態様によると、前記更新手段は、選択されなかった更新された証明書に対応する証明書を更新することなく、前記選択されなかった更新された証明書を、前記受信した複数の更新された証明書から削除する。
【００１７】
本発明の第6の態様によると、前記装置はさらに、前記装置の固有鍵である装置鍵を格納する装置鍵格納手段を備え、前記更新手段は、前記装置鍵を用いて前記1つの更新された証明書を変換し、前記変換された1つの更新された証明書で前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書を上書きすることにより、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書を更新する。
【００１８】
本発明の第7の態様によると、前記装置は、さらに、1つの証明書に対応する更新された証明書が、前記受信した複数の更新された証明書に含まれていないとき、前記1つの証明書が無効であると判定する無効化判定手段と、前記格納手段に格納されている前記1つの証明書を無効化する無効化手段とを備える。
【００１９】
この構成により、当該装置は、受信した更新された証明書の中に、当該証明書の最新版が含まれているか否かをチェックすることによって、どの証明書を無効化するべきか判定する。
【００２０】
本発明の本態様によると、当該装置はコンポーネント(およびそのコンポーネントに対応する証明書)を、その証明書を更新すると同時に無効化することができる。よって、本発明の本態様では、無効化リストなどの追加情報を送信することなく証明書を無効化することができる。
【００２１】
本発明の第8の態様によると、前記装置はさらに、前記設定手段が前記装置に、前記複数のソフトウェアのうちの1つを前記複数のソフトウェアのうちの前記有効な1つのソフトウェアとして設定したとき、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを示す許可フラグを格納するフラグ格納手段を備え、前記選択手段は、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書に対応する1つの更新された証明書を、前記フラグ格納手段に格納されている前記許可フラグに基づいて、前記受信した複数の更新された証明書から選択する。
【００２２】
本発明の第9の態様によると、前記装置はさらに、前記無効化手段が前記格納手段に格納されている前記1つの証明書を無効化するときに、カウンタ値をインクリメントするカウンタと、カウンタ値がインクリメントされたとき、前記許可フラグを含む管理情報に前記インクリメントされたカウンタ値を設定するカウンタ値設定手段と、前記管理情報に設定された前記カウンタ値を用いて前記管理情報が改竄されているか否かを判定する判定手段とを備える。
【００２３】
本発明の第10の態様によると、前記装置はさらに、前記許可フラグと前記カウンタ値とを含む前記管理情報の暗号技術的ハッシュ値を算出する算出手段と、前記算出された暗号技術的ハッシュ値に対応する検証値を格納する値格納手段と、前記選択手段が前記1つの更新された証明書を選択するために前記管理情報を用いる前に、前記格納された検証値と前記算出された暗号技術的ハッシュ値とを比較することにより、前記管理情報が改竄されているか否かを検証する検証手段を備える。
【００２４】
本発明の第11の態様によると、前記装置はさらに、前記複数のソフトウェアと前記複数の証明書の間のマッピングを示すマッピングデータを格納するマッピングデータ格納手段と、前記マッピングデータの暗号技術的ハッシュ値を算出する算出手段と、前記算出された暗号技術的ハッシュ値に対応する検証値を格納する値格納手段と、前記選択手段が前記1つの更新された証明書を選択する前に、前記格納された検証値と前記算出された暗号技術的ハッシュ値とを比較することにより、前記マッピングデータが改竄されているか否かを検証する検証手段を備え、前記選択手段は、前記マッピングデータに基づき前記1つの更新された証明書を選択する。
【００２５】
本発明の第12の態様によると、前記装置はさらに、前記無効化手段が前記格納手段に格納されている前記1つの証明書を無効化するときに、カウンタ値をインクリメントするカウンタと、カウンタ値がインクリメントされたとき、前記マッピングデータに前記インクリメントされたカウンタ値を割り当てるカウンタ値割り当て手段とを備え、前記算出手段は、前記マッピングデータと前記マッピングデータに割り当てられた前記カウンタ値とを用いて前記暗号技術的ハッシュ値を算出する。
【００２６】
＜本実施形態の概要＞
本実施形態は、ソフトウェアの検証に用いられる証明書を更新することができるシステムに関する。装置が1つ以上のオプショナルなコンポーネントを有する場合、どのコンポーネントをアクティブ化するかは、ユーザの決定次第である。よって通常、サーバは、アクティブなコンポーネントに対応する更新された証明書を送信するために、各装置においてどのコンポーネントがアクティブ化されているかを知っていなければならない。そしてサーバは、各装置のアクティブなコンポーネントに対応する、更新された証明書のカスタマイズされたセットを、各装置に送信する。
【００２７】
しかし、装置毎にカスタマイズされたセットを作成するのは煩雑で、費用もかかる。よって、本実施形態は、装置毎にカスタマイズされたセットを作成することなく、証明書を更新するシステムを示す。
【００２８】
さらに、従来技術においては、オプショナルなコンポーネントを無効化することができない。したがって、インストール後に脆弱であることが判明しても、オプショナルなコンポーネントを無効化することは不可能であった。コンポーネントを無効化するためには通常、無効なコンポーネントを示す無効化リストが各装置に送信される。しかし、例えば携帯電話システムにおいて、ユーザに無効化リストのダウンロードを強いることは、そのダウンロードにさえ通信費がかかることから、困難である。この通信費をユーザではなく製造業者が負担することも可能だが、この費用のために無効化リストのダウンロードまたは送信が困難になっていることには変わりはない。
【００２９】
よって、本発明は、コンポーネントを簡単かつ合理的に無効化できるシステムを示す。
【００３０】
本実施形態において、サーバは、当該装置でアクティブ化可能なソフトウェアの候補全てを含む、更新された証明書のセットを作成する。そして装置は、サーバからそのセットを受信し、装置でアクティブ化するソフトウェアに対応する更新された証明書を検索する。この構成により、サーバは、更新された証明書のセットを各装置用にカスタマイズする必要がない。
【００３１】
この構成により、本発明の本態様によると、サーバが送信する証明書のセットをカスタマイズすることなく、証明書を適切に更新することが可能である。
【００３２】
さらに、ソフトウェアを無効化するために、サ―バは無効なソフトウェアに対応する証明書をセットから除外する。また、受信したセットに1つ以上の証明書が含まれていないことが分かった場合は、装置はその証明書が無効であると判断する。装置は、無効な証明書を削除することでコンポーネントを無効化する。証明書が削除されると、その証明書に対応するコンポーネントの検証は必ず失敗する。その結果、そのコンポーネントもまた無効化される。
【００３３】
この構成により、本実施形態では、無効化リストなどの追加情報を送信することなく、コンポーネント（およびそのコンポーネントに対応する証明書）を無効化することができる。
【００３４】
本発明は、セキュアブートを実行するシステム内でオプショナルもしくは失敗のコンポーネントをサポートするためのシステムに関する。後述する追加のRIM証明書およびデータテーブルを提供することにより、セキュアブートをサポートする装置の開発者は、起動に失敗したコンポーネント柔軟に扱うシステムや、セキュアブートによってもたらされる信頼された環境内で、コンポーネントの状態を報告できる装置を生産できる。さらに、アクティブなオプショナルなコンポーネントのリストを備えることで、システムが、外部関係者によって有効化および無効化される可能性のあるコンポーネントも処理できるようになる。本実施形態は、装置内の少なくとも1つのコンポーネントがオプショナルなコンポーネントであり、そのコンポーネントおよびそのコンポーネントのブート時よりも前にブートした他のコンポーネントを検証するために証明書を用いるシステムを想定している。よって、通常のシステムでは、あるコンポーネントのブートプロセスの失敗が、その失敗したコンポーネントの後にブートする他のコンポーネントに影響を与える。これは、その失敗したコンポーネントがオプショナルなコンポーネントであり、他のコンポーネント自体は有効だとしても起こることである。この問題を避けるために、本実施形態では、以下に説明するように、失敗RIM証明書および成功RIM証明書を用いている。
【００３５】
この構成もまた、従来技術よりも新しい技術である。しかしながら、証明書の更新および無効化に関する本発明の一部は、上記に示した課題を扱わないシステムにも適用できる。
【００３６】
セキュアブートをサポートする装置の、オプショナルなコンポーネントの取り扱いを含む、コンポーネントを更新および無効化するための新しいシステムおよび方法を説明する。本願を完全に理解するため、以下、具体的な詳細を多数挙げて説明する。他の例では、周知の構造および装置をブロック図に示し、説明を簡単にするため、具体的な詳細は説明していない。しかしながら、当業者であれば、改良により、またはそのような具体的な説明なくとも、本願を実施することができるのは明らかである。好適な実施形態の説明により、クレームの範囲が限定されるものではない。
【００３７】
＜本実施形態の詳細＞
図1は、携帯装置のライフサイクルを示す。工場(100)で、初期化プロセス(102)において、各装置でどのオプショナルなコンポーネントが利用可能であるかを示す情報と共にオプショナルなコンポーネントのセットをインストールする。携帯装置が携帯電話販売店(106)またはオンラインストア等の他の販売業者に出荷されると、顧客はオプショナルなコンポーネントに対応する様々なオプションの購入(108)が可能になる。これで携帯装置(110)が使用できる状態になり、その装置の使用期間中、オプショナルなコンポーネントおよび必須のコンポーネント用の証明書(112)が全装置に送信される（114）。さらに、その装置の所有者は、携帯通信事業者または他の装置管理団体が提供するサーバ(118)を介して契約オプションのセットを明示的に更新し(116)、ある特定の装置で利用可能なオプショナルなコンポーネントを更新することが可能である。オプショナルなコンポーネントの管理に係る各プロセスの動作を以下に説明する。
【００３８】
図2は、本発明の一態様、具体的には、システム内のオプショナルなコンポーネントの作成および維持の方法、および、携帯装置110の構成を示す。重要な機能要素およびデータの項目は以下の通りである。まず、データ構造は全て、完全性保護(200)されており、好適な実施形態において、これは署名されたハッシュを用いることで達成されている。このデータ構造は、まず、成功RIM証明書202および失敗RIM証明書204である。成功RIM証明書は、全てのコンポーネントが適切に動作している場合の、セキュアブート中に予想されるプラットフォームの状態を記述したものであり、失敗RIM証明書は、1つ以上のコンポーネントが適切に動作しなかった場合の、セキュアブート中に予想されるプラットフォームの状態を記述したものである。ラベル-証明書対応テーブル206は、信頼されたコンポーネントの状態を特定の成功RIM証明書202または失敗RIM証明書204に対してマッピングし、オプショナルコンポーネント制御テーブル208は、どのオプショナルな信頼コンポーネントがアクティブで、どれが非アクティブかを記述し、デフォルトオプショナルコンポーネント制御テーブル210は、携帯電話の初回ブート時、または万一オプショナルコンポーネント制御テーブル208が破損した場合等に、オプショナルコンポーネント制御テーブル208を初期化する際に用いられる。好適な実施形態において、このテーブルの構造はオプショナルコンポーネント制御テーブル208の構造と同様である。このオプショナルコンポーネント制御テーブル208を初期化するため、イニシャライザ(226)が、デフォルトオプショナルコンポーネント制御テーブル210に基づいて、オプショナルコンポーネント制御テーブル208を作成する。このプロセスの詳細は後に説明する。
【００３９】
証明書更新部(212)は、携帯電話通信塔から無線ネットワークを通じて送出され、更新受信部(214)により装置が受信（216）する証明書リストを処理することにより、成功RIM証明書202および失敗RIM証明書204を最新の状態に保つ。このプロセスの詳細は後に説明する。当業者であれば、メモリカードやその他の有線または無線の送信手段を介する等、他にも更新を可能にする方法があることがわかるであろう。
【００４０】
契約更新部（218）は、装置上のウェブブラウザ(220)に、サーバ(224)にあるオプショナルなコンポーネントの維持ペ―ジにアクセスするよう要求することで、オプショナルコンポーネント制御テーブル208をアクティブな状態、および非アクティブな状態に保つ。好適な実施形態において、ウェブブラウザ(220)からサーバ(224)への接続には、通信路を攻撃から守るためにセキュアソケットレイヤ(SSL)を用いる(222)。このプロセスの詳細は後に説明する。
【００４１】
図3は、RIM証明書300、従来技術により定義されるRIM証明書の拡張である成功RIM証明書202および失敗RIM証明書204の詳細を示す。オプショナルなコンポーネントをサポートできるようにするため、mapLabeltoCertTableSize 306およびmapLabeltoCertTable 308が証明書に加えられ、extensionDigest 304のエントリは、これらの追加されたデータの暗号技術的ハッシュ値を含む。この拡張されたRIM証明書の例は1つだけでよく、また実施の形態ではこれらのテーブルをRTV+RTMが自己検証に使用する単一のRIM証明書に付加する。しかし、従来技術のこの態様は、ここでは述べない。
【００４２】
技術分野の当業者は、RIM証明書300を使用することなく、mapLabeltoCertTable 308の完全性を利用可能にし、維持する他の方法、例えば、署名者および装置の両方に既知の秘密鍵を使用したデジタル署名など、他の方法があることを理解できるであろう。
【００４３】
図4は、論理的識別子および1つ前に起動するソフトウェアコンポーネントから実際のRIM証明書までのマッピングを示すデータエントリを持つthe Map label to Cert table 308のフォーマットを示す。第1列の、論理証明書ラベル400は、RIM証明書のための特定の役割を示す識別子であり、システムの他の部分がRIM証明書を要求するために使用する識別子である。第2列の、依存する信頼コンポーネントの状態402には、どの信頼コンポーネントエラー状態のセットに対して各行が有効であるかを示すフラグが並べられている。第3列の、依存する信頼コンポーネントのマスク404には、どのコンポーネントの状態をチェックするべきかを示すフラグが並べられている。実施の形態では、これらの２つの列は、ビットマップを使用して実装される。最後に、RIM証明書ラベル406の列には、RIM証明書データベースから成功RIM証明書202または失敗RIM証明書204を検索するために用いられる実際のRIM証明書ラベルが保持されている。この値は、TCGで定義されるRIM証明書のlabelフィールド302を表す。
【００４４】
携帯装置の所有者、プロバイダー、製造業者等の外部関係者によって選択的にアクティブ化される可能性のあるこれらの信頼コンポーネントを管理するため、その装置は、どのオプショナルな信頼コンポーネントがアクティブで、どれが非アクティブであるかを示すリストを維持する。図5は、オプショナルコンポーネント制御構造体208におけるこのデータの好適な実施形態を示す。RIMProtectValue(502)は、ロールバックまたはリフラッシュの攻撃からの構造体の保護を支援するため、構造体作成時のTCG Mobile Trusted Module仕様書が定義するcounterRIMProtect単調カウンタのコピーである。その下に来るのは各行が2つのフィールドをもつテーブルである。最初のフィールドは、オプショナルな信頼コンポーネントの論理証明書ラベル（504）であり、ここではmapLabeltoCertTable(308)内の論理証明書ラベル(400)に用いられるものと同一のコンポーネント識別子が用いられている。次は、論理証明書ラベル(504)によって特定されるオプショナルな信頼コンポーネントが有効化されているか否かを示すフラグ(506)であり、有効化されている場合はTRUEに、有効化されていない場合はFALSEに設定される。この値のペアは、システム内の各オプショナルな信頼コンポーネントに対し繰り返され、-1の論理証明書ラベル(508)、および、非アクティブにするために通常はFALSEに設定されるフラグ(510)によりテーブルを終了する。この値のペアのセットの集合は、論理証明書ラベルテーブル(514)として知られている。最後に、オプショナルコンポーネント制御構造体内の上記データ全てを改竄から保護するために、PDCS v1.5アルゴリズムにしたがって生成され、下記図6で説明する通りに作成された外部プロセスからは利用できない秘密鍵を使って署名された暗号署名(512)がある。当該技術分野の当業者は、各オプショナルなコンポーネントの状態の完全性を利用可能にし、維持できる他の方法を理解するだろう。
【００４５】
図19は、本発明の別の態様、つまり、装置のユーザによるオプショナルなコンポーネントの維持を可能にするサーバ(224)の構造体が、その装置上で有効化または無効化されることを示す。重要な機能要素およびデータ項目は以下の通りである。秘密生成部(1902)、ページ生成部(1908)、オプション処理部(1916)、暗号化部(1920)、およびトランザクションコミッタ(1926)の5つのブロックは、外部装置へのインターフェースポイントであり、情報の伝達は左から右へ進む。まず、秘密生成部(1902)が、Diffe-Hellman等の、双方向通信プロトコル(1900)を用いて共有鍵(1904)を確立する。次に、携帯装置が契約維持ウェブページを要求する(1906)。その結果、ページ生成部(1908)がページを作成し、ページ生成部(1908)が現在のオプショナルなコンポーネントの状態を顧客オプション維持部(1910)に要求し、顧客オプション維持部(1910)が現在の状態を知るために顧客オプションデータベース(1912)に問い合わせを行う。装置のユーザが生成されたウェブページとの交信を終えると、完了メッセージがサーバに送信され(1914)、オプション処理部(1916)が、顧客オプション維持部(1910)にその新たなオプションを通知し、顧客オプションデータベース(1912)内でトランザクションを開始する。そのオプションはオプショナルコンポーネント制御構造体生成部(1918)に送られ、そこでオプショナルコンポーネント更新構造体（1800）にフォーマットされる。暗号化部(1920)が、共有鍵(1904)でこの構造体を暗号化し、その構造体を携帯装置に返す(1922)。最後に、装置が全ての内部構造体を更新し終えると、トランザクションコミッタ(1926)が完了メッセージを受信し(1924)、顧客オプション維持部(1910)に、顧客オプションデータベース(1912)内で進行中のトランザクションを完了しなければならないことを通知する。
【００４６】
図6は、本発明のオプショナルコンポーネント制御構造体の初期作成を示す。図示されたプロセスは、TCG Mobile Trusted Module仕様書に初期ブート用に詳述されている通り、ひとたびMTMが初期起動すると起こる、装置を初めてブートする時のプロセスである。また、そのドキュメントに詳述されているように、初期ブートは携帯装置のライフサイクルにおいて他の時点でも起こりえるため、図6は必要に応じた構造体の再作成も示す。まず、一連の初期ブートにおいてMTMおよび信頼性のルートを確立して初期化するために十分な初期化を行った後に、MTMからのオプショナルコンポーネント制御構造体に署名するための秘密鍵が要求される(600)。好適な実施形態において、秘密鍵はRSAキーペアの秘密鍵を示す。この要求の成功または失敗がチェックされ(602)、MTMが要求された鍵を発見できなかったときは、MTM内で秘密鍵を作成する(604)。この鍵は、TPMメイン仕様書パート2に定義されている使用法タイプであるTPM_KEY_SIGNINGで作成されなければならない。また、好適な実施形態において、この鍵のアルゴリズムは1024ビット長のTPM_ALG_RSAであり、TPM_SS_RSASSAPKCSA1v15_SHA1署名スキームとともに使用できる。しかし、秘密鍵が見つかったときは(602)、鍵を作成する必要がなく、その代わりに、既存の、有効に署名されたオプショナルコンポーネント制御構造体(208)があるか否かを確認するためのチェックを行う(606)。構造体がある場合は、構造体を再作成すると例えば変更されたオプションを上書きする可能性があることから、構造体は再作成する必要がなく、TCG Mobile Reference Architectureに定められているように、初期ブート手順が他の処理と共に進む。オプショナルコンポーネント制御構造体(208)がない場合は、MTMがRIM証明書を保護するために管理する単調カウンタが要求され(610)、オプショナルなコンポーネントのデフォルト状態情報が要求される(612)。新たなオプショナルコンポーネント制御構造体(208)が作成され、単調カウンタがRIMProtectValueフィールド(502)に、また、オプショナルなコンポーネントおよびその状態がフィールド504およびフィールド506に挿入され、テーブルターミネータ508および510が作成される。次に、この新たな構造体が、先に作成または取得された鍵を用いた暗号署名の要求と共に、MTMに送られる（616）。この署名プロセスにより、暗号署名(512)が作成される。これで、所望の、改竄できないオプショナルコンポーネント制御構造体(208)が格納された。これで、オプショナルコンポーネント制御構造体(208)の作成プロセスが完了し、初期ブート手順が、TCG Mobile Reference Architectureに定められている通り、他の処理と共に進む(620)。
【００４７】
図7は、TCG Mobile Reference Architecture version 1.0 revision 1のセクション6.3.4.2に記載されているRIM更新のタスクに必要な、本発明の追加的な処理を示す。その仕様書は、RIM_Authがどのように検証されるか、外部RIM_Certがどのように自身のCounterBootstrapをチェックさせるか、そしてどのように内部RIM証明書が作成され、ソフトウェアがインストールされるかを説明している。図7に示すプロセスは、内部RIM証明書を作成するべきか否か、またソフトウェアをインストールするべきか否かを判定するCounterBootstrapチェックの後に実行される。まず、オプショナルコンポーネント制御構造体をMTMから取得する(700)。次に、データが依然として有効で、かつ改竄されていないことの検証を可能にするために、暗号署名512の作成に用いられる秘密鍵の公開部分がMTM102から取得され(702)、現在のcounterRIMProtect単調カウンタがMTM102から取得される(704)。署名を検証して当該データが改竄されていないことを確かめ、現在のcounterRIMProtect単調カウンタを、この構造体に格納されているRIMProtectValue502と比較する(706)。その格納された値が、現在の単調カウンタ値よりも大きいか、または同じである場合、オプショナルコンポーネント制御構造体は最新であり、この構造体にリフラッシュやロールバック攻撃が起こっていないことを示している。その2つのチェックの結果が、署名が正しくないか、または現在の単調カウンタの値が構造体内のRIMProtectValue502よりも大きいことを示す場合は（708）、このRIM更新プロセスは失敗し（712）、インストールされたプログラムもRIM証明書も変更されない。しかしながら、そのチェック結果が、オプショナルコンポーネント制御構造体が有効であることを示す場合は、更新する対象の外部RIM証明書を取得する(710)。外部RIM証明書からの証明書ラベルは、mapLabeltoCertTable 308内にRIM証明書ラベル406とラベル付けされている第4列を検索するために用いられ（714）、このラベルに対する対応論理証明書ラベル400は適合する行の第1列をチェックすることにより発見される(716)。テーブル内にそのラベルが見つからないときは、このRIM証明書はオプショナルなコンポーネント用ではなく、必須コンポーネント用であるので、TCG Mobile Reference Architectureで説明されている通りにインストールしてもよい(720)。
【００４８】
しかし、対応する論理証明書ラベル400が見つかった場合、このラベルは、論理証明書ラベル504のオプショナルコンポーネント制御構造体のテーブル208を検索するために用いられる(718)。対応するエントリが見つからないときは(722)、このRIM証明書は外部から有効化または無効化できるものではないので、TCG Mobile Reference Architectureで説明されている通りにインストールしてもよい(720)。対応するエントリが見つかった場合は、有効フラグ506を取得し(724)、チェックする(726)。有効化されている場合は、外部RIM証明書を、TCG Mobile Reference Architectureで説明されている通りにインストールしてもよい(720)。有効化されていない場合は、この証明書が制御するコンポーネントはアクティブ化を許可されていないため、外部RIM証明書はインストールされない(728)。
【００４９】
図8は、本発明の、TCG Mobile Reference Architectureのセクション6.3.4.2で説明されているRIM無効化のタスクに必要な、追加の処理を示す。その仕様書には、RIM_Authがどのように検証されるか、RIM_Cert有効性リストがどのようにチェックされ、新たな有効性リスト上の対応する外部RIM_Certを有しない全ての内部RIM_Certが削除されるか、残りの全ての内部RIM_Certがどのように再有効化されるか、また、counterRIMProtect単調カウンタがどのように更新されるかが説明されている。図8が示すプロセスにより、counterRIMProtect単調カウンタが更新され、残りの全ての内部RIM_Certが再有効化される。まず、オプショナルコンポーネント制御構造体(510)をMTM102から取得する(800)。次に、データが依然として有効で、かつ改竄されていないことの検証を可能にするために、暗号署名512の作成に用いられる秘密鍵の公開部分をMTMから取得し(802)、かつ現在のcounterRIMProtect単調カウンタをMTMから取得する(804)。署名を検証して(806)当該データが改竄されていないことを確かめ、現在のcounterRIMProtect単調カウンタを、オプショナルコンポーネント制御構造体(510)に格納されているRIMProtectValue502と比較する。その格納された値が、現在の単調カウンタ値よりも大きいか、または同じである場合、オプショナルコンポーネント制御構造体は最新であり、その構造体にリフラッシュやロールバック攻撃が起こっていないことを示している。その2つのチェックの結果が、署名が正しくないか、または現在の単調カウンタの値がオプショナルコンポーネント制御構造体(510)内のRIMProtectValue502よりも大きいことを示す場合は(808)、このRIM無効化プロセスは失敗し(810)、インストールされたプログラムもRIM証明書も変更されない。しかしながら、そのチェック結果が、オプショナルコンポーネント制御構造体が有効であることを示す場合は、オプショナルコンポーネント制御構造体(510)内のRIMProtectValue502を、804で取得したcounterRIMProtect単調カウンタの現在の値に1を足したものに設定する（812）。暗号署名は、802で取得した秘密鍵で署名されたPKCS v1.5アルゴリズムにしたがって生成される(814)。次に、TCG Mobile Reference Architectureに説明されているタスクを実行する。既存の内部RIM証明書が、インクリメントされたRIMProtectカウンタ値で再有効化され(816)、RIM証明書およびオプショナルコンポーネント制御構造体(208)をロールバックやリフラッシュ攻撃から保護するために、counterRIMProtect単調カウンタの値がインクリメントされる(818)。最後に、残りの無効化機能をTCG Mobile Reference Architecture仕様書に説明されているように実行する。
【００５０】
図9は、オプショナルなコンポーネントのアクティブ化および非アクティブ化を制御する携帯装置(900)とサーバ(904)の間の通信処理を示す。加えて、携帯装置(900)のMobile Trusted Module (902)から、携帯装置(900)が要求するサービスも示す。まず、ユーザが、サーバに格納されている契約維持オプションを要求する(906)。好適な実施形態において、これは、サーバとSSL(セキュアソケットレイヤ)セッションを確立することによって実行する。そしてサーバは、装置のIDおよび信頼性を検証するために、TCG仕様書アーキテクチャの概要で定義されているような装置の認証を行う(908)。装置は、MTM902からサーバへのレポートを可能にするために、MTM902へ認証の要求を転送する(910)。MTM902から、装置を介してサーバへ確認メッセージを返す(912、914)。認証が成功し完了すると、好適な実施形態においては、顧客はDiffie-Hellman鍵交換によってサーバとの間で共有秘密を確立する(916、918)。次にサーバが、特定された装置に適した、カスタマイズされたオプショナルなコンポーネントのページを送信する（920）。好適な実施形態において、これは、HTMLベースのページであり、どのオプションを装置に追加するか、または削除するかを選択するために装置のユーザが交信する(922)。所望の変更がなされた後、装置は、各オプショナルなコンポーネントの新しい有効な状態または無効な状態を含む、交信完了を示すメッセージを送信する(924)。好適な実施形態において、これは、POSTによって、先に送信されたカスタマイズされたオプションページ(920)内に記述されているHTTPSページに実行される。他の好適な実施形態において、装置は装置のユーザが行った変更毎に別々のメッセージを送信する。他の好適な実施形態において、装置は、AJAXベースのメカニズムを用いて変更が行われる毎にすぐに、別々のメッセージを送信し、ユーザは、一旦変更を終えると完了メッセージを送信するオプションを選択する。サーバは、サーバの顧客データベースを適切に更新してから、装置に、916および918で確立された鍵で暗号化された、新たな更新されたコンポーネントのセットを送信する(926)。これらのステップは、図19の項目1914、1916、1918、1920および1922に対応する。好適な実施例において、そのデータは論理証明書ラベルテーブル（514）と同様のフォーマットで記述される。つまり、論理証明書ラベル(504)と有効フラグ(506)との複数のペアと有し、-1(508)とFALSE(510)との一組のペアで終了する。これは図18に示されており、オプショナルなコンポーネント更新構造体(1800)は、上述のような論理証明書ラベルテーブル(514)、およびデータが送信中に破損していないことを保証するテーブルのハッシュ(1802)を有する。装置はこのメッセージを復号し(928)、テーブルのハッシュ(1802)を検証する。それが成功すると、有効なコンポーネントまたは無効なコンポーネントを確実に正しく構成するようにオプションの処理を開始する。
【００５１】
装置の次のタスクは、現在の全ての内部RIM証明書をスキャンし、オプショナルコンポーネント更新構造体(1800)内のオプショナルなコンポーネントの状態のリストに従って、どの内部RIM証明書が無効化されたコンポーネントに使用されているかを判定することである。以下に、このタスクの実行方法を説明する。まず、装置が、現在装置上にある各内部RIM証明書に対し(936)、無効なコンポーネントを表しているか否かを判定する(930)。各内部RIM証明書からの証明書ラベルは、mapLabeltoCertTable 308内にRIM証明書ラベル406とラベル付けされている第3列を検索するために用いられ、適合する行の第1列をチェックすることにより、このラベルに対する対応論理証明書ラベル400が発見される。928で復号された更新されたオプションを、更新された論理証明書ラベル504が存在するか否かを確認するためにチェックし、もしあれば、有効フラグ506をチェックする。ない場合は、この内部RIM証明書は922で無効化されたオプショナルなコンポーネント用であるので、この証明書は削除される(932)。その他全ての状況では、RIM証明書は維持され、インクリメントされたRIMProtectカウンタと共に再インストールされる。全ての既存のRIM証明書がチェックされると、MTM902からの現在のRIMProtectカウンタ値が要求され(938)、MTM902から装置にこの値が返される(940)。新たなオプショナルコンポーネント制御構造体が、940で読み出されたRIMProtectカウンタ値よりも1つ大きな値と、928からの更新されたオプション情報とを用いて作成される(924)。MTM902に対し、図6に示した方法により生成された署名鍵を用いてデータに署名するよう要求する(944)。MTM902が署名を返し(946)、装置が新たなオプショナルコンポーネント構造体を作成し、以前の構造体を上書きして格納する(948)。
【００５２】
これで装置は、必要に応じ、外部RIM証明書および更新されたコンポーネントを、アクティブ化されたオプショナルなコンポーネント用に受信できる状態になった。そうして、装置はこれらのコンポーネントをサーバに要求する(950)。好適な実施形態において、装置からの通知を受信した(924)後にどのコンポーネントが有効化されたかに関する記録はサーバが有するため、装置は、送信開始の簡単な要求を送信する必要がある。サーバは、更新されたコンポーネントを送信する(952)。好適な実施形態において、送信および更新をインストールする(954)方法はTCG Mobile Reference ArchitectureのRIM更新で説明されている通りである。他の好適な実施形態において、サーバは、全てのコンポーネントに対する更新された証明書およびソフトウェアを送信し、図7に記載の処理により、無効なコンポーネント用の外部RIM証明書がインストールされないことを保証する。この実施形態において、有効なオプショナルなコンポーネント用の更新された証明書は、常に更新された証明書に含まれている。よって、携帯装置ではどのようなオプショナルなコンポーネントも有効化できる。そしてサーバは、携帯装置でどのオプショナルなコンポーネントが有効かを検知することなく、更新された証明書を作成できる。これにより、サーバに係るコストおよび負荷を減らすことができる。ロールバックやリフラッシュ攻撃から保護するために、装置はMTM902に対しRIMProtect単調カウンタのインクリメントを要求し（956）、MTM902は動作の成功を応答する(958)。これで、オプショナルなコンポーネントに関連する、装置の全ての情報、具体的には、オプショナルコンポーネント制御構造体(208)、適切な成功RIM証明書(202)および失敗RIM証明書(204)、ならびにcounterRIMProtect単調カウンタが成功裏に更新され、装置がサーバに対し、処理の完了を通知する(960)。最後に、確実に新たに有効化されたコンポーネントが動作し、無効なコンポーネントが動作をストップするように、装置が再ブートする（962）。
【００５３】
図10はこの実施形態のセキュアブートプロセスを示す。このセキュアブートプロセスは、オプショナルコンポーネント制御構造体(208)が有効であることを検証するための動作を含む。この処理は、引用した特許出願に記載のようにネクストコンポーネントテーブルおよびラベル-証明書対応テーブルの検証後に行われる。まず、オプショナルコンポーネント制御構造体（208）上の署名を検証するための秘密鍵の公開部分を取得する(1000)。鍵が見つからない場合は(1002)、エラーが起こり、適切な対応が取られる（1004）。好適な実装形態において、これをきっかけとして、図6に示されるようにデフォルトのオプショナルコンポーネント制御構造体（208）が再作成される。鍵がある場合は、オプショナルコンポーネント制御構造体（208）を要求する(1006)。構造体が存在しない場合は(1008)、エラーが起こり、適切な対応が取られる(1004)。ここで、counterRIMProtect単調カウンタ値を取得し(1010)、オプショナルコンポーネント制御構造体(208)を検証する(1012)。これは、改竄を検知するために、算出された署名が格納されている署名に適合すること、および、格納されているRIMProtectValue(502)が呼び出された単調カウンタ値よりも大きいかまたは同じであることをチェックすることの両方を含む。これが失敗した場合は(1014)、エラーが起こり、適切な対応が取られる(1004)。これが成功した場合は(1014)、オプショナルコンポーネント制御構造体（208）は有効であり、引用した特許公報に記載されているようにセキュアブートプロセスを続行する（1016）。
【００５４】
オプショナルコンポーネント制御構造体（208）内のカウンタの使用方法において、現在のcounterRIMProtect単調カウンタが4にインクリメントされた場合を説明する。この値4は、オプショナルコンポーネント制御構造体(208)のRIMProtectValueフィールド（502）にも格納され、秘密鍵で署名される。ここで、攻撃者がこの構造体を保存して、図9で説明したプロセスで全てのオプショナルなコンポーネントを無効化した場合、counterRIMProtect単調カウンタを5にインクリメントされ、この5の値は、オプショナルコンポーネント制御構造体(208)のRIMProtectValueフィールド（502）にも格納され、秘密鍵で署名される。しかし、ユーザが無効なコンポーネントを使用しようと、4の値のRIMProtectValue（502）を伴う古いオプショナルコンポーネント制御構造体(208)をコピーバックし、装置をリブートした場合、図10で説明したチェックがこれを検出する。オプショナルコンポーネント制御構造体(208)の検証(1012)は、格納されている4の値のRIMProtectValue（502）と、5の値のRIMProtectValueを比較することを含む。その結果、格納された値の方が低いので、検証は失敗し（1014）、エラーが発生する（1004）。
【００５５】
上述のように、図5〜図10はオプショナルコンポーネント制御構造体(208)がRIMProtectValue（502）および暗号署名（512）を有する場合の好適な実施形態を示しているが、以下に、オプショナルなコンポーネントの、有効な状態、または無効な状態を維持するための他の好適な実施形態を説明する。
【００５６】
図11は、先に説明したオプショナルコンポーネント制御構造体（208）の簡易版であるオプショナルコンポーネント制御構造体(1100)における、このデータの好適な実施形態を示す。上述のように、各行に2つのフィールドをもつテーブルがあり、最初のフィールドは、オプショナルな信頼コンポーネントの論理証明書ラベル（504）であり、ここではmapLabeltoCertTable(308)内の論理証明書ラベル(400)に用いられるものと同一のコンポーネント識別子が用いられている。次は、論理証明書ラベル(504)によって特定されるオプショナルな信頼コンポーネントが有効か否かを示すフラグ(506)であり、有効な場合はTRUEに、無効な場合はFALSEに設定される。この値のペアは、システム内の各オプショナルな信頼コンポーネントに対し繰り返され、-1の論理証明書ラベル(508)、および非アクティブにするために通常はFALSEに設定されるフラグ(510)によりテーブルを終了する。この値のペアのセットの集合は、論理証明書ラベルテーブル(514)として知られている。
【００５７】
図12は、オプショナルコンポーネント制御構造体(1100)の完全性を維持するために用いられるオプショナルコンポーネント制御RIM証明書の好適な実施形態を示す。このRIM証明書は、装置内で作成されることから、TCG Mobile Trusted Module仕様書に定義されるように、常に内部RIM証明書である。単一の装置の中に、そのような証明書は1つのみしかないことから、label(1202)は固定ストリングであり、好適な実施形態において「OCC_RIMC」に設定される。先の実施形態において、ロールバックまたはリフラッシュの攻撃からの保護にはRIMProtectValue(502)が用いられたが、ここではreferenceCounter(1204)を用いる。このフィールドは、TCG Mobile Trusted Module仕様書に定義されるように、MTMにより管理される。このRIM証明書は、決してMTM API MTM_VerifyRIMCertAndExtendには送られないため、state（1206）はTPM_PCR_SELECTIONが空になるように設定され、measurementPCRIndex(1208)の値は0に設定される。measurementValue(1210)は、オプショナルコンポーネント制御構造体(1100)のハッシュを格納する。好適な実施形態では、この値の生成にSHA-1アルゴリズムを用いる。このハッシュに署名する必要はない。フィールドextensionDigestSize(1212)は0に設定され、extentionDigest(1214)は表示されない。他の好適な実施形態において、フィールドを0に設定したmeasurementValue(1210)のハッシュを格納する代わりに、extentionDigest(1214)がオプショナルコンポーネント制御構造体(1100)のハッシュを格納し、extensionDigestSize(1212)がこのハッシュの大きさをバイト単位で保持する。最後に、integrityCheckSize(1216)およびintegrityCheck(1218)が、TCG Mobile Trusted Module仕様書に定義されるように、完全性チェック情報を格納する。
【００５８】
図13は、本発明のオプショナルコンポーネント制御構造体の、初期作成を示す。図示されたプロセスは、初期ブート用のTCG Mobile Trusted Module仕様書に詳述されている通り、ひとたびMTM 102が初期起動すると起こる、装置を初めてブートする時のプロセスである。また、そのドキュメントに詳述されているように、初期ブートは携帯装置のライフサイクルにおいて他の時点でも起こりえるため、図13は必要に応じた構造体の再作成も示す。まず、一連の初期ブートにおいてMTMおよび信頼性のルートを確立して初期化するために十分な初期化を行った後に、既存のオプショナルコンポーネント制御構造体(1100)が存在するか否かを確認するチェックを行う(1300)。構造体が既にあるときは(1302)、その構造体のハッシュを算出し(1304)、オプショナルコンポーネント制御RIM証明書（1200）を呼び出す(1306)。呼び出しが成功し、measurementValue(1210)に格納されたハッシュ値が1304で算出したハッシュ値と等しい場合、MTM_VerifyRIMCertがTPM_SUCCESSを返し、構造体が最新でかつ改竄されていないことを確認した場合は(1308)、TCG Mobile Reference Architectureに定義されているように、他の処理と共にその初期ブート手順を続ける(1320)。1302または1308何れかのチェック結果が失敗である場合は、オプショナルコンポーネント制御構造体（1100）およびオプショナルコンポーネント制御RIM証明書を再作成するか、または初めて作成する。まず、デフォルトのオプショナルコンポーネント制御構造体(1100)を作成し（1310）、その構造体のハッシュを算出する（1312）。次に、measurementValue(1210)を1312で算出したハッシュ値に設定して、署名されていないオプショナルコンポーネント制御RIM証明書（1200）を作成する(1314)。この署名されていない証明書を用いてMTM API MTM_InstallRIMを呼び出すことにより(1316)、MTMはMTM API MTM_InstallRIMを、有効な内部RIM証明書を作成するためのテンプレートとして用いる。有効な内部RIM証明書は、現在のcounterRIMProtect値をreferenceCounterフィールド(1204)に挿入し、TCG Mobile Trusted Module仕様書に定義されているように秘密内部鍵を用いてintegrityCheckData(1218)を生成することで作成される。これら2つの新たな構造体が格納され(1318)、TCG Mobile Reference Architectureに定められている通り、初期ブート手順が他の処理と共に続く(1320)。
【００５９】
図14は、本発明の、Mobile Reference Architecture version 1.0 revision 1のセクション6.3.4.2に記載されているRIM更新のタスクに必要な、本発明の追加的な処理を示す。その仕様書は、RIM_Authがどのように検証されるか、外部RIM_Certがどのように自身のCounterBootstrapをチェックさせるか、そしてどのように内部RIM証明書が作成され、ソフトウェアがインストールされるかを説明している。図14に示すプロセスは、内部RIM証明書を作成するべきか否か、またソフトウェアをインストールするべきか否かを判定するCounterBootstrapチェックの後に実行される。まず、オプショナルコンポーネント制御構造体をMTM102から取得する(1400)。次に、その構造体のハッシュを算出し(1402)、オプショナルコンポーネント制御RIM証明書（1200）を呼び出す(1404)。この呼び出しに失敗した場合、つまり、measurementValue(1210)に格納されたハッシュ値が1402で算出したハッシュ値と等しくない場合、またはMTM_VerifyRIMCertがTPM_SUCCESS以外の値を返し、この構造体が最新でないか、改竄されていることを示す場合は(1406)、更新処理は失敗である（1408）。しかしながら、全ての検査で問題がなければ、更新する対象の外部RIM証明書を取得する(1410)。外部RIM証明書からの証明書ラベルは、mapLabeltoCertTable 308内のRIM証明書ラベル406とラベル付けされている第4列を検索するために用いられ(1412)、適合する行の第1列をチェックすることにより(1414)、このラベルに対する対応論理証明書ラベル400が発見される。テーブル内にそのラベルが見つからないときは、このRIM証明書はオプショナルなコンポーネント用ではなく、必須コンポーネント用であるので、TCG Mobile Reference Architectureで説明されている通りにインストールしてもよい(1418)。
【００６０】
しかし、対応する論理証明書ラベル400が見つかった場合、このラベルは、論理証明書ラベル504のオプショナルコンポーネント制御構造体のテーブル1100を検索するために用いられる(1416)。対応するエントリが見つからないときは(1420)、このRIM証明書は外部から有効化または無効化できるものではないので、TCG Mobile Reference Architectureで説明されている通りにインストールしてもよい(1418)。対応するエントリが見つかった場合は、有効フラグ506を取得し(1422)、チェックする(1424)。有効化されている場合は、外部RIM証明書を、TCG Mobile Reference Architectureで説明されている通りにインストールしてもよい(1418)。有効化されていない場合は、この証明書が制御するコンポーネントはアクティブ化を許可されていないため、外部RIM証明書はインストールされない(1426)。
【００６１】
図15は、本発明の、TCG Mobile Reference Architectureのセクション6.3.4.5で説明されているRIM無効化のタスクに必要な、追加の処理を示す。その仕様書には、RIM_Authがどのように検証されるか、RIM_Cert有効性リストがどのようにチェックされ、新しい認証リスト上に対応する外部RIM_Certを有しない全ての内部RIM_Certがどのように削除されるか、残りの全ての内部RIM_Certがどのように再有効化されるか、また、counterRIMProtect単調カウンタがどのように更新されるかが説明されている。図15が示すプロセスにより、counterRIMProtect単調カウンタが更新され、残りの全ての内部RIM_Certが再有効化される。まず、オプショナルコンポーネント制御構造体をMTMから取得する(1500)。次に、その構造体のハッシュを算出し(1502)、オプショナルコンポーネント制御RIM証明書（1200）を呼び出す(1504)。この呼び出しに失敗した場合、つまり、measurementValue(1210)に格納されたハッシュ値が1502で算出したハッシュ値と等しくない場合、またはMTM_VerifyRIMCertがTPM_SUCCESS以外の値を返し、この構造体が最新でないか、改竄されていることを示す場合は（1506）、RIM無効化処理は失敗であり（1508）、インストールされたプログラムもRIM証明書も変更されない。
【００６２】
チェックの結果、オプショナルコンポーネント制御構造体（1100）が有効であることを示している場合は、MTMは、1504で取得した既存の証明書を用いてMTM API MTM_InstallRIMを呼び出して、referenceCounterフィールド(1204)に挿入された、インクリメントされたcounterRIMProtect値を伴う新しい内部RIM証明書を作成するためのテンプレートとして使用し、TCG Mobile Trusted Module 仕様書に説明されているように、秘密内部鍵を用いてintegrityCheckData(1218)を生成する。
【００６３】
次に、TCG Mobile Reference Architecture仕様書に説明されているタスクを実行する。既存の内部RIM証明書はインクリメントされたRIMProtectカウンタ値で再有効化され(1512)、counterRIMProtect単調カウンタがインクリメントされ、信頼されたコンポーネントのRIM証明書およびオプショナルコンポーネント制御RIM証明書（1200）の両方をロールバックまたはリフラッシュの攻撃から保護する。最後に、残りの無効化機能をTCG Mobile Reference Architecture仕様書に説明されている通りに実行する（1516）。
【００６４】
図16は、オプショナルコンポーネントのアクティブ化および非アクティブ化を制御する携帯装置(1600)とサーバ(1604)の間の通信処理を示す。加えて、携帯装置(1600)上のMobile Trusted Module(1602)から、携帯装置(1600)が要求するサービスも示す。この通信シーケンスの最初の部分に参照符号1606〜1636を付しており、これは、図9のステップ906〜936に相当する。よって、本ステップの説明はその部分を参照する。
【００６５】
まず、ユーザが、サーバに格納されている契約維持オプションを要求する(1606)。好適な実施形態において、これは、サーバとSSL(セキュアソケットレイヤ)セッションを確立することによって実行する。そしてサーバは、装置のIDおよび信頼性を検証するために、TCG仕様書アーキテクチャの概要で定義されているような装置の認証を行う(1608)。装置は、MTM1602からサーバへの報告を可能にするため、MTM1602に要求を転送する(1610)。MTM1602から、装置を介してサーバへ確認メッセージを返す(1612、1614)。認証が成功し完了すると、好適な実施形態においては、顧客はDiffie-Hellman鍵交換によって、サーバとの間で共有秘密を確立する(1616、1618)。次にサーバが、特定された携帯電話に適した、カスタマイズされたオプショナルなコンポーネントのページを送信する（1620）。好適な実施形態において、これは、HTMLベースのページであり、どのオプションを装置に追加するか、または削除するかを選択するために装置のユーザが交信する(1622)。所望の変更がなされた後、装置は、各オプショナルなコンポーネントの新しい有効な状態または無効な状態を含む、交信完了を示すメッセージを送信する(1624)。好適な実施形態において、これは、POSTによって先に送信されたカスタマイズされたオプションページ(1620)内に記述されているHTTPSページに実行される。他の好適な実施形態において、装置は装置のユーザが行った変更毎に別々のメッセージを送信する。他の好適な実施形態において、装置は、AJAXベースのメカニズムを用いて変更が行われる毎にすぐに、別々のメッセージを送信し、ユーザは、一旦変更を終えると完了メッセージを送信するオプションを選択する。サーバは、サーバの顧客データベースを適切に更新してから、携帯装置に、1616および1618で確立された鍵で暗号化された、新たな更新されたコンポーネントのセットを送信する(1626)。好適な実施例において、図5に示されるように、そのデータは論理証明書ラベルテーブル（514）と同様のフォーマットで記述される。つまり、論理証明書ラベル(504)と有効フラグ(506)との複数のペアを有し、-1(508)とFALSE(510)との一組のペアで終了する。これは図18に示されており、オプショナルなコンポーネント更新構造体(1800)は、上述のような論理証明書ラベルテーブル(514)、およびデータが送信中に破損していないことを保証するテーブルのハッシュ(1802)を有する。装置はこのメッセージを復号し(1628)、テーブルのハッシュ(1802)を検証する。それが成功すると、有効なコンポーネントおよび無効なコンポーネントを確実に正しく構成するようにオプションの処理を開始する。
【００６６】
まず、装置が、現在装置上にある各内部RIM証明書に対し(1636)、無効なコンポーネントを表しているか否かを判定する(1630)。各内部RIM証明書からの証明書ラベルは、mapLabeltoCertTable 308内にRIM証明書ラベル406とラベル付けされている第3列を検索するために用いられ、適合する行の第1列をチェックすることにより、このラベルに対する対応論理証明書ラベル400が発見される。1628で復号された更新されたオプションは、更新された論理証明書ラベル504があるか否かを確認するためにチェックされ、もしあれば、有効フラグ506がチェックされる。ない場合は、この内部RIM証明書は1622で無効化されたオプショナルなコンポーネント用であるので、この証明書は削除される(1632)。その他全ての状況では、RIM証明書は維持され、インクリメントされたRIMProtectカウンタを伴って再インストールされる(1634)。
【００６７】
全ての既存のRIM証明書がチェックされると、新しいオプショナルコンポーネント制御構造体(1100)を作成し(1638)、その構造体のハッシュを算出する（1640）。次に、measurementValue(1210)を1640で算出したハッシュ値に設定して、署名されていないオプショナルコンポーネント制御RIM証明書（1200）を作成する(1642)。この署名されていない証明書を用いてMTM API MTM_InstallRIMを呼び出すことにより(1644)、MTMはMTM API MTM_InstallRIMを、有効な内部RIM証明書を作成するためのテンプレートとして用いる。有効な内部RIM証明書は、現在のcounterRIMProtect値をreferenceCounterフィールド(1204)に挿入し、TCG Mobile Trusted Module仕様書に定義されているように秘密内部鍵を用いてintegrityCheckData(1218)を生成することで作成される。そして、MTMは携帯装置に署名された構造体を返す(1646)。この新たな構造体は格納され(1648)、その後ステップ1650〜1662が、図9のステップ950〜962と同じように実行される。よって、本ステップの説明はその部分を参照する。
【００６８】
これで装置は、必要に応じ、外部RIM証明書および更新されたコンポーネントを、アクティブ化されたオプショナルなコンポーネント用に受信できる状態になった。そうして、装置はこれらのコンポーネントをサーバに要求する(1650)。好適な実施形態において、装置からの通知を受信した後に(1624)どのコンポーネントが有効化されたかに関する記録はサーバが有するため、装置は、送信開始の簡単な要求を送信する必要がある。サーバは、更新されたコンポーネントを送信する(1652)。好適な実施形態において、送信および更新をインストールする(1654)方法はTCG Mobile Reference ArchitectureのRIM更新で説明されている通りである。他の好適な実施形態において、サーバは、全てのコンポーネントに対し更新された証明書およびソフトウェアを送信し、図14に記載の処理により、無効なコンポーネント用の外部RIM証明書がインストールされないことを保証する。この実施形態において、有効なオプショナルなコンポーネント用の更新された証明書は、常に更新された証明書に含まれている。よって、携帯装置ではどのようなオプショナルなコンポーネントも有効化できる。そしてサーバは、携帯装置でどのオプショナルなコンポーネントが有効かを検知することなく、更新された証明書を作成できる。これにより、サーバに係るコストおよび負荷を減らすことができる。ロールバックやリフラッシュの攻撃から保護するために、装置はMTM1602に対しRIMProtect単調カウンタをインクリメントするように要求し（1656）、MTM1602は動作の成功を応答する(1658)。これで、オプショナルなコンポーネントに関連する、装置の全ての情報、具体的には、オプショナルコンポーネント制御構造体(208)、適切な成功RIM証明書(202)および失敗RIM証明書(204)、ならびにcounterRIMProtect単調カウンタが成功裏に更新され、装置がサーバに対し、処理の完了を通知する(1660)。最後に、確実に新たに有効化されたコンポーネントが動作し、無効なコンポーネントが動作をストップするように、装置が再ブートする(1662)。
【００６９】
図17は、この実施形態のセキュアブートプロセスを示す。このセキュアブートプロセスは、オプショナルコンポーネント制御構造体(1100)が有効であることを検証するための動作を含む。この処理は、引用した特許出願に説明されているネクストコンポーネントテーブルおよびラベル-証明書対応テーブルの検証後に行われる。まず、オプショナルコンポーネント制御構造体RIM証明書（1200）を探す(1700)。RIM証明書が見つからない場合は(1702)、エラーが起こり、適切な対応が取られる(1704)。好適な実現例において、これをきっかけとして、図13に示されるようにデフォルトのオプショナルコンポーネント制御構造体（1100）および適合するオプショナルコンポーネント制御構造体RIM証明書（1200）が再作成される。RIM証明書がある場合は、オプショナルコンポーネント制御構造体(1100)も取得する。また、構造体が見つからない場合は(1708)、エラーが起こり、適切な対応が取られる(1704)。SHA-1を用いる好適な実施形態において、この構造体のためのハッシュ値を算出し、その結果をmeasurementValueフィールド(1210)のオプショナルコンポーネント制御構造体RIM証明書（1200）に格納されているハッシュ値と比較する。それらの値が異なる場合は(1714)、エラーが起こり、適切な対応が取られる(1704)。最終的な検証はMTMによって行われる。オプショナルコンポーネント制御構造体RIM証明書（1200）が、パラメータとしてMTM API MTM_VerifyRIMCertに送られる（1716）。MTM API MTM_VerifyRIMCertは、RIM証明書上の署名が有効であること、および、referenceCounter(1204)に格納されている値がMTMにより維持され、指示されている単調カウンタの値よりも大きいかまたは同じであることを検証する。MTMが、有効化失敗を示すエラーを返した場合は(1718)、エラーが起こり、適切な対応が取られる(1704)。成功を返した場合は、引用した特許公報に記載されているようにセキュアブートプロセスの続行が可能である(1720)。
【００７０】
本発明は上記の実施の形態に基づいて述べられているが、本発明は明らかにそのような実施の形態に限定されるものではない。下記のケースもまた本発明に含まれる。
【００７１】
(1)上述の実施の形態では、検証は証明書(RIM証明書)内でハッシュ値を使用することにより実行された。しかしながら、ハッシュ値を使用しない他の検証方法が本発明に適用されても良い。
【００７２】
従来のチェックサムや、コンポーネントから抽出される別のデータ(例えば、コンポーネントから抽出される第一所定ビット)が、検証を実行するために使用されても良い。また、証明書は、完全性チェック値を含むデータグループに置き換えられても良い。
【００７３】
さらに、検証方法は、コンポーネントから抽出される値と期待される値が等しいか否かをチェックすることに限定されない。例えば、コンポーネントのサイズを確認し、もしサイズが所定量より大きいか、または小さいなら、コンポーネントは検証されたと判断されるとしてもよい。これらの検証方法は、ハッシュ値と、その期待値とを比較するほど厳密なものではないが、高速に実行される。
【００７４】
(2)上述の実施形態において、サーバは、全てのコンポーネントに対して更新された証明書およびソフトウェアを送信する。しかしながら、サーバは1つ以上の無効化された証明書に対応する1つ以上の更新された証明書を除外してもよい。この構造により、サーバは、証明書を一組のみ送信することで、証明書の更新および無効化を行うことができる。
【００７５】
さらに、証明書のうち少なくとも1つが更新されない場合は、サーバは、1つ以上の更新されていない証明書に対応する1つ以上の更新された証明書を除外してもよい。この場合、どの証明書が無効化されたかを示す情報を送信することが望ましい。これは、更新されていない証明書が図15の手順において無効化された証明書と間違われる可能性があるためである。
【００７６】
(3)上記の各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。前記ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記憶されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
【００７７】
(4)上記の各装置を構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記憶されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。
【００７８】
さらに、各装置を構成する構成部品の各ユニットは、個別のチップとして、又は、一部若しくは全てを含む単一のチップとして作られても良い。
【００７９】
さらに、ここでは、LSIが述べられているが、集積化の程度の違いにより、指定IC、LSI、スーパーLSI、ウルトラLSIが使用される場合もある。
【００８０】
さらに、回路の集積化の手段は、LSIに限定されるものではなく、専用回路、若しくは汎用プロセッサによる実装も利用できる。さらに、LSIが製造された後にプログラム可能なフィールドプログラムゲートアレイ(FPGA)を使用することもまた可能であり、またLSI内で回路セルの接続及び設定を再構成可能なリコンフィギュアラブルプロセッサも使用可能である。
【００８１】
さらに、もしLSIに置き換わる集積回路技術が半導体技術若しくは他の派生する技術の進歩を通じて現われるのであれば、その技術は当然に構成要素の集積化を実現するために使用することができる。バイオ技術の適用が予想される。
【００８２】
(5)上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。前記ＩＣカードまたは前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。前記ＩＣカードまたは前記モジュールは、上記の超多機能ＬＳＩに含まれるとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、前記ＩＣカードまたは前記モジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
【００８３】
(6)本発明は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、前記コンピュータプログラムからなるデジタル信号であるとしてもよい。
【００８４】
また、本発明は、前記コンピュータプログラムまたは前記デジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Blu-ray Disc）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されている前記デジタル信号であるとしてもよい。
【００８５】
また、本発明は、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
【００８６】
また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記憶しており、前記マイクロプロセッサは、前記コンピュータプログラムにしたがって動作するとしてもよい。
【００８７】
また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を、前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
【００８８】
(7)本技術分野の当業者にとっては、説明した実施の形態の、本発明固有の教示及び利点から原理的に離れることのない多くの変形がありえることを容易に理解することができるだろう。また、上記変更及び実施の形態の任意の組み合わせは、本発明の範囲内に含まれる。
【図面の簡単な説明】
【００８９】
後述の好適な実施形態の詳細な説明を以下の図面と共に考察することで、本発明のよりよい理解が得られる。
【図１】図1は、オプショナルコンポーネント制御構造体に係る携帯装置のライフタイムおよび外部との相互関係を示す。
【図２】図2は、オプショナルコンポーネント制御テーブルおよび関連データを維持するためのキーコンポーネントを表すブロック図である。
【図３】図3は、オプショナルなコンポーネントをサポートするために必要とされるテーブルを表す追加のデータを含むRIM証明書を示す。
【図４】図4は、RIM証明書に付加されたラベル-証明書対応テーブルを示す。
【図５】図5は、カウンタ値、証明書識別子およびその状態を示すテーブル、およびオプショナルなコンポーネントの状態を表す暗号署名を含むオプショナルコンポーネント制御構造体を示す。
【図６】図6は、本発明のオプショナルコンポーネント制御構造体の、初期化プロセスを示すフローチャートである。
【図７】図7は、本発明のオプショナルコンポーネント制御構造体を用いた、外部RIM証明書の更新プロセスを示すフローチャートである。
【図８】図8は、本発明のオプショナルコンポーネント制御構造体を用いた、内部RIM証明書の無効化プロセスを示すフローチャートである。
【図９】図9は、本発明のオプショナルコンポーネント制御構造体を更新するための、サーバとの交信プロセスを示すシーケンス線図である。
【図１０】図10は、本発明のオプショナルコンポーネント制御構造体の検証を含むセキュアブートの強化を示すシーケンス線図である。
【図１１】図11は、カウンタ値、証明書識別子およびその状態を示すテーブル、およびオプショナルなコンポーネントの状態を表す暗号署名を含むオプショナルコンポーネント制御構造体を示す。
【図１２】図12は、オプショナルコンポーネント制御構造体RIM証明書を示す。
【図１３】図13は、本発明のオプショナルコンポーネント制御構造体の、初期化プロセスを示すフローチャートである。
【図１４】図14は、本発明のオプショナルコンポーネント制御構造体を用いた、外部RIM証明書の更新プロセスを示すフローチャートである。
【図１５】図15は、本発明のオプショナルコンポーネント制御構造体を用いた、内部RIM証明書の無効化プロセスを示すフローチャートである。
【図１６】図16は、本発明のオプショナルコンポーネント制御構造体を更新するための、サーバとの交信プロセスを示すシーケンス線図である。
【図１７】図17は、本発明のオプショナルコンポーネント制御構造体の検証を含むセキュアブートの強化を示すシーケンス線図である。
【図１８】図18は、サーバから携帯装置へ送られるオプショナルコンポーネント更新構造体を示す。
【図１９】図19は、顧客装置によるオプショナルコンポーネント制御オプションの維持をサポートするための、サーバ内のキーコンポーネントを表すブロック図である。
【特許請求の範囲】
【請求項１】
サーバに接続可能な装置であって、
各々が1つの証明書に割り当てられる複数のソフトウェアと、前記複数のソフトウェアに関連付けられ、かつ各々が前記複数のソフトウェア各々の検証に用いられる複数の証明書とを格納する格納手段と、
前記複数のソフトウェアの1つを、前記装置で実行可能な前記複数のソフトウェアのうちの有効な1つのソフトウェアとして、前記装置に設定する設定手段と、
前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書を用いて、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証し、前記検証の後に、前記複数のソフトウェアのうちの前記有効かつ検証されたソフトウェアを実行する実行手段と、
前記複数の証明書のうち、何れが前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに対応するかを検出することなく、更新すべきと前記サーバによって判定された所定の証明書に対応する複数の更新された証明書を前記サーバから受信する受信手段と、
前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書に対応する1つの更新された証明書を、前記受信した複数の更新された証明書から選択する選択手段とを備え、
前記実行手段は、前記1つの更新され選択された証明書を用いて前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証する装置。
【請求項２】
前記サーバは、前記複数の更新された証明書を前記装置およびもう1つの別の装置に共通して送信する、請求項1に記載の装置。
【請求項３】
前記複数の更新された証明書は、前記複数のソフトウェアのうちの前記1つの有効なソフトウェアとは異なる、前記複数のソフトウェアのうちの1つのソフトウェアに関連する証明書に対応する更新された証明書を含む、請求項1に記載の装置。
【請求項４】
前記装置はさらに、前記1つの更新された証明書に基づき、前記複数のソフトウェアのうちの前記1つの有効なソフトウェアに関連する証明書を更新する更新手段を備え、
前記実行手段は、前記更新手段が更新した証明書を用いて前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証する、請求項1に記載の装置。
【請求項５】
前記更新手段は、選択されなかった更新された証明書に対応する証明書を更新することなく、前記選択されなかった更新された証明書を、前記受信した複数の更新された証明書から削除する、請求項4に記載の装置。
【請求項６】
前記装置はさらに、前記装置の固有鍵である装置鍵を格納する装置鍵格納手段を備え、
前記更新手段は、前記装置鍵を用いて前記1つの更新された証明書を変換し、前記変換された1つの更新された証明書で前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書を上書きすることにより、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書を更新する、請求項4に記載の装置。
【請求項７】
前記装置はさらに、1つの証明書に対応する更新された証明書が、前記受信した複数の更新された証明書に含まれていないとき、前記1つの証明書が無効であると判定する無効化判定手段と、
前記格納手段に格納されている前記1つの証明書を無効化する無効化手段とを備える、請求項1に記載の装置。
【請求項８】
前記装置はさらに、前記設定手段が前記装置に、前記複数のソフトウェアのうちの1つを前記複数のソフトウェアのうちの前記有効な1つのソフトウェアとして設定したとき、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを示す許可フラグを格納するフラグ格納手段を備え、
前記選択手段は、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書に対応する1つの更新された証明書を、前記フラグ格納手段に格納されている前記許可フラグに基づいて、前記受信した複数の更新された証明書から選択する、請求項7に記載の装置。
【請求項９】
前記装置はさらに、前記無効化手段が前記格納手段に格納されている前記1つの証明書を無効化するときに、カウンタ値をインクリメントするカウンタと、
カウンタ値がインクリメントされたとき、前記許可フラグを含む管理情報に前記インクリメントされたカウンタ値を設定するカウンタ値設定手段と、
前記管理情報に設定された前記カウンタ値を用いて、前記管理情報が改竄されているか否かを判定する判定手段とを備える、請求項8に記載の装置。
【請求項１０】
前記装置はさらに、前記許可フラグと前記カウンタ値とを含む前記管理情報の暗号技術的ハッシュ値を算出する算出手段と、
前記算出された暗号技術的ハッシュ値に対応する検証値を格納する値格納手段と、
前記選択手段が前記1つの更新された証明書を選択するために前記管理情報を用いる前に、前記格納された検証値と前記算出された暗号技術的ハッシュ値とを比較することにより、前記管理情報が改竄されているか否かを検証する検証手段を備える、請求項9に記載の装置。
【請求項１１】
前記装置はさらに、前記複数のソフトウェアと前記複数の証明書の間のマッピングを示すマッピングデータを格納するマッピングデータ格納手段と、
前記マッピングデータの暗号技術的ハッシュ値を算出する算出手段と、
前記算出された暗号技術的ハッシュ値に対応する検証値を格納する値格納手段と、
前記選択手段が前記1つの更新された証明書を選択する前に、前記格納された検証値と前記算出された暗号技術的ハッシュ値とを比較することにより、前記マッピングデータが改竄されているか否かを検証する検証手段を備え、
前記選択手段は、前記マッピングデータに基づき前記1つの更新された証明書を選択する、請求項7に記載の装置。
【請求項１２】
前記装置はさらに、前記無効化手段が前記格納手段に格納されている前記1つの証明書を無効化するときに、カウンタ値をインクリメントするカウンタと、
カウンタ値がインクリメントされたとき、前記マッピングデータに前記インクリメントされたカウンタ値を割り当てるカウンタ値割り当て手段とを備え、
前記算出手段は、前記マッピングデータと前記マッピングデータに割り当てられた前記カウンタ値とを用いて前記暗号技術的ハッシュ値を算出する、請求項11に記載の装置。
【請求項１３】
サーバに接続可能な装置のための方法であって、
各々が1つの証明書に割り当てられる複数のソフトウェアと、前記複数のソフトウェアに関連付けられ、かつ各々が前記複数のソフトウェア各々の検証に用いられる複数の証明書とを格納する格納ステップと、
前記複数のソフトウェアの1つを、前記装置で実行可能な前記複数のソフトウェアのうちの有効な1つのソフトウェアとして、前記装置に設定する設定ステップと、
前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書を用いて、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証し、前記検証の後に、前記複数のソフトウェアのうちの前記有効かつ検証されたソフトウェアを実行する実行ステップと、
前記複数の証明書のうち、何れが前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに対応するかを検出することなく、更新すべきと前記サーバによって判定された所定の証明書に対応する複数の更新された証明書を前記サーバから受信する受信ステップと、
前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書に対応する1つの更新された証明書を、前記受信した複数の更新された証明書から選択する選択ステップとを含み、
前記実行ステップは、前記1つの最新かつ選択された証明書を用いて前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証する、方法。
【請求項１４】
サーバに接続可能な装置のためのプログラムを記録した記録媒体であって、前記プログラムは、
各々が1つの証明書に割り当てられる複数のソフトウェアと、前記複数のソフトウェアに関連付けられ、かつ各々が前記複数のソフトウェア各々の検証に用いられる複数の証明書とを格納する格納ステップと、
前記装置に対し、前記複数のソフトウェアの1つを、前記装置で実行可能な前記複数のソフトウェアのうち有効な1つのソフトウェアとして設定する設定ステップと、
前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書を用いて、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証し、前記検証の後に、前記複数のソフトウェアのうちの前記有効かつ検証されたソフトウェアを実行する実行ステップと、
前記複数の証明書のうち、何れが前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに対応するかを検出することなく、更新すべきと前記サーバによって判定された所定の証明書に対応する複数の更新された証明書を前記サーバから受信する受信ステップと、
前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書に対応する1つの更新された証明書を、前記受信した複数の更新された証明書から選択する選択ステップとを含み、
前記実行ステップは、前記1つの更新され選択された証明書を用いて前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証する、プログラムを記録した記録媒体。
【請求項１５】
サーバに接続可能な装置に用いられる集積回路であって、
各々が1つの証明書に割り当てられる複数のソフトウェアと、前記複数のソフトウェアに関連付けられ、かつ各々が前記複数のソフトウェア各々の検証に用いられる複数の証明書とを格納する格納手段と、
前記複数のソフトウェアの1つを、前記装置で実行可能な前記複数のソフトウェアのうちの有効な1つのソフトウェアとして、前記装置に設定する設定手段と、
前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書を用いて、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証し、前記検証の後に、前記複数のソフトウェアのうちの前記有効かつ検証されたソフトウェアを実行する実行手段と、
前記複数の証明書のうち、何れが前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに対応するかを検出することなく、更新すべきと前記サーバによって判定された所定の証明書に対応する複数の更新された証明書を前記サーバから受信する受信手段と、
前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書に対応する1つの更新された証明書を、前記受信した複数の更新された証明書から選択する選択手段とを含み、
前記実行手段は、前記1つの更新され選択された証明書を用いて前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証する、集積回路。
【請求項１】
サーバに接続可能な装置であって、
各々が1つの証明書に割り当てられる複数のソフトウェアと、前記複数のソフトウェアに関連付けられ、かつ各々が前記複数のソフトウェア各々の検証に用いられる複数の証明書とを格納する格納手段と、
前記複数のソフトウェアの1つを、前記装置で実行可能な前記複数のソフトウェアのうちの有効な1つのソフトウェアとして、前記装置に設定する設定手段と、
前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書を用いて、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証し、前記検証の後に、前記複数のソフトウェアのうちの前記有効かつ検証されたソフトウェアを実行する実行手段と、
前記複数の証明書のうち、何れが前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに対応するかを検出することなく、更新すべきと前記サーバによって判定された所定の証明書に対応する複数の更新された証明書を前記サーバから受信する受信手段と、
前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書に対応する1つの更新された証明書を、前記受信した複数の更新された証明書から選択する選択手段とを備え、
前記実行手段は、前記1つの更新され選択された証明書を用いて前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証する装置。
【請求項２】
前記サーバは、前記複数の更新された証明書を前記装置およびもう1つの別の装置に共通して送信する、請求項1に記載の装置。
【請求項３】
前記複数の更新された証明書は、前記複数のソフトウェアのうちの前記1つの有効なソフトウェアとは異なる、前記複数のソフトウェアのうちの1つのソフトウェアに関連する証明書に対応する更新された証明書を含む、請求項1に記載の装置。
【請求項４】
前記装置はさらに、前記1つの更新された証明書に基づき、前記複数のソフトウェアのうちの前記1つの有効なソフトウェアに関連する証明書を更新する更新手段を備え、
前記実行手段は、前記更新手段が更新した証明書を用いて前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証する、請求項1に記載の装置。
【請求項５】
前記更新手段は、選択されなかった更新された証明書に対応する証明書を更新することなく、前記選択されなかった更新された証明書を、前記受信した複数の更新された証明書から削除する、請求項4に記載の装置。
【請求項６】
前記装置はさらに、前記装置の固有鍵である装置鍵を格納する装置鍵格納手段を備え、
前記更新手段は、前記装置鍵を用いて前記1つの更新された証明書を変換し、前記変換された1つの更新された証明書で前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書を上書きすることにより、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書を更新する、請求項4に記載の装置。
【請求項７】
前記装置はさらに、1つの証明書に対応する更新された証明書が、前記受信した複数の更新された証明書に含まれていないとき、前記1つの証明書が無効であると判定する無効化判定手段と、
前記格納手段に格納されている前記1つの証明書を無効化する無効化手段とを備える、請求項1に記載の装置。
【請求項８】
前記装置はさらに、前記設定手段が前記装置に、前記複数のソフトウェアのうちの1つを前記複数のソフトウェアのうちの前記有効な1つのソフトウェアとして設定したとき、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを示す許可フラグを格納するフラグ格納手段を備え、
前記選択手段は、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書に対応する1つの更新された証明書を、前記フラグ格納手段に格納されている前記許可フラグに基づいて、前記受信した複数の更新された証明書から選択する、請求項7に記載の装置。
【請求項９】
前記装置はさらに、前記無効化手段が前記格納手段に格納されている前記1つの証明書を無効化するときに、カウンタ値をインクリメントするカウンタと、
カウンタ値がインクリメントされたとき、前記許可フラグを含む管理情報に前記インクリメントされたカウンタ値を設定するカウンタ値設定手段と、
前記管理情報に設定された前記カウンタ値を用いて、前記管理情報が改竄されているか否かを判定する判定手段とを備える、請求項8に記載の装置。
【請求項１０】
前記装置はさらに、前記許可フラグと前記カウンタ値とを含む前記管理情報の暗号技術的ハッシュ値を算出する算出手段と、
前記算出された暗号技術的ハッシュ値に対応する検証値を格納する値格納手段と、
前記選択手段が前記1つの更新された証明書を選択するために前記管理情報を用いる前に、前記格納された検証値と前記算出された暗号技術的ハッシュ値とを比較することにより、前記管理情報が改竄されているか否かを検証する検証手段を備える、請求項9に記載の装置。
【請求項１１】
前記装置はさらに、前記複数のソフトウェアと前記複数の証明書の間のマッピングを示すマッピングデータを格納するマッピングデータ格納手段と、
前記マッピングデータの暗号技術的ハッシュ値を算出する算出手段と、
前記算出された暗号技術的ハッシュ値に対応する検証値を格納する値格納手段と、
前記選択手段が前記1つの更新された証明書を選択する前に、前記格納された検証値と前記算出された暗号技術的ハッシュ値とを比較することにより、前記マッピングデータが改竄されているか否かを検証する検証手段を備え、
前記選択手段は、前記マッピングデータに基づき前記1つの更新された証明書を選択する、請求項7に記載の装置。
【請求項１２】
前記装置はさらに、前記無効化手段が前記格納手段に格納されている前記1つの証明書を無効化するときに、カウンタ値をインクリメントするカウンタと、
カウンタ値がインクリメントされたとき、前記マッピングデータに前記インクリメントされたカウンタ値を割り当てるカウンタ値割り当て手段とを備え、
前記算出手段は、前記マッピングデータと前記マッピングデータに割り当てられた前記カウンタ値とを用いて前記暗号技術的ハッシュ値を算出する、請求項11に記載の装置。
【請求項１３】
サーバに接続可能な装置のための方法であって、
各々が1つの証明書に割り当てられる複数のソフトウェアと、前記複数のソフトウェアに関連付けられ、かつ各々が前記複数のソフトウェア各々の検証に用いられる複数の証明書とを格納する格納ステップと、
前記複数のソフトウェアの1つを、前記装置で実行可能な前記複数のソフトウェアのうちの有効な1つのソフトウェアとして、前記装置に設定する設定ステップと、
前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書を用いて、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証し、前記検証の後に、前記複数のソフトウェアのうちの前記有効かつ検証されたソフトウェアを実行する実行ステップと、
前記複数の証明書のうち、何れが前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに対応するかを検出することなく、更新すべきと前記サーバによって判定された所定の証明書に対応する複数の更新された証明書を前記サーバから受信する受信ステップと、
前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書に対応する1つの更新された証明書を、前記受信した複数の更新された証明書から選択する選択ステップとを含み、
前記実行ステップは、前記1つの最新かつ選択された証明書を用いて前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証する、方法。
【請求項１４】
サーバに接続可能な装置のためのプログラムを記録した記録媒体であって、前記プログラムは、
各々が1つの証明書に割り当てられる複数のソフトウェアと、前記複数のソフトウェアに関連付けられ、かつ各々が前記複数のソフトウェア各々の検証に用いられる複数の証明書とを格納する格納ステップと、
前記装置に対し、前記複数のソフトウェアの1つを、前記装置で実行可能な前記複数のソフトウェアのうち有効な1つのソフトウェアとして設定する設定ステップと、
前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書を用いて、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証し、前記検証の後に、前記複数のソフトウェアのうちの前記有効かつ検証されたソフトウェアを実行する実行ステップと、
前記複数の証明書のうち、何れが前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに対応するかを検出することなく、更新すべきと前記サーバによって判定された所定の証明書に対応する複数の更新された証明書を前記サーバから受信する受信ステップと、
前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書に対応する1つの更新された証明書を、前記受信した複数の更新された証明書から選択する選択ステップとを含み、
前記実行ステップは、前記1つの更新され選択された証明書を用いて前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証する、プログラムを記録した記録媒体。
【請求項１５】
サーバに接続可能な装置に用いられる集積回路であって、
各々が1つの証明書に割り当てられる複数のソフトウェアと、前記複数のソフトウェアに関連付けられ、かつ各々が前記複数のソフトウェア各々の検証に用いられる複数の証明書とを格納する格納手段と、
前記複数のソフトウェアの1つを、前記装置で実行可能な前記複数のソフトウェアのうちの有効な1つのソフトウェアとして、前記装置に設定する設定手段と、
前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書を用いて、前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証し、前記検証の後に、前記複数のソフトウェアのうちの前記有効かつ検証されたソフトウェアを実行する実行手段と、
前記複数の証明書のうち、何れが前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに対応するかを検出することなく、更新すべきと前記サーバによって判定された所定の証明書に対応する複数の更新された証明書を前記サーバから受信する受信手段と、
前記複数のソフトウェアのうちの前記有効な1つのソフトウェアに関連する証明書に対応する1つの更新された証明書を、前記受信した複数の更新された証明書から選択する選択手段とを含み、
前記実行手段は、前記1つの更新され選択された証明書を用いて前記複数のソフトウェアのうちの前記有効な1つのソフトウェアを検証する、集積回路。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【公開番号】特開２０１０−３２３５（Ｐ２０１０−３２３５Ａ）
【公開日】平成２２年１月７日（２０１０．１．７）
【国際特許分類】
【外国語出願】
【出願番号】特願２００８−１６３４７１（Ｐ２００８−１６３４７１）
【出願日】平成２０年６月２３日（２００８．６．２３）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成２２年１月７日（２０１０．１．７）
【国際特許分類】
【出願番号】特願２００８−１６３４７１（Ｐ２００８−１６３４７１）
【出願日】平成２０年６月２３日（２００８．６．２３）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]