情報処理装置および携帯電話装置
【課題】複数の演算処理部を備える場合であっても、十分な利便性および安全性を考慮したドメイン分割を実行可能な情報処理装置および携帯電話装置を提供する。
【解決手段】保護リソースを有しないノーマルモードおよび保護リソースを有するセキュアモードを含む複数の動作モードを有する携帯電話端末１０であって、複数の演算処理部と、所定のセキュリティポリシに基づいてアクセス制御されるプログラムまたはデータを含む実行領域を示すドメインを生成するＤＣ２３と、を有し、ＤＣ２３は、複数の演算処理部および複数の動作モードに基づいてドメインを生成する。
【解決手段】保護リソースを有しないノーマルモードおよび保護リソースを有するセキュアモードを含む複数の動作モードを有する携帯電話端末１０であって、複数の演算処理部と、所定のセキュリティポリシに基づいてアクセス制御されるプログラムまたはデータを含む実行領域を示すドメインを生成するＤＣ２３と、を有し、ＤＣ２３は、複数の演算処理部および複数の動作モードに基づいてドメインを生成する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置および携帯電話装置に関し、特に、複数のＣＰＵを備える場合であっても、十分な利便性および安全性を考慮したドメイン分割を実行可能な情報処理装置および携帯電話装置に関する。
【背景技術】
【０００２】
近年、マルウェアによるＰＣ等の情報処理端末の被害が拡大している。このような情報処理端末の被害を最小限に抑えるために、仮想化技術、セキュリティに関する動作モードの設定、ソフトウェアの完全性計測または完全性検証の実施、ドメイン分割などが知られている。
【０００３】
仮想化技術は、同一のＣＰＵ内に複数の仮想環境を設け、仮想環境毎に異なるＯＳを実行する技術であり、リソースの効率利用や管理の容易性から注目されている。セキュリティ面では、仮想環境間はＶＭＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｍｏｎｉｔｏｒ）によりリソースが排他制御され、ある仮想環境から他仮想環境に対するアクセスを制御できる。そのため、ある環境におけるマルウェア等による被害が他の環境へ波及しにくい。
【０００４】
また、情報処理端末の動作モードとして、ノーマルモードおよびセキュアモードがある。セキュアモードは、保護アプリケーションのみ実行可能であり、専用保護リソースを有する。このような動作モードを有する情報処理端末では、ノーマルモードからセキュアモードへ移行させ、アクセス制限を行うことが可能である。
【０００５】
また、ソフトウェアの完全性計測を実施するために、情報処理端末の一例である従来のＰＣではＴｒｕｓｔｅｄ Ｂｏｏｔと呼ばれる処理を、ソフトウェアの完全性検証を実施するために、情報処理端末の一例である従来の携帯電話ではＳｅｃｕｒｅ Ｂｏｏｔと呼ばれる処理を行う。
【０００６】
ソフトウェアの完全性計測を実施する従来のＰＣは、内部ＲＯＭ（Ｃｏｒｅ Ｒｏｏｔ ｏｆ Ｔｒｕｓｔ Ｍｅａｓｕｒｅｍｅｎｔ：ＣＲＴＭ）、ＢＩＯＳ、Ｋｅｒｎｅｌの順に起動する。この際、内部ＲＯＭから次に起動するＢＩＯＳのＳＨＡ−１ハッシュ値を計算し、ＴＰＭ（Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ）内部のＰＣＲ（Ｐｌａｔｆｏｒｍ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｒｅｇｉｓｔｅｒ）にハッシュ値を設定し、ＢＩＯＳを起動する。ＢＩＯＳはＫｅｒｎｅｌのハッシュ値を計算し、ＰＣＲにハッシュ値を設定し、Ｋｅｒｎｅｌを起動する。ここで、このハッシュ値は、ＢＩＯＳのハッシュ値にＫｅｒｎｅｌのハッシュ値が依存した形で設定される。Ｋｅｒｎｅｌが起動されると、Ｔｒｕｓｔｅｄ Ｃｏｍｐｏｎｅｎｔ Ｂａｓｅ（ＴＣＢ）が確立する。この一連の流れをＴｒｕｓｔｅｄ Ｂｏｏｔと呼ぶ。
【０００７】
Ｔｒｕｓｔｅｄ Ｂｏｏｔの実施後、ＰＣがネットワークに接続された場合等に、外部サーバがＰＣにＰＣＲ値を要求し、ＰＣはＴＰＭからＴＰＭ固有鍵で署名されたＰＣＲ値を取得して外部サーバに返信する。外部サーバはＰＣＲ値が想定の値と等しい場合に、ネットワーク接続を許可する等の制御を行う。ここで、ＰＣＲは耐タンパ性の高いモジュールであり、高い安全性が確保されるため、結果として端末の完全性を保証できる。
【０００８】
また、ソフトウェアの完全性検証を実施する従来の携帯電話は、Ｔｒｕｓｔｅｄ Ｂｏｏｔと同様の処理によりハッシュ値を計測し、事前に用意したハッシュ期待値と計測したハッシュ値を比較し、一致時のみ対象ソフトウェアを起動する。この流れをＳｅｃｕｒｅ Ｂｏｏｔと呼ぶ。なお、ハッシュ期待値や計測したハッシュ値は、ＭＴＭ（Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ）に格納される。
【０００９】
このように、Ｔｒｕｓｔｅｄ Ｂｏｏｔでは、ハッシュ値をＰＣＲに保存し、外部サーバにより完全性検証を行うが、Ｓｅｃｕｒｅ Ｂｏｏｔでは、端末自身でハッシュ値算出および完全性検証まで実施する。また、ＭＴＭは、携帯電話はユーザの所有物であり、通信オペレータのプラットフォームでもあるため、前者向けのＭＴＭをＭｏｂｉｌｅ Ｌｏｃａｌ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ（ＭＬＴＭ）、後者向けのＭＴＭをＭｏｂｉｌｅ Ｒｅｍｏｔｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ（ＭＲＴＭ）としている。
【００１０】
また、セキュリティポリシに従いアクセス制御される実行領域をドメインと呼ぶ。このドメインは、複数の仮想環境が１つのドメインに属することや、仮想化を用いないドメインを許容する。情報処理端末のＣＰＵにこのようなドメインを複数設定することが可能になっている。なお、ドメインを設定することをドメイン分割とも呼ぶ。
【００１１】
このような情報処理端末内のＣＰＵにドメイン分割を行う技術の一例として、上記動作モードを想定したドメイン分割（例えば、非特許文献１参照）や仮想環境を想定したドメイン分割（例えば、非特許文献２参照）が知られている。
【００１２】
なお、情報処理端末の被害を最小限に抑えるための技術の一例として、秘密キーを用いて生成される生成値と保存されている保存値とを比較し、一致すればプログラムを実行する技術が知られている（例えば、特許文献１参照）。また、ハードウェア固有鍵で暗号化されたプログラムを改ざん検証し、改ざんがなければ、プログラムを復号化して起動することが知られている（例えば、特許文献２参照）。
【００１３】
【非特許文献１】「Ｏｐｅｎ ａｎｄ Ｓｅｃｕｒｅ Ｔｅｒｍｉｎａｌ Ｉｎｉｔｉａｔｉｖｅ ２００６」 ＮＴＴドコモ
【非特許文献２】「ＩＢＭ Ｖｉｒｔｕａｌｉｚｉｎｇ ｔｈｅ Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ ２００６」 ＩＢＭ
【特許文献１】特許第２５６４５９３号公報
【特許文献２】特開２００３−１０８２５７号公報
【発明の開示】
【発明が解決しようとする課題】
【００１４】
しかしながら、上記特許文献では、情報処理端末が複数のＣＰＵ等の演算処理部を備える場合、複数のＣＰＵ等の演算処理部間にまたがってドメイン分割を行うことが想定されていないため、十分な利便性および安全性を考慮したドメイン分割を行うことができない。
【００１５】
本発明は、上記事情を鑑みてなされたものであって、複数の演算処理部を備える場合であっても、十分な利便性および安全性を考慮したドメイン分割を実行可能な情報処理装置および携帯電話装置を提供することを目的とする。
【課題を解決するための手段】
【００１６】
上記目的を達成するために、本発明の情報処理装置は、保護リソースを有しないノーマルモードおよび保護リソースを有するセキュアモードを含む複数の動作モードを有する情報処理装置であって、複数の演算処理部と、所定のセキュリティポリシに基づいてアクセス制御されるプログラムまたはデータを含む実行領域を示すドメインを生成するドメイン制御部と、を有し、前記ドメイン制御部は、前記複数の演算処理部および前記複数の動作モードに基づいて前記ドメインを生成する。
【００１７】
上記構成によれば、複数の演算処理部を備える場合であっても、十分な利便性および安全性を考慮したドメイン分割を実行可能である。
【００１８】
また、本発明の情報処理装置は、前記ドメイン制御部が、更に、前記動作モードの前記保護リソースに基づいてドメインを生成する。
【００１９】
上記構成によれば、複数の演算処理部を備える場合であっても、十分な利便性および安全性を考慮したドメイン分割を実行可能である。
【００２０】
また、本発明の情報処理装置は、前記ドメイン制御部が、更に、実行領域を含む仮想環境に基づいて、ドメインを生成する。
【００２１】
上記構成によれば、複数の演算処理部を備える場合であっても、十分な利便性および安全性を考慮したドメイン分割を実行可能である。
【００２２】
また、本発明の情報処理装置は、前記ドメイン制御部が、同一のセキュリティポリシに基づいてアクセス制御される実行領域を同一のドメインとする
【００２３】
上記構成によれば、信頼できるプラットフォームを構築することができる。
【００２４】
また、本発明の情報処理装置は、前記演算処理部が、複数の実行領域を示すエリアを有し、前記ドメイン制御部が、送信元エリアから送信先エリアへ通信を行う際、前記送信元エリアと前記送信先エリアとが同一のドメインである場合に、通信を許可する。
【００２５】
上記構成によれば、同一ドメイン間でのみ通信を許可するため、信頼できるプラットフォームを構築することができる。
【００２６】
また、本発明の情報処理装置は、前記演算処理部が、複数の実行領域を示すエリアを有し、前記ドメイン制御部が、送信元エリアから送信先エリアへ通信を行う際、前記送信元エリアと前記送信先エリアとが異なるドメインである場合、かつ、前記セキュリティポリシに前記送信元エリアと送信先エリアとの間の通信を許可するための情報が含まれる場合に、通信を許可する。
【００２７】
上記構成によれば、送信元エリアと送信先エリアとが異なるドメインである場合であっても、所定の場合にのみ通信を許可するので、柔軟性のある信頼できるプラットフォームを構築することができる。
【００２８】
また、本発明の情報処理装置は、前記演算処理部が、複数の実行領域を示すエリアを有し、前記ドメイン制御部が、所定の検証処理に失敗したエリアとの間の通信を禁止する。
【００２９】
上記構成によれば、同一ドメインであっても検証処理に失敗している場合には通信を禁止するため、信頼できるプラットフォームを構築することができる。
【００３０】
また、本発明の情報処理装置は、前記演算処理部が、個別に起動可能なプログラムまたはデータを含む実行領域を階層的に有し、所定階層の実行領域が、当該所定階層の実行領域の固有鍵を用いて当該所定階層よりも一段階上位層の実行領域を復号化し、前記一段階上位層の実行領域について所定の検証処理を実行し、前記検証処理に成功した場合、前記一段階上位層の実行領域が有するプログラムを起動する起動時処理を実行する。
【００３１】
上記構成によれば、前階層の固有鍵を用いて復号化等を行うため、信頼できるプラットフォームを構築することができる。
【００３２】
また、本発明の情報処理装置は、前記起動時処理が、最下位層を前記所定階層として最上位層よりも一段階下位層を前記所定階層とするまで一段階ずつ順に実行される。
【００３３】
上記構成によれば、階層毎に段階的に復号化し、さらに前階層の固有鍵を用いてＣｈａｉｎ−ｂｉｎｄｉｎｇをＵｎｂｉｎｄｉｎｇすることで起動時処理を行うため、信頼できるプラットフォームを構築することができる。
【００３４】
また、本発明の情報処理装置は、最上位層の実行領域が、当該最上位層の実行領域の起動後に、当該最上位層の実行領域の固有鍵を用いて所定のデータを復号化し、前記所定のデータについて所定の検証処理を実行し、前記検証処理に成功した場合、前記所定のデータを操作可能とする。
【００３５】
上記構成によれば、例えば所定のデータを含めてＣｈａｉｎ−ｂｉｎｄｉｎｇをＵｎｂｉｎｄｉｎｇすることで起動時処理を行うため、さらに信頼できるプラットフォームを構築することができる。また、復号化ができない限りコピーされたデータがコピー先端末で利用できず、コピー先端末ではデータが復号困難となる。なお、所定のデータとしては、ＩＭＥＩやＳＩＭＬｏｃｋ設定のような事前に決めることができて、かつ全ての端末で同じではないデータが考えられる。
【００３６】
また、本発明の情報処理装置は、前記所定のデータが、当該情報処理装置を識別するための識別データを含むデータである。
【００３７】
上記構成によれば、ＩＭＥＩ等のデータを含めてＣｈａｉｎ−ｂｉｎｄｉｎｇをＵｎｂｉｎｄｉｎｇすることで起動時処理を行うため、さらに信頼できるプラットフォームを構築することができる。また、復号化ができない限りコピーされたＩＭＥＩがコピー先端末で利用できず、コピー先端末ではＩＭＥＩ及び関連ソフトウェアの全てが復号困難となる。
【００３８】
また、本発明の情報処理装置は、所定階層の実行領域が、前記検証処理に失敗した場合、当該所定階層の重要度に基づく復旧処理を実行する。
【００３９】
上記構成によれば、検証失敗時に復旧処理を実行可能であるため、検証失敗時であっても起動時処理を柔軟に継続または停止することが可能である。
【００４０】
また、本発明の情報処理装置は、所定階層の実行領域が、前記復旧処理に失敗した場合、当該所定階層の重要度よりも高い重要度に基づく復旧処理を実行する。
【００４１】
上記構成によれば、復旧失敗時にさらに復旧処理を実行可能であるため、検証や復旧に失敗時であっても起動時処理を柔軟に継続または停止することが可能である。
【００４２】
また、本発明の情報処理装置は、前記復旧処理が、当該情報処理装置の起動停止処理である。
【００４３】
上記構成によれば、情報処理装置を起動停止することで、最も安全に起動時処理を停止ことが可能である。特に携帯電話端末の主要な処理の実行に不可欠なコンポーネントにおいて検証失敗した場合に起動停止すると、高い安全性を確保できる。
【００４４】
また、本発明の情報処理装置は、前記復旧処理が、前記所定階層の実行領域を外部サーバから取得した他の実行領域に差し替える処理である。
【００４５】
上記構成によれば、上記実行領域の差し替えにより、起動時処理を柔軟に継続可能である。
【００４６】
また、本発明の情報処理装置は、前記復旧処理が、非常通報機能のみ利用可能とする処理である。
【００４７】
上記構成によれば、非常通報のみ利用可能とするので、危急の場合に最低限の動作を保証することができるとともに、高い安全性を確保することができる。
【００４８】
また、本発明の情報処理装置は、前記復旧処理が、前記検証処理に失敗した旨を報知部に報知させる処理である。
【００４９】
上記構成によれば、失敗した旨を情報処理装置のユーザやサービス提供者が認識可能であるため、情報処理装置のユーザやサービス提供者が以降の処理を迅速に判断することができる。
【００５０】
また、本発明の情報処理装置は、前記演算処理部が、個別に起動可能なプログラムまたはデータを含む実行領域を階層的に有し、所定階層の実行領域が、当該所定階層の実行領域の固有鍵を用いて当該所定階層よりも一段階下位層の実行領域を暗号化する暗号化処理を実行する。
【００５１】
上記構成によれば、前階層の固有鍵を用いて暗号化を行うため、信頼できるプラットフォームを構築することができる。
【００５２】
また、本発明の情報処理装置は、前記暗号化処理が、最上位層よりも一段階下位層を前記所定階層としてから最下位層を前記所定階層とするまで一段階ずつ順に実行される。
【００５３】
上記構成によれば、階層毎に段階的に暗号化し、さらに前階層の固有鍵を用いてＣｈａｉｎ−ｂｉｎｄｉｎｇを行う暗号化処理を行うため、信頼できるプラットフォームを構築することができる。
【００５４】
また、本発明の情報処理装置は、最上位層の実行領域が、当該最上位層の実行領域の暗号化前に、当該最上位層の実行領域の固有鍵を用いて所定のデータを暗号化する。
【００５５】
上記構成によれば、所定のデータを含めてＣｈａｉｎ−ｂｉｎｄｉｎｇを行う起動時処理を行うため、さらに信頼できるプラットフォームを構築することができる。また、復号化ができない限りコピーされたデータがコピー先端末で利用できず、コピー先端末ではデータが復号困難となる。
【００５６】
また、本発明の情報処理装置は、前記演算処理部が、所定のデータを備える第１の演算処理部と、第２の演算処理部とを有し、前記第２の演算処理部が、前記第１の演算処理部へ前記所定のデータの送信要求を実行し、前記第１の演算処理部と当該第２の演算処理部とを接続する通信路を構成するプログラムを含む実行領域に関する検証処理が成功した場合、前記第１の演算処理部から送信された前記所定のデータを記憶する。
【００５７】
上記構成によれば、例えば情報処理装置の利用時又は定期的に、ＩＭＥＩの送受信を行う２つの演算処理部において、ＩＭＥＩの送受信に関連するプログラムの検証処理を行い、検証処理に成功した場合にのみＩＭＥＩをコピーし記憶することが可能となるため、ＩＭＥＩの完全性を確実に確保することが可能である。
【００５８】
また、本発明の情報処理装置は、前記検証処理の結果を示すセキュアフラグを有し、前記演算処理部が、前記セキュアフラグに基づいて、前記検証処理に失敗したか否かを判定する。
【００５９】
また、本発明の情報処理装置は、前記演算処理部が、前記セキュアフラグに基づく検証処理の結果に応じて、異なる制御を行う。
【００６０】
上記構成によれば、セキュアフラグを用いることで、検証処理の結果を容易に判断することができ、検証処理後の挙動についても決定することが可能である。
【００６１】
また、本発明の携帯電話装置は、アンテナと、操作入力を受け付ける入力部と、前記アンテナを介して無線通信を行うための無線部と、上記いずれかの情報処理装置とを有する。
【００６２】
上記構成によれば、複数のＣＰＵを備える場合であっても、十分な利便性および安全性を考慮したドメイン分割の実行等が可能である。
【発明の効果】
【００６３】
以上説明したように、本発明にかかる情報処理装置および携帯電話装置によれば、複数の演算処理部、複数モードにまたがってドメイン分割できる。また、本発明の完全性検証では、ソフトウェアおよびデータの完全性検証まで行うことが可能である。したがって、プログラムのみに依存したセキュアブートではなく、保護したいデータにも依存させるセキュアブートが実行可能である。
【発明を実施するための最良の形態】
【００６４】
本発明の実施形態における情報処理装置および携帯電話装置について、図面を参照しながら以下に説明する。
【００６５】
本実施形態にかかる情報処理装置としては、ＰＣ、携帯情報端末（ＰＤＡ）、携帯電話端末などが考えられるが、ここでは一例として携帯電話端末について考察する。
【００６６】
図１は、本実施形態にかかる携帯電話端末のハードウェア構成の一例を示す図である。
【００６７】
本実施形態の携帯電話端末は、無線部１１と、Ｃ−ＭＰＵ（Ｍｉｃｒｏ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１２と、ＳＤＲＡＭ等の揮発メモリ１３と、ＭＢ（ＭＰＵ Ｂｒｉｄｇｅ）１４と、ＮＯＲ／ＮＡＮＤ等によって構成される不揮発メモリ１５と、Ａ−ＭＰＵ１６と、内部ＲＯＭ（ＣＲＴＭ）１７と、ＭＲＴＭ（Ｍｏｂｉｌｅ Ｒｅｍｏｔｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ）１８とを有して構成される。また、図示はしないが、操作入力を受け付ける入力部を当然備えてもよい。
【００６８】
無線部１１は、図示しないアンテナを介して外部サーバ等の外部通信装置と通信を行う。
【００６９】
Ａ−ＭＰＵ１６は、アプリケーション用のＭＰＵであり、Ｃ−ＭＰＵ１２は、通信用のＭＰＵである。ＭＰＵは演算処理部の一例であるが、演算処理部として他に、ＣＰＵ、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、複数コアのＣＰＵなどが考えられる。
【００７０】
揮発メモリ１３は、いわゆるメインメモリであり、実行プログラムや各種データを記憶する。
【００７１】
ＭＢ１４は、Ａ−ＭＰＵ１６およびＣ−ＭＰＵ１２間のデータ伝送路であり、Ｃ−ＭＰＵ１２とＡ−ＭＰＵ１６との間の通信を制御する。ＭＢ１４は、ハードウェア的要素とソフトウェア的要素とをあわせ持つ。
【００７２】
不揮発メモリ１５は、携帯電話端末１０の生産工程で記載されたＩＭＥＩや、暗号化コンポーネントを記憶する。
【００７３】
内部ＲＯＭ１７は、各種プログラムを記憶する。
【００７４】
ＭＲＴＭ１８は、高い耐タンパ性を有するモジュールであり、ＰＣＲ（Ｐｌａｔｆｏｒｍ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｒｅｇｉｓｔｅｒ）、Ｓｅｃｕｒｅ Ｆｌａｇ、携帯端末を識別するためのＩＭＥＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｅｑｕｉｐｍｅｎｔ Ｉｄｅｎｔｉｔｙ）、ＭＲＴＭ１８の固有鍵であるＫｅｙ、ハッシュ期待値であるＲＩＭ＿Ｃｅｒｔなどの特に重要度の高い領域やデータを記憶する。
【００７５】
なお、ＲＩＭ＿Ｃｅｒｔについては、ディジタル署名などが施されている場合には、不揮発メモリ１５に保存することも可能である。
【００７６】
また、後述する各階層が有する固有鍵は、平文のまま各階層のプログラムに埋め込む場合と、暗号化してプログラムに埋め込む場合があり得る。後者の場合、各階層の固有鍵はＭＲＴＭ１８の固有鍵または関連する鍵で暗号化する。暗号化された各階層の固有鍵はＭＲＴＭの内部で復号化され、ＭＲＴＭのＲＡＭにキャッシュされる。この場合、Ｋｅｙにはキャッシュされた各階層の固有鍵も含む。
【００７７】
ここで、Ｓｅｃｕｒｅ Ｆｌａｇ（セキュアフラグ）とは、ＭＴＭが内部に保持する保護メモリ領域上に形成されたフラグである。後述する各レイヤにおける完全性検証の結果を保持する。また、セキュアフラグに基づいて、演算処理部は所定の検証処理に失敗したか否かを判定する。また、セキュアフラグに基づく検証処理の結果に応じて、演算処理部は異なる制御を行う。また、セキュアフラグは、更新可能である。本実施形態では、Ｓｅｃｕｒｅ Ｆｌａｇを単にＦｌａｇとも称する。
【００７８】
携帯電話端末１０は、後述するＤＣ（Ｄｏｍａｉｎ Ｃｏｏｒｄｉｎａｔｏｒ）により、所定のセキュリティポリシに基づいてアクセス制御されるプログラムまたはデータを含む実行領域を示すドメインを生成するために、Ｃ−ＭＰＵ１２およびＡ−ＭＰＵ１６の領域を分割する。これをドメイン分割と称する。携帯電話端末１０は、Ｃ−ＭＰＵ１２およびＡ−ＭＰＵ１６などの複数のＭＰＵ等の演算処理部、保護リソースを有しないノーマルモードおよび保護リソースを有するセキュアモードを含む複数の動作モードに基づいて、ドメインを生成する。
【００７９】
なお、複数の演算処理部および複数の動作モードの他に、更に、動作モードの頬リソースに基づいてドメインを生成してもよい。また、更に、実行領域を含む仮想環境に基づいて、ドメインを生成してもよい。また、更に、仮想環境および実環境を含む複数の環境に基づいて、ドメインを生成してもよい。
【００８０】
ここで、ドメインの生成とは、任意に定めた１つまたは複数のエリア（Ａ−ＭＰＵ１６、Ｃ−ＭＰＵ１２、ノーマルモード、セキュアモード、仮想環境）を、ＤＣが、情報やリソースを共有する１つの領域として制御することでドメインを実現することを意味している。
【００８１】
また、上記の保護リソースとは、例えばメモリや暗号エンジンである。また、実行領域とは、各種プログラムやアプリケーションやソフトウェアを実行するための領域や部位を示し、プログラムやデータを含むものである。
【００８２】
図２は、主にＣ−ＭＰＵ１２およびＡ−ＭＰＵ１６の分割されたドメインの一例を示す図である。
【００８３】
図２に示すように、Ｃ−ＭＰＵ１２は、ＯＤ（Ｏｐｅｒａｔｏｒ Ｄｏｍａｉｎ）を有する。Ａ−ＭＰＵ１６は、ノーマルモードおよびセキュアモードにおいて利用される実行領域を有する。また、Ａ−ＭＰＵ１６は、ＯＤ（Ｏｐｅｒａｔｏｒ Ｄｏｍａｉｎ）およびＵＤ（Ｕｓｅｒ Ｄｏｍａｉｎ）を有する。
【００８４】
ＯＤは、携帯電話端末１０のオペレータ向けのプラットフォーム構築とアプリケーション実行が可能な環境（領域）であり、他ドメインから直接アクセスできない。
【００８５】
ＵＤは、携帯電話端末１０の所有者又は所有者へサービスを提供するサードパーティが利用するデータやアプリケーションの実行が可能な環境（実行領域）であり、他ＵＤから許可された場合のみ他ＵＤリソースへのアクセスや他ＵＤとの通信が可能である。
【００８６】
Ｃ−ＭＰＵ１２およびＡ−ＭＰＵ１６は、ノーマルモード、セキュアモードのモード切替によって、ＯＤ、ＵＤを排他的に形成する。ただし、Ｃ−ＭＰＵ１２およびＡ−ＭＰＵ１６は、両モードを排他的に形成せずに両モードを同時に処理可能なＭＰＵであってもよい。
【００８７】
Ａ−ＭＰＵ１６のＯＤは、ＴＣＢ（Ｔｒｕｓｔｅｄ Ｃｏｍｐｏｎｅｎｔ Ｂａｓｅ）、ＴＣＢ以外のノーマルモードのＯＤ、およびＴＣＢ以外のセキュアモードのＯＤを有する。また、Ｃ−ＭＰＵ１２のＯＤは、ＴＣＢ以外のノーマルモードのＯＤを有する。
【００８８】
Ａ−ＭＰＵ１６のＯＤに含まれるＴＣＢは、ＨＷ（Ｈａｒｄｗａｒｅ） Ｐｌａｔｆｏｒｍ２１、ＩＰＬ（Ｉｎｉｔｉａｌ Ｐｒｏｇｒａｍ Ｌｏａｄｅｒ）２２、ＤＣ（Ｄｏｍａｉｎ Ｃｏｏｒｄｉｎａｔｏｒ）２３、ＭＳ（Ｍｏｄｅ Ｓｅｌｅｃｔｏｒ）２４、ＶＭＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｍｏｎｉｔｏｒ）２５、ＭＢ（ＭＰＵ Ｂｒｉｄｇｅ）１４、およびＭＲＴＭ（Ｍｏｂｉｌｅ Ｒｅｍｏｔｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ）１８を有する。なお、ＴＣＢは概念的な区分けであるため、ＭＲＴＭ１８やＭＢ１４など、ＭＰＵ内に含まれない構成要素についても、ＴＣＢに含まれるものとして扱うことが可能である。
【００８９】
ＨＷ Ｐｌａｔｆｏｒｍ２１は、Ａ−ＭＰＵ１６自体が備える暗号処理機能、ＨＷ固有鍵、モード切り替え機能の総称である。また、ＨＷ Ｐｌａｔｆｏｒｍ２１は、内部ＲＯＭ１７（ＣＲＴＭ）１７、ＨＷ固有鍵、ＭＣ（Ｍｏｄｅ Ｃｏｎｔｏｌｌｅｒ）を有している。
【００９０】
ここで、ＭＣは、ＭＳと同様にモード切り替え機能を有する。また、ＭＣは、ＭＢ１４と同様に、ハードウェア的要素とソフトウェア的要素をあわせ持つ。
【００９１】
ＩＰＬ２２は、外部ＲＯＭ（図示せず）において最初に実行されるプログラムであり、各種のハードウェア設定やＫｅｒｎｅｌの起動を司る。
【００９２】
ＤＣ２３は、ドメイン毎に定義されるセキュリティポリシに従いＶＭＭ２５とＭＳ２４とＭＢを統合的に制御し、携帯電話端末１内の異なる複数エリアにまたがるドメインを形成する。なお、ＤＣ２３は、ドメイン制御部としての機能を有する。
【００９３】
ＭＳ２４は、ノーマルモードおよびセキュアモードのモード切り替え機構であり、モード間の排他制御を行う。
【００９４】
ＶＭＭ２５は、ハードウェアの仮想化層であり、仮想環境間の排他制御を行う。
【００９５】
Ａ−ＭＰＵ１６およびＣ−ＭＰＵ１２において、ＴＣＢ以外のセキュアモードのＯＤおよびＵＤは、ＯＳ（セキュアモード用ＯＳ、Ａ−ＯＳ、もしくはＣ−ＯＳ）およびアプリ（セキュアモード用アプリ、Ａ−ａｐｐ、もしくはＣ−Ａｐｐ）を有する。
【００９６】
さらに、Ａ−ＭＰＵ１６およびＣ−ＭＰＵ１２において、各種データを格納する領域として、ＭＴＭ（Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ）の一例でありＯＤに含まれるＶｉｒｔｕａｌｉｚｉｎｇ ＭＲＴＭ（Ａ−ｖＭＲＴＭもしくはＣ−ｖＭＲＴＭ）や、ＵＤに含まれるＶｉｒｔｕａｌｉｚｉｎｇ ＭＬＴＭ（Ａ−ｖＬＴＭ）を有する。
【００９７】
ｖＭＲＴＭは、Ａ−ＭＰＵ１６のノーマルモードで実現されるＵＤで利用するＭＬＴＭであり、その機能はＭＲＴＭ１８を用いることで実現される。
【００９８】
ｖＭＬＴＭは、Ｃ−ＭＰＵ１２またはＡ−ＭＰＵ１６のノーマルモードで実現されるＯＤからＭＲＴＭ１８にアクセスするための仮想ドライバである。
【００９９】
なお、ドメイン生成の際には、同一のセキュリティポリシに基づいてアクセス制御される実行領域は、同一のドメインとして生成される。例えば図２では、Ａ−ＭＰＵ１６のノーマルモードのＯＤとＡ−ＭＰＵ１６のセキュアモードのＯＤとＣ−ＭＰＵ１２のＯＤ、Ａ−ＭＰＵ１６のノーマルモードのＵＤ１とセキュアモード）のＵＤ１、Ａ−ＭＰＵ１６のノーマルモードのＵＤ２とセキュアモードのＵＤ２が、それぞれ同一のドメインとして生成される。
【０１００】
次に、携帯電話端末１０の電源ＯＮから各実行領域による実行が可能な状態となるまでの一連の処理の流れ（Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅや起動時処理とも称する）の一例について説明する。
【０１０１】
Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅをさらに詳細な処理に分けると、ＴＣＢを確立するＳｅｃｕｒｅ Ｂｏｏｔ０、複数ＭＰＵをまたいだＯＤを確立するＳｅｃｕｒｅ Ｂｏｏｔ１および１’、ＵＤを確立するＳｅｃｕｒｅ Ｂｏｏｔ２の３レイヤに分けられる。
【０１０２】
Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅでは、携帯電話プラットフォーム（ここでは、主にＡ−ＭＰＵ１６およびＣ−ＭＰＵ１２である）を１つのＯＤと複数ＵＤにドメイン分割する。ＯＤのドメイン分割をＯＤ確立、ＵＤのドメイン分割をＵＤ確立とも称する。
【０１０３】
ＯＤ確立では、内部ＲＯＭ（ＣＲＴＭ）１７とＩＰＬ２２とＤＣ２３を起動するＳｅｃｕｒｅ Ｂｏｏｔ０と、Ａ−ＭＰＵ１６のＯＤのノーマルモードのＯＳ／アプリ／データ（ＩＭＥＩなど）までを起動するＳｅｃｕｒｅ Ｂｏｏｔ１と、Ｃ−ＭＰＵ１６のＯＤのノーマルモードのＯＳ／アプリ／データまでを起動するＳｅｃｕｒｅＢｏｏｔ１’と、の３つのレイヤに分けて処理が行われる。
【０１０４】
ＵＤ確立では、Ａ−ＭＰＵ ＵＤのノーマルモードのＯＳ／アプリ／データまでを起動するＳｅｃｕｒｅ Ｂｏｏｔ２の１つのレイヤで処理が行われる。ＯＤ確立後にＵＤ確立を実行する。
【０１０５】
そして、後述するが、ＯＤ確立およびＵＤ確立では、予め定めたレイヤ毎の重要度に応じ、完全性検証に失敗した場合の挙動を定める。
【０１０６】
Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅでは、内部ＲＯＭ１７、ＩＰＬ２２、ＤＣ２３などの各コンポーネントやデータ（ＩＭＥＩ等）に対して、ソフトウェア同様の完全性検証、検証失敗時処理の実行、およびＳｅｃｕｒｅ Ｆｌａｇを用いた処理結果に依存した検証／復号処理を実行する。
【０１０７】
また、Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅ時に起動を実行するコンポーネントは、起動対象コンポーネントを自身の固有鍵で復号後に完全性を検証（計測）する。完全性検証に成功した場合、つまり完全性が保持されていると判定された場合には、起動対象コンポーネントの起動を実施する。一方、完全性検証に失敗した場合には、起動対象コンポーネントの起動を禁止する。なお、起動を実行するコンポーネントは、暗号化された起動対象コンポーネントをハッシュの対象とすれば、完全性検証を行なった後に復号化することも可能である。
【０１０８】
携帯電話端末１０では、特に、移動機固有番号であるＩＭＥＩとＩＭＥＩを扱うソフトウェアの完全性を保護することが求められている。携帯電話網では、ＩＭＥＩを用いて網にアクセスする端末をアクセス制御することで盗難端末の無効化等を実現するため、ＩＭＥＩの完全性が必要不可欠である。さらに、ＰＣにも携帯電話の通信機能が備えられるようになり、今後はＰＣでも同様にＩＭＥＩ保護が求められる可能性もあるため、ソフトウェア同様にＩＭＥＩ等のデータについても改ざん検証を行う本実施形態におけるＢｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅは、大変有用である。
【０１０９】
ここで、上記のコンポーネントを暗号化する方法の一例について説明する。
【０１１０】
携帯電話端末１０は、製造時に、アプリ固有鍵でデータを暗号化、アプリをＯＳ固有鍵で暗号化する様に、起動を実行するコンポーネントの固有鍵で起動対象コンポーネントの暗号化を繰返し、暗号化コンポーネントを不揮発メモリ１５に保存している。ルートの鍵はＨＷ固有鍵とする。このような暗号化方法をＣｈａｉｎ−ｂｉｎｄｉｎｇとも称する。
【０１１１】
このように、Ａ−ＭＰＵ１６やＣ−ＭＰＵ１２が、個別に起動可能な複数のコンポーネント（プログラムを含む実行領域の一例）を階層的に有し、所定階層のコンポーネントが、所定階層のコンポーネントの固有鍵を用いて所定階層よりも一段階上位層のコンポーネントを暗号化する暗号化処理を実行する。また、上記暗号化処理は、最上位層よりも一段階下位層を所定階層としてから最下位層を所定階層とするまで一段階ずつ順に実行されることも可能である。これにより暗号化されたコンポーネントが不揮発メモリ１５に保存されている。
【０１１２】
また、上記コンポーネントが、所定階層の実行領域の固有鍵を用いて所定階層よりも一段階下位層の実行領域が暗号化される暗号化処理が、最上位層を所定階層としてから最下位層を所定階層とするまで一段階ずつ順に実行された後、Ａ−ＭＰＵ１６やＣ−ＭＰＵ１２に記憶されるようにしてもよい。
【０１１３】
また、最上位層の実行領域が、最上位層の実行領域の暗号化前に、ＩＭＥＩ等を含むデータを用いて暗号化されるようにすることも可能である。
【０１１４】
図３〜図６は、携帯電話端末１０が実施するＢｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅの一例を示すフローチャートである。ここでは、特に、完全性検証について示している。携帯電話端末１０は、Ｓｅｃｕｒｅ Ｂｏｏｔ０の実施後に、Ｓｅｃｕｒｅ Ｂｏｏｔ１／１’／２を実施する。
【０１１５】
まず、Ｓｅｃｕｒｅ Ｂｏｏｔ０において、内部ＲＯＭ１７は、自身のハッシュ値を計算してＰＣＲを設定し、Ｓｅｃｕｒｅ Ｆｌａｇ０をＯＮに設定する。続いて、Ｆｌａｇ０＝ＯＮなら、内部ＲＯＭ１７は、ＩＰＬ２２をＨＷ固有鍵とＭＲＴＭ固有鍵で復号してハッシュ値を計算し、ハッシュ期待値であるＲＩＭ＿Ｃｅｒｔと上記計算したハッシュ値とを比較することで、完全性を検証する。検証成功時には、内部ＲＯＭ１７が、ＭＲＴＭ１８へＩＰＬ２２のハッシュ値をＰＣＲに設定し、Ｓｅｃｕｒｅ Ｆｌａｇ１をＯＮに設定後、ＩＰＬ２２を起動する。一方、検証失敗時には、内部ＲＯＭ１６は、起動を停止する（ステップＳ１）。なお、以降の完全性検証においても、計算したハッシュ値はＲＩＭ＿Ｃｅｒｔとの比較が行われる。
【０１１６】
Ｆｌａｇ１＝ＯＮなら、ＩＰＬ２２は、ＤＣ２３をＭＲＴＭ固有鍵で復号して完全性を検証する。検証成功時には、ＩＰＬ２２は、ＭＲＴＭ１８へＤＣ２３のハッシュ値をＰＣＲに設定、Ｓｅｃｕｒｅ Ｆｌａｇ２をＯＮに設定後、ＤＣ２３を起動する。一方、検証失敗時には、ＩＰＬ２２は、起動を停止する（ステップＳ２）。
【０１１７】
なお、ここでは、ＤＣ２３がＶＭＭ２５、ＭＳ２４、ＭＢ１４を包含しており、ＤＣ２３の改ざん検証時には、ＶＭＭ２５、ＭＳ２４、ＭＢ１４の順に段階的に改ざん検証が行なわれる。これは、ＤＣ２３のバイナリファイル内にＶＭＭ２５、ＭＳ２４４、ＭＢ１４が含まれており、ＤＣ２３を検証すると一緒に検証されるためである。なお、ＤＣ２３がＶＭＭ２５、ＭＳ２４、ＭＢ１４を包含せずに、ＤＣ２３の改ざん検証に成功した場合に、ＶＭＭ２５、ＭＳ２４、ＭＢ１４の順に検証および起動を行なうようにしてもよい。
【０１１８】
なお、Ｓｅｃｕｒｅ Ｂｏｏｔ０の実装方法として、 完全性検証及び検証後の対象ソフトウェアの起動まで含めた全てをセキュアモードで処理する方法と、 完全性検証のみをセキュアモードで処理する方法が考えられる。いずれを採用するかは各プラットフォームのＭＳ２４の実装に応じて決定すべきである。
【０１１９】
ＤＣ２３の完全性検証後、携帯電話端末１０はＳｅｃｕｒｅ Ｂｏｏｔ１を実施する。
【０１２０】
Ｓｅｃｕｒｅ Ｂｏｏｔ１において、まず、Ｆｌａｇ２＝ＯＮなら、ＤＣ２３は、Ａ−ＯＳ０をＤＣ固有鍵で復号して完全性を検証する。検証成功時には、ＤＣ２３は、ＭＲＴＭ１８へＡ−ＯＳ０のハッシュ値をＰＣＲに設定し、Ｓｅｃｕｒｅ Ｆｌａｇ３をＯＮに設定後、Ａ−ＯＳ０を起動する。一方、検証失敗時には、ＤＣ２３が、携帯電話端末１０をリカバリーモードへ遷移させる（ステップＳ３）。
【０１２１】
続いて、Ｆｌａｇ３＝ＯＮなら、Ａ−ＯＳ０は、Ａ−Ａｐｐ０をＡ−ｖＭＲＴＭ０固有鍵で復号して完全性を検証する。検証成功時には、Ａ−ＯＳ０は、Ａ−ｖＭＲＴＭ０へＡ−Ａｐｐ０のハッシュ値をＰＣＲに設定し、Ｓｅｃｕｒｅ Ｆｌａｇ４をＯＮに設定後、Ａ−Ａｐｐ０を起動する。一方、検証失敗時には、Ａ−ＯＳ０が、携帯電話端末１０をリカバリーモードへ遷移させる（ステップＳ４）。
【０１２２】
続いて、Ｆｌａｇ４＝ＯＮなら、Ａ−Ａｐｐ０は、Ａ−Ｄａｔａ０（ＩＭＥＩ等）をＣ−Ａｐｐ０固有鍵で復号して完全性を検証する。検証成功時には、Ａ−Ａｐｐ０は、Ａ−ｖＭＲＴＭ０へＡ−Ｄａｔａ０のハッシュ値をＰＣＲに設定し、Ｓｅｃｕｒｅ Ｆｌａｇ５をＯＮに設定後、Ａ−Ｄａｔａ０をＡ−ｖＭＲＴＭ０にキャッシュする。一方、検証失敗時には、Ａ−Ａｐｐ０が、携帯電話端末１０をリカバリーモードへ遷移させる（ステップＳ５）。
【０１２３】
ＤＣ２３の完全性検証後、携帯電話端末１０はＳｅｃｕｒｅ Ｂｏｏｔ１’も実施する。Ｓｅｃｕｒｅ Ｂｏｏｔ１’の実施はＳｅｃｕｒｅ Ｂｏｏｔ１の実施と並行することが可能である。
【０１２４】
Ｓｅｃｕｒｅ Ｂｏｏｔ１’において、まず、Ｆｌａｇ２＝ＯＮなら、ＤＣ２３は、Ｃ−ＯＳ０をＤＣ固有鍵で復号して完全性を検証する。検証成功時には、ＤＣ２３は、ＭＲＴＭ１８へＣ−ＯＳ０のハッシュ値をＰＣＲに設定し、Ｓｅｃｕｒｅ Ｆｌａｇ３’をＯＮに設定後、Ｃ−ＯＳ０／Ｃ−Ａｐｐ０／Ｃ−Ｄａｔａ０をＣ−ＭＰＵ１２へ転送する。一方、検証失敗時には、Ｃ−ＯＳ０が、携帯電話端末１０をリカバリーモードへ遷移させる（ステップＳ３’）。
【０１２５】
続いて、Ｆｌａｇ３’＝ＯＮなら、ＭＢ１４は、Ｃ−ＯＳ０を起動し、Ｃ−ｖＭＲＴＭ０とＡ−ｖＭＲＴＭ０を用いて、Ｃ−ＯＳ０とＡ−ＯＳ０との間でＳＡＣ（Ｓｅｃｕｒｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｃｈａｎｎｅｌ）を確立する。ＳＡＣは、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）にように相互認証と通信路の暗号化を実現した通信路である。ＳＡＣ確立成功後、Ｃ−ＯＳ０は、Ｃ−Ａｐｐ０をＣ−ｖＭＲＴＭ０固有鍵で復号して完全性を検証する。検証成功時には、Ｃ−ＯＳ０は、Ｃ−ｖＭＲＴＭ０へＣ−Ａｐｐ０のハッシュ値をＰＣＲに設定し、Ｓｅｃｕｒｅ Ｆｌａｇ４’をＯＮに設定後、Ｃ−Ａｐｐ０を起動する。一方、検証失敗時には、Ｃ−ＯＳ０が、携帯電話端末１０をリカバリーモードへ遷移させる（ステップＳ４’）。
【０１２６】
続いて、Ｆｌａｇ４’＝ＯＮなら、Ｃ−Ａｐｐ０は、Ｃ−Ｄａｔａ０をＣ−Ａｐｐ０固有鍵で復号して完全性を検証する。検証成功時には、Ｃ−Ａｐｐ０は、Ｃ−ｖＭＲＴＭ０へＡ−Ｄａｔａ０のハッシュ値をＰＣＲに設定し、Ｓｅｃｕｒｅ Ｆｌａｇ５をＯＮに設定後、Ａ−Ｄａｔａ０をＡ−ｖＭＲＴＭ０にキャッシュする。一方、検証失敗時には、Ｃ−Ａｐｐ０が携帯電話端末１０をリカバリーモードへ遷移させる。
【０１２７】
ここでは、Ｃ−ＭＰＵ１２側で完全性検証を行うＳｅｃｕｒｅ Ｂｏｏｔ１’の実施方法を示したが、Ａ−ＭＰＵ１６側のＤＣ２３により、Ｃ−ＯＳ０のみではなく、Ｃ−Ａｐｐ０／Ｃ−Ｄａｔａ０も復号／完全性検証してからＣ−ＭＰＵ１２へ転送することも可能である。
【０１２８】
ＤＣ２３の完全性検証後、携帯電話端末１０はＳｅｃｕｒｅ Ｂｏｏｔ２を実施する。Ｓｅｃｕｒｅ Ｂｏｏｔ２の実施はＳｅｃｕｒｅ Ｂｏｏｔ１および１’の実施と並行することが可能である。
【０１２９】
Ｓｅｃｕｒｅ Ｂｏｏｔ２において、まず、Ｆｌａｇ２＝ＯＮ、Ｆｌａｇ５＝ＯＮ、かつＦｌａｇ５’＝ＯＮなら、ＤＣ２３は、Ａ−ＯＳ１をＤＣ固有鍵で復号して完全性を検証する。検証成功時には、ＤＣ２３は、ＭＲＴＭ１８へＡ−ＯＳ１のハッシュ値をＰＣＲに設定し、Ｓｅｃｕｒｅ Ｆｌａｇ６をＯＮに設定後、Ａ−ＯＳ１を起動する。一方、検証失敗時には、ＤＣ２３が携帯電話端末１０をリポートモードへ遷移させる（ステップＳ６）。
【０１３０】
続いて、Ｆｌａｇ６＝ＯＮなら、Ａ−ＯＳ１はＡ−Ａｐｐ１をＡ−ｖＭＲＴＭ１固有鍵で復号して完全性を検証する。検証成功時には、Ａ−ＯＳ１は、Ａ−ｖＭＬＴＭ１へＡ−Ａｐｐ１のハッシュ値をＰＣＲに設定し、Ｓｅｃｕｒｅ Ｆｌａｇ７をＯＮに設定後、Ａ−Ａｐｐ１を起動する。一方、検証失敗時には、Ａ−ＯＳ１が携帯電話端末１０をリポートモードへ遷移させる（ステップＳ７）。
【０１３１】
続いて、Ｆｌａｇ７＝ＯＮなら、Ａ−Ａｐｐ１は、Ａ−Ｄａｔａ１をＡ−Ａｐｐ１固有鍵で復号して完全性を検証する。検証成功時には、Ａ−Ａｐｐ１は、Ａ−ｖＭＬＴＭ１へＡ−Ｄａｔａ１のハッシュ値をＰＣＲに設定し、Ｓｅｃｕｒｅ Ｆｌａｇ８をＯＮに設定後、Ａ−Ｄａｔａ１をＡ−ｖＭＬＴＭ１にキャッシュする。検証失敗時には、Ａ−Ａｐｐ１が、リポートモードへ遷移させる（ステップＳ８）。
【０１３２】
なお、図２のようにＵＤが複数存在する場合、Ａ−ＭＰＵ１６のＵＤ２以降の確立方法はＵＤ１と同じである。
【０１３３】
また、セキュアモードにおけるＯＤ／ＵＤの確立は、セキュアモード遷移時に実行される。確立の内容は、直接ＭＲＴＭ１８にアクセスすることを除いて、ノーマルモードの場合と同様である。なお、図３では、ノーマルモードを想定している。
【０１３４】
セキュアモードで実行される保護ソフトウェアは、暗号化された状態で不揮発メモリ１５に保存されており、実行直前にＨＷ Ｐｌａｔｆｏｒｍ２１により復号及び完全性の検証が行われ、成功時のみ実行が許可される。
【０１３５】
このように、携帯電話端末１０は、Ａ−ＭＰＵ１６やＣ−ＭＰＵ１２が、個別に起動可能な複数のコンポーネント（プログラムを含む実行領域の一例）を階層的に有し、所定階層のコンポーネントが、所定階層のコンポーネントの固有鍵を用いて所定階層よりも一段階上位層のコンポーネントを復号化し、一段階上位層のコンポーネントについて所定の検証処理を実行し、検証処理に成功した場合、上記一段階上位層のコンポーネントを起動する起動時処理を実行する。また、上記起動時処理が、最下位層を上記所定階層としてから最上位層よりも一段階下位層を上記所定階層とするまで一段階ずつ順に実行されることが可能である。
【０１３６】
さらに、最上位層の実行領域が、最上位層の実行領域の起動後に、最上位層の実行領域の固有鍵を用いてＩＭＥＩ等のデータを復号化し、所定の検証処理を実行し、上記検証処理に成功した場合、ＩＭＥＩ等のデータを操作可能とする。
【０１３７】
次に、Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅにおける検証失敗時の挙動の一例について説明する。
【０１３８】
本実施形態では、検証失敗時に次の５つのパターンを想定している。携帯電話端末１０は、Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅにおけるレイヤの重要度に応じて、検証失敗時の挙動を変更することが可能である。つまり、つまり所定階層の重要度に基づく復旧処理を実行することが可能である。
【０１３９】
（１）無視して起動を続ける。
（２）起動を停止する。
（３）検証に失敗したコンポーネントをリポジトリサーバ（外部サーバの一例）からダウンロードした正しいコンポーネントに差し替える（リカバリーモードとも称する）。
（４）１１０番通報等の非常時通報機能のみ利用できる（エマージェンシーモードとも称する）。
（５）失敗をユーザに通知する（リポートモードとも称する）。この通知は、図示しない報知部によって行われる。
【０１４０】
リカバリーモードで処理が失敗した場合は、エマージェンシーモードへ遷移させる。ただし、ＩＭＥＩ及びＩＭＥＩ関連ソフトウェア等の通信に必要となるコンポーネントの完全性が保証されている場合のみ遷移させる。ＵＤでの失敗時はユーザ（携帯電話端末１０の所有者又はサービス提供者）に失敗内容を通知するリポートモードに遷移させ、ユーザにそれ以降の処理を判断させる。
【０１４１】
また、Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅにおけるレイヤの重要度に応じて検証失敗時の挙動を変更する以外に、レイヤの重要度に応じて完全性検証のレベル自体を変更することも可能である。例えば、起動を高速化するため、重要度が低いほどコンポーネントの検証範囲を狭くする、あるいは検証される確率を低くする。最低限、ある期間内には全コンポーネントの全範囲が検証されるよう実装する必要はあるが、重要度の低いレイヤの検証処理の一部を省略することで高速化することも可能である。
【０１４２】
さらに、復旧処理に失敗した場合には、復旧処理に失敗した所定階層（コンポーネント）よりも当該所定階層の重要度よりも高い重要度に基づく復旧処理を行うようにしてもよい。
【０１４３】
図３では、検証失敗時には、Ｓｅｃｕｒｅ Ｂｏｏｔ１および１’においてはリカバリーモード、Ｓｅｃｕｒｅ Ｂｏｏｔ２においてはリポートモードへ遷移することを説明しているが、各レイヤの重要度等に応じて、リカバリーモード、エマージェンシーモード、リポートモード、起動停止のいずれかに遷移すればよい。ただし、Ｓｅｃｕｒｅ Ｂｏｏｔ０においては、非常に重要度が高いため、検証失敗時には起動停止を行うようにする。また、リポートモードでは、例えば、ユーザインタフェース（ＵＩ）でユーザに向けてメッセージの表示等を行ったり、サービス提供サーバなどの外部サーバに対してメッセージを送信したりすることが可能である。
【０１４４】
次に、ＤＣ２３によるアクセス制御の一例について説明する。
【０１４５】
図２に示したように、携帯電話端末１におけるドメインは、Ａ−ＭＰＵ１６のＴＣＢ、Ａ−ＭＰＵ１６のノーマルモード０の仮想環境０／１／２、Ａ−ＭＰＵ１６のセキュアモード０／１／２、Ｃ−ＭＰＵ１２のノーマルモード０の１つ又は複数のエリアから構成される。例えば、ＯＤは、Ａ−ＭＰＵ１６のＴＣＢ、Ａ−ＭＰＵ１６のノーマルモード０の仮想環境０、A−ＭＰＵ１６のセキュアモード０、Ｃ−ＭＰＵ１２のノーマルモード０の複数エリアから構成される。ただし、ドメインの構成は上記構成に限られない。
【０１４６】
ここで、ＤＣ２３の役割の１つは、これらのＯＤに所属する複数エリア内において情報とリソースをフレキシブルに共有し、他ドメインへの情報流出とリソースを制御することにある。ＤＣ２３は、複数ＭＰＵを制御するＭＢ、複数の動作モードを制御するＭＳ２４、複数仮想環境を制御するＶＭＭ２５を監視し、ＯＤに対応するベースポリシとＵＤに対応するドメインポリシに従い、情報およびリソースアクセスを制御する。なお、ベースポリシおよびドメインポリシは、セキュリティポリシの一例である。
【０１４７】
ここで、エリアとは、Ａ−ＭＰＵ１６のノーマルモードのＯＤやＵＤ１やＵＤ２、Ａ−ＭＰＵ１６のセキュアモードのＯＤやＵＤ１やＵＤ２、Ｃ−ＭＰＵ１２のＯＤなどの実行領域を示すものである。
【０１４８】
携帯電話端末１０は、一例として、以下のようにＤＣ２３によるドメイン間情報流通の制御を行う。
【０１４９】
・あらかじめ、例えばＤＣ２３によって、エリアから他のエリアへ情報は必ずＤＣ２３を経由するように指定する。
・ＤＣ２３は、送信元エリアの属するドメインと送信先エリアの属するドメインが一致する場合のみ通信を許可する（ベースポリシ）。
・ＤＣ２３は、送信元エリアの属するドメインに予め設定されたドメインポリシが許可する場合は送信先エリアの属するドメインが異なる場合も通信を許可する。
・ＤＣ２３は、Ｓｅｃｕｒｅ Ｆｌａｇを確認し、ＦｌａｇがＯＦＦの部分があるエリアからの通信およびＯＦＦの部分があるエリアへの通信については禁止する。つまり、所定の検証処理に失敗したエリアとの間の通信を禁止する。
【０１５０】
また、携帯電話端末１０は、一例として、以下のようにＤＣ２３によるドメイン間リソース共有の制御を行う。図７にドメイン間リソース共有の一例を示す図である。
【０１５１】
・あらかじめ、あるエリアからＭＲＴＭ１８にアクセスする場合は、必ずＤＣ２３を経由するように指定する。
・ＭＲＴＭ１８はＳｅｃｕｒｅ Ｆｌａｇ０／１／２／３／６、Ａ−ｖＭＲＴＭ０はＳｅｃｕｒｅ Ｆｌａｇ４／５、Ｃ−ｖＭＲＴＭ０はＳｅｃｕｒｅ Ｆｌａｇ４’／５’、Ａ−ｖＭＬＴＭ１はＳｅｃｕｒｅ Ｆｌａｇ７／８を管理し、ＤＣ２３は所属するドメインからのアクセスしか許可しない（ベースポリシ）。
・セキュアモードにおけるエリアからは、直接ＤＣ２３を経由してＭＲＴＭ１８へアクセスすることを許可とする。図７では、一例としてＯＳからアクセスすることを示している。
・ノーマルモードにおけるエリアからは、仮想ＭＴＭ（ｖＭＲＴＭ又はｖＭＬＴＭ）経由以外のアクセスを許可しない。仮想ＭＴＭ経由の場合、ＤＣ２３は、ＭＲＴＭ１８のＰＣＲ／Ｓｅｃｕｒｅ ＦｌａｇをＲｅａｄ Ｏｎｌｙ（読み取り専用）に制御し、かつＭＲＴＭ１８以外のＰＣＲ／Ｓｅｃｕｒｅ Ｆｌａｇは参照も許可しない（ベースポリシ）。
・ＤＣ２３は、アクセス先エリアの属するドメインに予め設定されたドメインポリシが許可する場合には、アクセス元エリアの属するドメインが異なる場合もＰＣＲ／Ｓｅｃｕｒｅ Ｆｌａｇ参照を許可する。
【０１５２】
次に、Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅ後における完全性検証の一例について説明する。
【０１５３】
Ｃ−ＭＰＵ１２においてＩＭＥＩを利用する場合、ＳＡＣ経由でＩＭＥＩをロードしてＣ−ｖＭＲＴＭ０へキャッシュする。ただし、利用時又は定期的にＩＭＥＩおよびＩＭＥＩに関連するソフトウェアの完全性検証が必要と考えられる。この完全性検証は、ＩＭＥＩをＡ−ｖＭＲＴＭ０からリロードする際の流通経路となるソフトウェアをデータドリブンで検証することで、最小限の範囲を利用直前に検証するものである。なお、ＩＭＥＩをリロードする毎に完全性検証が発生する為、実装時はＣ−ｖＭＲＴＭ０のキャッシュの有効期間を定め、許容される負荷の範囲でリロードするべきである。
【０１５４】
具体的には、ＩＭＥＩ等のデータにＶｅｒｉｆｉｃａｔｉｏｎ Ｔａｇを設け、データ送信元コンポーネントはデータ送信先コンポーネントの完全性を実施し、検証成功時のみ送信することで実現できる。検証成功か否は、Ｖｅｒｉｆｉｃａｔｉｏｎ Ｔａｇ＝ＯＮか否かを判断する。また、リロード時も各コンポーネントにおける完全性検証結果をＭＴＭのＳｅｃｕｒｅ Ｆｌａｇに設定することで、事前の検証が失敗している場合には、各コンポーネントからＩＭＥＩをＣ−ＭＰＵ１２へ出力させない。なお、Ｖｅｒｉｆｉｃａｔｉｏｎ ＴａｇはＩＭＥＩ等のデータとともにＭＴＭに保存可能である。
【０１５５】
図８は、Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅ後における完全性検証の一例を示すフローチャートである。
【０１５６】
まず、Ｃ−ＭＰＵ１２は、Ｃ−ｖＭＲＴＭ０にキャッシュしているＩＭＥＩの有効期間が過ぎた場合などに、Ｃ−Ａｐｐ０がＡ−Ａｐｐ０へＩＭＥＩを要求する（ステップＳ１１）。
【０１５７】
続いて、Ａ−ＭＰＵ１６は、Ａ−Ａｐｐ０がＡ−ｖＭＲＴＭ０からＩＭＥＩを読み出す（ステップＳ１２）。なお、ＩＭＥＩはＡ−ｖＭＲＴＭ０又はＡ−ｖＭＲＴＭ経由でＭＲＴＭ１８にキャッシュされているとする。
【０１５８】
続いて、Ａ−ＭＰＵ１６は、Ｖｅｒｉｆｉｃａｔｉｏｎ ＴａｇをＯＮに設定してＩＭＥＩメッセージをＣ−Ａｐｐ０宛に送る（ステップＳ１３）。
【０１５９】
続いて、Ａ−ＭＰＵ１６またはＣ−ＭＰＵ１２は、ＩＭＥＩメッセージを受信した通信経路上のプログラム（ＰＧ）（Ａ−ＯＳ０、ＤＣ２３、またはＣ−ＯＳ０に含まれる）が、Ｖｅｒｉｆｉｃａｔｉｏｎ＿Ｔａｇ＝ＯＮか否か判定する。
【０１６０】
Ｖｅｒｉｆｉｃａｔｉｏｎ＿Ｔａｇ＝ＯＮの場合、Ａ−ＭＰＵ１６およびＣ−ＭＰＵ１２は、ＩＭＥＩを送ってきた送り元プログラムに対応するＳｅｃｕｒｅ ＦｌａｇがＯＮであるか否かを判定する（ステップＳ１５）。
【０１６１】
Ｓｅｃｕｒｅ ＦｌａｇがＯＮである場合、Ａ−ＭＰＵ１６およびＣ−ＭＰＵ１２は、送り先プログラムの改ざん検証を実行し（ステップＳ１６）、送り先プログラム（例えばＣ−ＯＳ０）の改ざんがないか判定する（ステップＳ１７）。
【０１６２】
送り先プログラムの改ざんがないと判定された場合、Ａ−ＭＰＵ２６およびＣ−ＭＰＵ２２は、送り先プログラムに対応するＳｅｃｕｒｅ ＦｌａｇをＯＮし、ＩＭＥＩメッセージを送り先プログラムに送信する（ステップＳ１８）。
【０１６３】
なお、ステップＳ１４〜Ｓ１８は、通信経路上のプログラム数だけ繰り返される。
【０１６４】
続いて、Ａ−ＭＰＵ１６およびＣ−ＭＰＵ１２は、例えばステップＳ１３に示すように、Ｃ−Ａｐｐ０へＩＭＥＩメッセージを送信したか否かを判定する。ＩＭＥＩメッセージを送信していない場合、ステップＳ１３の直前に戻る。
【０１６５】
ＩＭＥＩメッセージを送信されると、Ｃ−ＭＰＵ１２は、Ｃ−Ａｐｐ０がＩＭＥＩメッセージを受信する（ステップＳ２０）。
【０１６６】
続いて、Ｃ−ＭＰＵ１２は、送り元プログラムのＳｅｃｕｒｅ ＦｌａｇがＯＮであるか否かを判定する（ステップＳ２１）。
【０１６７】
送り元プログラムのＳｅｃｕｒｅ ＦｌａｇがＯＮである場合、Ｃ−ＭＰＵ１２は、ＩＭＥＩをＣ−ｖＭＲＴＭ０にキャッシュする（ステップＳ２２）。
【０１６８】
このように、Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅ後における完全性検証では、携帯電話端末１０は、例えば、ＩＭＥＩの利用時や有効期限が過ぎた場合に、Ｃ−ＭＰＵ１２がＩＭＥＩ等のデータの送信要求をＡ−ＭＰＵ１６へ行い、Ｃ−ＭＰＵ１２は、Ａ−ＭＰＵ１６とＣ−ＭＰＵ１２とを接続する通信路を構成するプログラムを含む実行領域に関する検証処理が成功した場合、Ａ−ＭＰＵ１６から送信されたデータを記憶する。
【０１６９】
携帯電話端末１０によれば、以下の効果が得られる。
【０１７０】
・複数ＭＰＵ等の演算処理部、複数モードに基づいてドメイン分割することができるため、複数の演算処理部を備える場合であっても、十分な利便性および安全性を考慮したドメイン分割を実施することが可能である。
【０１７１】
・従来のＴｒｕｓｔｅｄ ＢｏｏｔおよびＳｅｃｕｒｅ Ｂｏｏｔではソフトウェアの完全性計測または完全性検証のみであったが、本実施形態におけるＢｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅでは、ソフトウェアおよびデータ（ＩＭＥＩ等）の完全性検証まで行うことが可能である。したがって、プログラムのみに依存したセキュアブートではなく、保護したいデータにも依存させるセキュアブート（本実施形態におけるＢｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅ）が実行可能である。
【０１７２】
・携帯電話端末１０は、復号／改ざん検証時に一段階前の処理結果をＳｅｃｕｒｅ Ｆｌａｇにより確認すること、検証成功時にＳｅｃｕｒｅ Ｆｌａｇ＝ＯＮを設定すること、データまで起動プロセスで復号及び完全性検証することにより、所望のドメイン分割および完全性検証が実現できる。
【０１７３】
・コピーされたＩＭＥＩがコピー先端末で利用できないようにするために、Ｃｈａｉｎ−ｂｉｎｄｉｎｇによりＩＭＥＩをＨＷ Ｐｌａｔｆｏｒｍ２１／ＭＲＴＭ１８の固有鍵をルートとしてチェーンで暗号化することで、コピー先端末ではＩＭＥＩ及び関連ソフトウェアの全てが復号困難となる。
【０１７４】
・生産工程で不揮発メモリ１５に記載されたＩＭＥＩと無線通信路に出力されたＩＭＥＩの一致は、ＩＭＥＩがＯＤ確立後に完全性が保証された状態でＭＲＴＭにキャッシュされることで実現される。これは、前述したＣｈａｉｎ−ＵｎｂｉｎｄｉｎｇによるＩＭＥＩ自体の完全性検証のみではなく、ＩＭＥＩを利用するコンポーネントの完全性がＢｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅで保証され、かつＩＭＥＩの復号／検証処理がＳｅｃｕｒｅ Ｆｌａｇに依存して制御されていることからも保証される。さらに、ＩＭＥＩ利用時にＩＭＥＩドリブンで必要最小限のＩＭＥＩ関連ソフトウェアの検証を実行することで、ＩＭＥＩの保護を実現しつつ、効率的な通信側の処理を実現することができる。
【産業上の利用可能性】
【０１７５】
本発明は、複数の演算処理部を備える場合であっても、十分な利便性および安全性を考慮したドメイン分割を実行可能な情報処理装置および携帯電話装置等として有用である。
【図面の簡単な説明】
【０１７６】
【図１】本発明の実施形態にかかる携帯電話端末のハードウェア構成の一例を示す図
【図２】本発明の実施形態にかかる携帯電話端末における主にＣ−ＭＰＵ１２およびＡ−ＭＰＵ１６の分割されたドメインの一例を示す図
【図３】本発明の実施形態にかかるＢｏｏｔｓｔｒａｐ ＳｅｑｕｅｎｃｅのＳｅｃｕｒｅ Ｂｏｏｔ０の一例を示すフローチャート
【図４】本発明の実施形態にかかるＢｏｏｔｓｔｒａｐ ＳｅｑｕｅｎｃｅのＳｅｃｕｒｅ Ｂｏｏｔ１の一例を示すフローチャート
【図５】本発明の実施形態にかかるＢｏｏｔｓｔｒａｐ ＳｅｑｕｅｎｃｅのＳｅｃｕｒｅ Ｂｏｏｔ１’の一例を示すフローチャート
【図６】本発明の実施形態にかかるＢｏｏｔｓｔｒａｐ ＳｅｑｕｅｎｃｅのＳｅｃｕｒｅ Ｂｏｏｔ２の一例を示すフローチャート
【図７】本発明の実施形態にかかるドメイン間リソース共有の一例を示す図
【図８】本発明の実施形態にかかるＢｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅ後における完全性検証の一例を示すフローチャート
【符号の説明】
【０１７７】
１０ 携帯電話端末
１１ 無線部
１２ Ｃ−ＭＰＵ
１３ 揮発メモリ
１４ ＭＢ（ＭＰＵ Ｂｒｉｄｇｅ）
１５ 不揮発メモリ
１６ Ａ−ＭＰＵ
１７ 内部ＲＯＭ
１８ ＭＲＴＭ
２１ ＨＷ Ｐｌａｔｆｏｒｍ
２２ ＩＰＬ
２３ ＤＣ
２４ ＭＳ
２５ ＶＭＭ
【技術分野】
【０００１】
本発明は、情報処理装置および携帯電話装置に関し、特に、複数のＣＰＵを備える場合であっても、十分な利便性および安全性を考慮したドメイン分割を実行可能な情報処理装置および携帯電話装置に関する。
【背景技術】
【０００２】
近年、マルウェアによるＰＣ等の情報処理端末の被害が拡大している。このような情報処理端末の被害を最小限に抑えるために、仮想化技術、セキュリティに関する動作モードの設定、ソフトウェアの完全性計測または完全性検証の実施、ドメイン分割などが知られている。
【０００３】
仮想化技術は、同一のＣＰＵ内に複数の仮想環境を設け、仮想環境毎に異なるＯＳを実行する技術であり、リソースの効率利用や管理の容易性から注目されている。セキュリティ面では、仮想環境間はＶＭＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｍｏｎｉｔｏｒ）によりリソースが排他制御され、ある仮想環境から他仮想環境に対するアクセスを制御できる。そのため、ある環境におけるマルウェア等による被害が他の環境へ波及しにくい。
【０００４】
また、情報処理端末の動作モードとして、ノーマルモードおよびセキュアモードがある。セキュアモードは、保護アプリケーションのみ実行可能であり、専用保護リソースを有する。このような動作モードを有する情報処理端末では、ノーマルモードからセキュアモードへ移行させ、アクセス制限を行うことが可能である。
【０００５】
また、ソフトウェアの完全性計測を実施するために、情報処理端末の一例である従来のＰＣではＴｒｕｓｔｅｄ Ｂｏｏｔと呼ばれる処理を、ソフトウェアの完全性検証を実施するために、情報処理端末の一例である従来の携帯電話ではＳｅｃｕｒｅ Ｂｏｏｔと呼ばれる処理を行う。
【０００６】
ソフトウェアの完全性計測を実施する従来のＰＣは、内部ＲＯＭ（Ｃｏｒｅ Ｒｏｏｔ ｏｆ Ｔｒｕｓｔ Ｍｅａｓｕｒｅｍｅｎｔ：ＣＲＴＭ）、ＢＩＯＳ、Ｋｅｒｎｅｌの順に起動する。この際、内部ＲＯＭから次に起動するＢＩＯＳのＳＨＡ−１ハッシュ値を計算し、ＴＰＭ（Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ）内部のＰＣＲ（Ｐｌａｔｆｏｒｍ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｒｅｇｉｓｔｅｒ）にハッシュ値を設定し、ＢＩＯＳを起動する。ＢＩＯＳはＫｅｒｎｅｌのハッシュ値を計算し、ＰＣＲにハッシュ値を設定し、Ｋｅｒｎｅｌを起動する。ここで、このハッシュ値は、ＢＩＯＳのハッシュ値にＫｅｒｎｅｌのハッシュ値が依存した形で設定される。Ｋｅｒｎｅｌが起動されると、Ｔｒｕｓｔｅｄ Ｃｏｍｐｏｎｅｎｔ Ｂａｓｅ（ＴＣＢ）が確立する。この一連の流れをＴｒｕｓｔｅｄ Ｂｏｏｔと呼ぶ。
【０００７】
Ｔｒｕｓｔｅｄ Ｂｏｏｔの実施後、ＰＣがネットワークに接続された場合等に、外部サーバがＰＣにＰＣＲ値を要求し、ＰＣはＴＰＭからＴＰＭ固有鍵で署名されたＰＣＲ値を取得して外部サーバに返信する。外部サーバはＰＣＲ値が想定の値と等しい場合に、ネットワーク接続を許可する等の制御を行う。ここで、ＰＣＲは耐タンパ性の高いモジュールであり、高い安全性が確保されるため、結果として端末の完全性を保証できる。
【０００８】
また、ソフトウェアの完全性検証を実施する従来の携帯電話は、Ｔｒｕｓｔｅｄ Ｂｏｏｔと同様の処理によりハッシュ値を計測し、事前に用意したハッシュ期待値と計測したハッシュ値を比較し、一致時のみ対象ソフトウェアを起動する。この流れをＳｅｃｕｒｅ Ｂｏｏｔと呼ぶ。なお、ハッシュ期待値や計測したハッシュ値は、ＭＴＭ（Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ）に格納される。
【０００９】
このように、Ｔｒｕｓｔｅｄ Ｂｏｏｔでは、ハッシュ値をＰＣＲに保存し、外部サーバにより完全性検証を行うが、Ｓｅｃｕｒｅ Ｂｏｏｔでは、端末自身でハッシュ値算出および完全性検証まで実施する。また、ＭＴＭは、携帯電話はユーザの所有物であり、通信オペレータのプラットフォームでもあるため、前者向けのＭＴＭをＭｏｂｉｌｅ Ｌｏｃａｌ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ（ＭＬＴＭ）、後者向けのＭＴＭをＭｏｂｉｌｅ Ｒｅｍｏｔｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ（ＭＲＴＭ）としている。
【００１０】
また、セキュリティポリシに従いアクセス制御される実行領域をドメインと呼ぶ。このドメインは、複数の仮想環境が１つのドメインに属することや、仮想化を用いないドメインを許容する。情報処理端末のＣＰＵにこのようなドメインを複数設定することが可能になっている。なお、ドメインを設定することをドメイン分割とも呼ぶ。
【００１１】
このような情報処理端末内のＣＰＵにドメイン分割を行う技術の一例として、上記動作モードを想定したドメイン分割（例えば、非特許文献１参照）や仮想環境を想定したドメイン分割（例えば、非特許文献２参照）が知られている。
【００１２】
なお、情報処理端末の被害を最小限に抑えるための技術の一例として、秘密キーを用いて生成される生成値と保存されている保存値とを比較し、一致すればプログラムを実行する技術が知られている（例えば、特許文献１参照）。また、ハードウェア固有鍵で暗号化されたプログラムを改ざん検証し、改ざんがなければ、プログラムを復号化して起動することが知られている（例えば、特許文献２参照）。
【００１３】
【非特許文献１】「Ｏｐｅｎ ａｎｄ Ｓｅｃｕｒｅ Ｔｅｒｍｉｎａｌ Ｉｎｉｔｉａｔｉｖｅ ２００６」 ＮＴＴドコモ
【非特許文献２】「ＩＢＭ Ｖｉｒｔｕａｌｉｚｉｎｇ ｔｈｅ Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ ２００６」 ＩＢＭ
【特許文献１】特許第２５６４５９３号公報
【特許文献２】特開２００３−１０８２５７号公報
【発明の開示】
【発明が解決しようとする課題】
【００１４】
しかしながら、上記特許文献では、情報処理端末が複数のＣＰＵ等の演算処理部を備える場合、複数のＣＰＵ等の演算処理部間にまたがってドメイン分割を行うことが想定されていないため、十分な利便性および安全性を考慮したドメイン分割を行うことができない。
【００１５】
本発明は、上記事情を鑑みてなされたものであって、複数の演算処理部を備える場合であっても、十分な利便性および安全性を考慮したドメイン分割を実行可能な情報処理装置および携帯電話装置を提供することを目的とする。
【課題を解決するための手段】
【００１６】
上記目的を達成するために、本発明の情報処理装置は、保護リソースを有しないノーマルモードおよび保護リソースを有するセキュアモードを含む複数の動作モードを有する情報処理装置であって、複数の演算処理部と、所定のセキュリティポリシに基づいてアクセス制御されるプログラムまたはデータを含む実行領域を示すドメインを生成するドメイン制御部と、を有し、前記ドメイン制御部は、前記複数の演算処理部および前記複数の動作モードに基づいて前記ドメインを生成する。
【００１７】
上記構成によれば、複数の演算処理部を備える場合であっても、十分な利便性および安全性を考慮したドメイン分割を実行可能である。
【００１８】
また、本発明の情報処理装置は、前記ドメイン制御部が、更に、前記動作モードの前記保護リソースに基づいてドメインを生成する。
【００１９】
上記構成によれば、複数の演算処理部を備える場合であっても、十分な利便性および安全性を考慮したドメイン分割を実行可能である。
【００２０】
また、本発明の情報処理装置は、前記ドメイン制御部が、更に、実行領域を含む仮想環境に基づいて、ドメインを生成する。
【００２１】
上記構成によれば、複数の演算処理部を備える場合であっても、十分な利便性および安全性を考慮したドメイン分割を実行可能である。
【００２２】
また、本発明の情報処理装置は、前記ドメイン制御部が、同一のセキュリティポリシに基づいてアクセス制御される実行領域を同一のドメインとする
【００２３】
上記構成によれば、信頼できるプラットフォームを構築することができる。
【００２４】
また、本発明の情報処理装置は、前記演算処理部が、複数の実行領域を示すエリアを有し、前記ドメイン制御部が、送信元エリアから送信先エリアへ通信を行う際、前記送信元エリアと前記送信先エリアとが同一のドメインである場合に、通信を許可する。
【００２５】
上記構成によれば、同一ドメイン間でのみ通信を許可するため、信頼できるプラットフォームを構築することができる。
【００２６】
また、本発明の情報処理装置は、前記演算処理部が、複数の実行領域を示すエリアを有し、前記ドメイン制御部が、送信元エリアから送信先エリアへ通信を行う際、前記送信元エリアと前記送信先エリアとが異なるドメインである場合、かつ、前記セキュリティポリシに前記送信元エリアと送信先エリアとの間の通信を許可するための情報が含まれる場合に、通信を許可する。
【００２７】
上記構成によれば、送信元エリアと送信先エリアとが異なるドメインである場合であっても、所定の場合にのみ通信を許可するので、柔軟性のある信頼できるプラットフォームを構築することができる。
【００２８】
また、本発明の情報処理装置は、前記演算処理部が、複数の実行領域を示すエリアを有し、前記ドメイン制御部が、所定の検証処理に失敗したエリアとの間の通信を禁止する。
【００２９】
上記構成によれば、同一ドメインであっても検証処理に失敗している場合には通信を禁止するため、信頼できるプラットフォームを構築することができる。
【００３０】
また、本発明の情報処理装置は、前記演算処理部が、個別に起動可能なプログラムまたはデータを含む実行領域を階層的に有し、所定階層の実行領域が、当該所定階層の実行領域の固有鍵を用いて当該所定階層よりも一段階上位層の実行領域を復号化し、前記一段階上位層の実行領域について所定の検証処理を実行し、前記検証処理に成功した場合、前記一段階上位層の実行領域が有するプログラムを起動する起動時処理を実行する。
【００３１】
上記構成によれば、前階層の固有鍵を用いて復号化等を行うため、信頼できるプラットフォームを構築することができる。
【００３２】
また、本発明の情報処理装置は、前記起動時処理が、最下位層を前記所定階層として最上位層よりも一段階下位層を前記所定階層とするまで一段階ずつ順に実行される。
【００３３】
上記構成によれば、階層毎に段階的に復号化し、さらに前階層の固有鍵を用いてＣｈａｉｎ−ｂｉｎｄｉｎｇをＵｎｂｉｎｄｉｎｇすることで起動時処理を行うため、信頼できるプラットフォームを構築することができる。
【００３４】
また、本発明の情報処理装置は、最上位層の実行領域が、当該最上位層の実行領域の起動後に、当該最上位層の実行領域の固有鍵を用いて所定のデータを復号化し、前記所定のデータについて所定の検証処理を実行し、前記検証処理に成功した場合、前記所定のデータを操作可能とする。
【００３５】
上記構成によれば、例えば所定のデータを含めてＣｈａｉｎ−ｂｉｎｄｉｎｇをＵｎｂｉｎｄｉｎｇすることで起動時処理を行うため、さらに信頼できるプラットフォームを構築することができる。また、復号化ができない限りコピーされたデータがコピー先端末で利用できず、コピー先端末ではデータが復号困難となる。なお、所定のデータとしては、ＩＭＥＩやＳＩＭＬｏｃｋ設定のような事前に決めることができて、かつ全ての端末で同じではないデータが考えられる。
【００３６】
また、本発明の情報処理装置は、前記所定のデータが、当該情報処理装置を識別するための識別データを含むデータである。
【００３７】
上記構成によれば、ＩＭＥＩ等のデータを含めてＣｈａｉｎ−ｂｉｎｄｉｎｇをＵｎｂｉｎｄｉｎｇすることで起動時処理を行うため、さらに信頼できるプラットフォームを構築することができる。また、復号化ができない限りコピーされたＩＭＥＩがコピー先端末で利用できず、コピー先端末ではＩＭＥＩ及び関連ソフトウェアの全てが復号困難となる。
【００３８】
また、本発明の情報処理装置は、所定階層の実行領域が、前記検証処理に失敗した場合、当該所定階層の重要度に基づく復旧処理を実行する。
【００３９】
上記構成によれば、検証失敗時に復旧処理を実行可能であるため、検証失敗時であっても起動時処理を柔軟に継続または停止することが可能である。
【００４０】
また、本発明の情報処理装置は、所定階層の実行領域が、前記復旧処理に失敗した場合、当該所定階層の重要度よりも高い重要度に基づく復旧処理を実行する。
【００４１】
上記構成によれば、復旧失敗時にさらに復旧処理を実行可能であるため、検証や復旧に失敗時であっても起動時処理を柔軟に継続または停止することが可能である。
【００４２】
また、本発明の情報処理装置は、前記復旧処理が、当該情報処理装置の起動停止処理である。
【００４３】
上記構成によれば、情報処理装置を起動停止することで、最も安全に起動時処理を停止ことが可能である。特に携帯電話端末の主要な処理の実行に不可欠なコンポーネントにおいて検証失敗した場合に起動停止すると、高い安全性を確保できる。
【００４４】
また、本発明の情報処理装置は、前記復旧処理が、前記所定階層の実行領域を外部サーバから取得した他の実行領域に差し替える処理である。
【００４５】
上記構成によれば、上記実行領域の差し替えにより、起動時処理を柔軟に継続可能である。
【００４６】
また、本発明の情報処理装置は、前記復旧処理が、非常通報機能のみ利用可能とする処理である。
【００４７】
上記構成によれば、非常通報のみ利用可能とするので、危急の場合に最低限の動作を保証することができるとともに、高い安全性を確保することができる。
【００４８】
また、本発明の情報処理装置は、前記復旧処理が、前記検証処理に失敗した旨を報知部に報知させる処理である。
【００４９】
上記構成によれば、失敗した旨を情報処理装置のユーザやサービス提供者が認識可能であるため、情報処理装置のユーザやサービス提供者が以降の処理を迅速に判断することができる。
【００５０】
また、本発明の情報処理装置は、前記演算処理部が、個別に起動可能なプログラムまたはデータを含む実行領域を階層的に有し、所定階層の実行領域が、当該所定階層の実行領域の固有鍵を用いて当該所定階層よりも一段階下位層の実行領域を暗号化する暗号化処理を実行する。
【００５１】
上記構成によれば、前階層の固有鍵を用いて暗号化を行うため、信頼できるプラットフォームを構築することができる。
【００５２】
また、本発明の情報処理装置は、前記暗号化処理が、最上位層よりも一段階下位層を前記所定階層としてから最下位層を前記所定階層とするまで一段階ずつ順に実行される。
【００５３】
上記構成によれば、階層毎に段階的に暗号化し、さらに前階層の固有鍵を用いてＣｈａｉｎ−ｂｉｎｄｉｎｇを行う暗号化処理を行うため、信頼できるプラットフォームを構築することができる。
【００５４】
また、本発明の情報処理装置は、最上位層の実行領域が、当該最上位層の実行領域の暗号化前に、当該最上位層の実行領域の固有鍵を用いて所定のデータを暗号化する。
【００５５】
上記構成によれば、所定のデータを含めてＣｈａｉｎ−ｂｉｎｄｉｎｇを行う起動時処理を行うため、さらに信頼できるプラットフォームを構築することができる。また、復号化ができない限りコピーされたデータがコピー先端末で利用できず、コピー先端末ではデータが復号困難となる。
【００５６】
また、本発明の情報処理装置は、前記演算処理部が、所定のデータを備える第１の演算処理部と、第２の演算処理部とを有し、前記第２の演算処理部が、前記第１の演算処理部へ前記所定のデータの送信要求を実行し、前記第１の演算処理部と当該第２の演算処理部とを接続する通信路を構成するプログラムを含む実行領域に関する検証処理が成功した場合、前記第１の演算処理部から送信された前記所定のデータを記憶する。
【００５７】
上記構成によれば、例えば情報処理装置の利用時又は定期的に、ＩＭＥＩの送受信を行う２つの演算処理部において、ＩＭＥＩの送受信に関連するプログラムの検証処理を行い、検証処理に成功した場合にのみＩＭＥＩをコピーし記憶することが可能となるため、ＩＭＥＩの完全性を確実に確保することが可能である。
【００５８】
また、本発明の情報処理装置は、前記検証処理の結果を示すセキュアフラグを有し、前記演算処理部が、前記セキュアフラグに基づいて、前記検証処理に失敗したか否かを判定する。
【００５９】
また、本発明の情報処理装置は、前記演算処理部が、前記セキュアフラグに基づく検証処理の結果に応じて、異なる制御を行う。
【００６０】
上記構成によれば、セキュアフラグを用いることで、検証処理の結果を容易に判断することができ、検証処理後の挙動についても決定することが可能である。
【００６１】
また、本発明の携帯電話装置は、アンテナと、操作入力を受け付ける入力部と、前記アンテナを介して無線通信を行うための無線部と、上記いずれかの情報処理装置とを有する。
【００６２】
上記構成によれば、複数のＣＰＵを備える場合であっても、十分な利便性および安全性を考慮したドメイン分割の実行等が可能である。
【発明の効果】
【００６３】
以上説明したように、本発明にかかる情報処理装置および携帯電話装置によれば、複数の演算処理部、複数モードにまたがってドメイン分割できる。また、本発明の完全性検証では、ソフトウェアおよびデータの完全性検証まで行うことが可能である。したがって、プログラムのみに依存したセキュアブートではなく、保護したいデータにも依存させるセキュアブートが実行可能である。
【発明を実施するための最良の形態】
【００６４】
本発明の実施形態における情報処理装置および携帯電話装置について、図面を参照しながら以下に説明する。
【００６５】
本実施形態にかかる情報処理装置としては、ＰＣ、携帯情報端末（ＰＤＡ）、携帯電話端末などが考えられるが、ここでは一例として携帯電話端末について考察する。
【００６６】
図１は、本実施形態にかかる携帯電話端末のハードウェア構成の一例を示す図である。
【００６７】
本実施形態の携帯電話端末は、無線部１１と、Ｃ−ＭＰＵ（Ｍｉｃｒｏ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１２と、ＳＤＲＡＭ等の揮発メモリ１３と、ＭＢ（ＭＰＵ Ｂｒｉｄｇｅ）１４と、ＮＯＲ／ＮＡＮＤ等によって構成される不揮発メモリ１５と、Ａ−ＭＰＵ１６と、内部ＲＯＭ（ＣＲＴＭ）１７と、ＭＲＴＭ（Ｍｏｂｉｌｅ Ｒｅｍｏｔｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ）１８とを有して構成される。また、図示はしないが、操作入力を受け付ける入力部を当然備えてもよい。
【００６８】
無線部１１は、図示しないアンテナを介して外部サーバ等の外部通信装置と通信を行う。
【００６９】
Ａ−ＭＰＵ１６は、アプリケーション用のＭＰＵであり、Ｃ−ＭＰＵ１２は、通信用のＭＰＵである。ＭＰＵは演算処理部の一例であるが、演算処理部として他に、ＣＰＵ、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、複数コアのＣＰＵなどが考えられる。
【００７０】
揮発メモリ１３は、いわゆるメインメモリであり、実行プログラムや各種データを記憶する。
【００７１】
ＭＢ１４は、Ａ−ＭＰＵ１６およびＣ−ＭＰＵ１２間のデータ伝送路であり、Ｃ−ＭＰＵ１２とＡ−ＭＰＵ１６との間の通信を制御する。ＭＢ１４は、ハードウェア的要素とソフトウェア的要素とをあわせ持つ。
【００７２】
不揮発メモリ１５は、携帯電話端末１０の生産工程で記載されたＩＭＥＩや、暗号化コンポーネントを記憶する。
【００７３】
内部ＲＯＭ１７は、各種プログラムを記憶する。
【００７４】
ＭＲＴＭ１８は、高い耐タンパ性を有するモジュールであり、ＰＣＲ（Ｐｌａｔｆｏｒｍ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｒｅｇｉｓｔｅｒ）、Ｓｅｃｕｒｅ Ｆｌａｇ、携帯端末を識別するためのＩＭＥＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｅｑｕｉｐｍｅｎｔ Ｉｄｅｎｔｉｔｙ）、ＭＲＴＭ１８の固有鍵であるＫｅｙ、ハッシュ期待値であるＲＩＭ＿Ｃｅｒｔなどの特に重要度の高い領域やデータを記憶する。
【００７５】
なお、ＲＩＭ＿Ｃｅｒｔについては、ディジタル署名などが施されている場合には、不揮発メモリ１５に保存することも可能である。
【００７６】
また、後述する各階層が有する固有鍵は、平文のまま各階層のプログラムに埋め込む場合と、暗号化してプログラムに埋め込む場合があり得る。後者の場合、各階層の固有鍵はＭＲＴＭ１８の固有鍵または関連する鍵で暗号化する。暗号化された各階層の固有鍵はＭＲＴＭの内部で復号化され、ＭＲＴＭのＲＡＭにキャッシュされる。この場合、Ｋｅｙにはキャッシュされた各階層の固有鍵も含む。
【００７７】
ここで、Ｓｅｃｕｒｅ Ｆｌａｇ（セキュアフラグ）とは、ＭＴＭが内部に保持する保護メモリ領域上に形成されたフラグである。後述する各レイヤにおける完全性検証の結果を保持する。また、セキュアフラグに基づいて、演算処理部は所定の検証処理に失敗したか否かを判定する。また、セキュアフラグに基づく検証処理の結果に応じて、演算処理部は異なる制御を行う。また、セキュアフラグは、更新可能である。本実施形態では、Ｓｅｃｕｒｅ Ｆｌａｇを単にＦｌａｇとも称する。
【００７８】
携帯電話端末１０は、後述するＤＣ（Ｄｏｍａｉｎ Ｃｏｏｒｄｉｎａｔｏｒ）により、所定のセキュリティポリシに基づいてアクセス制御されるプログラムまたはデータを含む実行領域を示すドメインを生成するために、Ｃ−ＭＰＵ１２およびＡ−ＭＰＵ１６の領域を分割する。これをドメイン分割と称する。携帯電話端末１０は、Ｃ−ＭＰＵ１２およびＡ−ＭＰＵ１６などの複数のＭＰＵ等の演算処理部、保護リソースを有しないノーマルモードおよび保護リソースを有するセキュアモードを含む複数の動作モードに基づいて、ドメインを生成する。
【００７９】
なお、複数の演算処理部および複数の動作モードの他に、更に、動作モードの頬リソースに基づいてドメインを生成してもよい。また、更に、実行領域を含む仮想環境に基づいて、ドメインを生成してもよい。また、更に、仮想環境および実環境を含む複数の環境に基づいて、ドメインを生成してもよい。
【００８０】
ここで、ドメインの生成とは、任意に定めた１つまたは複数のエリア（Ａ−ＭＰＵ１６、Ｃ−ＭＰＵ１２、ノーマルモード、セキュアモード、仮想環境）を、ＤＣが、情報やリソースを共有する１つの領域として制御することでドメインを実現することを意味している。
【００８１】
また、上記の保護リソースとは、例えばメモリや暗号エンジンである。また、実行領域とは、各種プログラムやアプリケーションやソフトウェアを実行するための領域や部位を示し、プログラムやデータを含むものである。
【００８２】
図２は、主にＣ−ＭＰＵ１２およびＡ−ＭＰＵ１６の分割されたドメインの一例を示す図である。
【００８３】
図２に示すように、Ｃ−ＭＰＵ１２は、ＯＤ（Ｏｐｅｒａｔｏｒ Ｄｏｍａｉｎ）を有する。Ａ−ＭＰＵ１６は、ノーマルモードおよびセキュアモードにおいて利用される実行領域を有する。また、Ａ−ＭＰＵ１６は、ＯＤ（Ｏｐｅｒａｔｏｒ Ｄｏｍａｉｎ）およびＵＤ（Ｕｓｅｒ Ｄｏｍａｉｎ）を有する。
【００８４】
ＯＤは、携帯電話端末１０のオペレータ向けのプラットフォーム構築とアプリケーション実行が可能な環境（領域）であり、他ドメインから直接アクセスできない。
【００８５】
ＵＤは、携帯電話端末１０の所有者又は所有者へサービスを提供するサードパーティが利用するデータやアプリケーションの実行が可能な環境（実行領域）であり、他ＵＤから許可された場合のみ他ＵＤリソースへのアクセスや他ＵＤとの通信が可能である。
【００８６】
Ｃ−ＭＰＵ１２およびＡ−ＭＰＵ１６は、ノーマルモード、セキュアモードのモード切替によって、ＯＤ、ＵＤを排他的に形成する。ただし、Ｃ−ＭＰＵ１２およびＡ−ＭＰＵ１６は、両モードを排他的に形成せずに両モードを同時に処理可能なＭＰＵであってもよい。
【００８７】
Ａ−ＭＰＵ１６のＯＤは、ＴＣＢ（Ｔｒｕｓｔｅｄ Ｃｏｍｐｏｎｅｎｔ Ｂａｓｅ）、ＴＣＢ以外のノーマルモードのＯＤ、およびＴＣＢ以外のセキュアモードのＯＤを有する。また、Ｃ−ＭＰＵ１２のＯＤは、ＴＣＢ以外のノーマルモードのＯＤを有する。
【００８８】
Ａ−ＭＰＵ１６のＯＤに含まれるＴＣＢは、ＨＷ（Ｈａｒｄｗａｒｅ） Ｐｌａｔｆｏｒｍ２１、ＩＰＬ（Ｉｎｉｔｉａｌ Ｐｒｏｇｒａｍ Ｌｏａｄｅｒ）２２、ＤＣ（Ｄｏｍａｉｎ Ｃｏｏｒｄｉｎａｔｏｒ）２３、ＭＳ（Ｍｏｄｅ Ｓｅｌｅｃｔｏｒ）２４、ＶＭＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｍｏｎｉｔｏｒ）２５、ＭＢ（ＭＰＵ Ｂｒｉｄｇｅ）１４、およびＭＲＴＭ（Ｍｏｂｉｌｅ Ｒｅｍｏｔｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ）１８を有する。なお、ＴＣＢは概念的な区分けであるため、ＭＲＴＭ１８やＭＢ１４など、ＭＰＵ内に含まれない構成要素についても、ＴＣＢに含まれるものとして扱うことが可能である。
【００８９】
ＨＷ Ｐｌａｔｆｏｒｍ２１は、Ａ−ＭＰＵ１６自体が備える暗号処理機能、ＨＷ固有鍵、モード切り替え機能の総称である。また、ＨＷ Ｐｌａｔｆｏｒｍ２１は、内部ＲＯＭ１７（ＣＲＴＭ）１７、ＨＷ固有鍵、ＭＣ（Ｍｏｄｅ Ｃｏｎｔｏｌｌｅｒ）を有している。
【００９０】
ここで、ＭＣは、ＭＳと同様にモード切り替え機能を有する。また、ＭＣは、ＭＢ１４と同様に、ハードウェア的要素とソフトウェア的要素をあわせ持つ。
【００９１】
ＩＰＬ２２は、外部ＲＯＭ（図示せず）において最初に実行されるプログラムであり、各種のハードウェア設定やＫｅｒｎｅｌの起動を司る。
【００９２】
ＤＣ２３は、ドメイン毎に定義されるセキュリティポリシに従いＶＭＭ２５とＭＳ２４とＭＢを統合的に制御し、携帯電話端末１内の異なる複数エリアにまたがるドメインを形成する。なお、ＤＣ２３は、ドメイン制御部としての機能を有する。
【００９３】
ＭＳ２４は、ノーマルモードおよびセキュアモードのモード切り替え機構であり、モード間の排他制御を行う。
【００９４】
ＶＭＭ２５は、ハードウェアの仮想化層であり、仮想環境間の排他制御を行う。
【００９５】
Ａ−ＭＰＵ１６およびＣ−ＭＰＵ１２において、ＴＣＢ以外のセキュアモードのＯＤおよびＵＤは、ＯＳ（セキュアモード用ＯＳ、Ａ−ＯＳ、もしくはＣ−ＯＳ）およびアプリ（セキュアモード用アプリ、Ａ−ａｐｐ、もしくはＣ−Ａｐｐ）を有する。
【００９６】
さらに、Ａ−ＭＰＵ１６およびＣ−ＭＰＵ１２において、各種データを格納する領域として、ＭＴＭ（Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ）の一例でありＯＤに含まれるＶｉｒｔｕａｌｉｚｉｎｇ ＭＲＴＭ（Ａ−ｖＭＲＴＭもしくはＣ−ｖＭＲＴＭ）や、ＵＤに含まれるＶｉｒｔｕａｌｉｚｉｎｇ ＭＬＴＭ（Ａ−ｖＬＴＭ）を有する。
【００９７】
ｖＭＲＴＭは、Ａ−ＭＰＵ１６のノーマルモードで実現されるＵＤで利用するＭＬＴＭであり、その機能はＭＲＴＭ１８を用いることで実現される。
【００９８】
ｖＭＬＴＭは、Ｃ−ＭＰＵ１２またはＡ−ＭＰＵ１６のノーマルモードで実現されるＯＤからＭＲＴＭ１８にアクセスするための仮想ドライバである。
【００９９】
なお、ドメイン生成の際には、同一のセキュリティポリシに基づいてアクセス制御される実行領域は、同一のドメインとして生成される。例えば図２では、Ａ−ＭＰＵ１６のノーマルモードのＯＤとＡ−ＭＰＵ１６のセキュアモードのＯＤとＣ−ＭＰＵ１２のＯＤ、Ａ−ＭＰＵ１６のノーマルモードのＵＤ１とセキュアモード）のＵＤ１、Ａ−ＭＰＵ１６のノーマルモードのＵＤ２とセキュアモードのＵＤ２が、それぞれ同一のドメインとして生成される。
【０１００】
次に、携帯電話端末１０の電源ＯＮから各実行領域による実行が可能な状態となるまでの一連の処理の流れ（Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅや起動時処理とも称する）の一例について説明する。
【０１０１】
Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅをさらに詳細な処理に分けると、ＴＣＢを確立するＳｅｃｕｒｅ Ｂｏｏｔ０、複数ＭＰＵをまたいだＯＤを確立するＳｅｃｕｒｅ Ｂｏｏｔ１および１’、ＵＤを確立するＳｅｃｕｒｅ Ｂｏｏｔ２の３レイヤに分けられる。
【０１０２】
Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅでは、携帯電話プラットフォーム（ここでは、主にＡ−ＭＰＵ１６およびＣ−ＭＰＵ１２である）を１つのＯＤと複数ＵＤにドメイン分割する。ＯＤのドメイン分割をＯＤ確立、ＵＤのドメイン分割をＵＤ確立とも称する。
【０１０３】
ＯＤ確立では、内部ＲＯＭ（ＣＲＴＭ）１７とＩＰＬ２２とＤＣ２３を起動するＳｅｃｕｒｅ Ｂｏｏｔ０と、Ａ−ＭＰＵ１６のＯＤのノーマルモードのＯＳ／アプリ／データ（ＩＭＥＩなど）までを起動するＳｅｃｕｒｅ Ｂｏｏｔ１と、Ｃ−ＭＰＵ１６のＯＤのノーマルモードのＯＳ／アプリ／データまでを起動するＳｅｃｕｒｅＢｏｏｔ１’と、の３つのレイヤに分けて処理が行われる。
【０１０４】
ＵＤ確立では、Ａ−ＭＰＵ ＵＤのノーマルモードのＯＳ／アプリ／データまでを起動するＳｅｃｕｒｅ Ｂｏｏｔ２の１つのレイヤで処理が行われる。ＯＤ確立後にＵＤ確立を実行する。
【０１０５】
そして、後述するが、ＯＤ確立およびＵＤ確立では、予め定めたレイヤ毎の重要度に応じ、完全性検証に失敗した場合の挙動を定める。
【０１０６】
Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅでは、内部ＲＯＭ１７、ＩＰＬ２２、ＤＣ２３などの各コンポーネントやデータ（ＩＭＥＩ等）に対して、ソフトウェア同様の完全性検証、検証失敗時処理の実行、およびＳｅｃｕｒｅ Ｆｌａｇを用いた処理結果に依存した検証／復号処理を実行する。
【０１０７】
また、Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅ時に起動を実行するコンポーネントは、起動対象コンポーネントを自身の固有鍵で復号後に完全性を検証（計測）する。完全性検証に成功した場合、つまり完全性が保持されていると判定された場合には、起動対象コンポーネントの起動を実施する。一方、完全性検証に失敗した場合には、起動対象コンポーネントの起動を禁止する。なお、起動を実行するコンポーネントは、暗号化された起動対象コンポーネントをハッシュの対象とすれば、完全性検証を行なった後に復号化することも可能である。
【０１０８】
携帯電話端末１０では、特に、移動機固有番号であるＩＭＥＩとＩＭＥＩを扱うソフトウェアの完全性を保護することが求められている。携帯電話網では、ＩＭＥＩを用いて網にアクセスする端末をアクセス制御することで盗難端末の無効化等を実現するため、ＩＭＥＩの完全性が必要不可欠である。さらに、ＰＣにも携帯電話の通信機能が備えられるようになり、今後はＰＣでも同様にＩＭＥＩ保護が求められる可能性もあるため、ソフトウェア同様にＩＭＥＩ等のデータについても改ざん検証を行う本実施形態におけるＢｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅは、大変有用である。
【０１０９】
ここで、上記のコンポーネントを暗号化する方法の一例について説明する。
【０１１０】
携帯電話端末１０は、製造時に、アプリ固有鍵でデータを暗号化、アプリをＯＳ固有鍵で暗号化する様に、起動を実行するコンポーネントの固有鍵で起動対象コンポーネントの暗号化を繰返し、暗号化コンポーネントを不揮発メモリ１５に保存している。ルートの鍵はＨＷ固有鍵とする。このような暗号化方法をＣｈａｉｎ−ｂｉｎｄｉｎｇとも称する。
【０１１１】
このように、Ａ−ＭＰＵ１６やＣ−ＭＰＵ１２が、個別に起動可能な複数のコンポーネント（プログラムを含む実行領域の一例）を階層的に有し、所定階層のコンポーネントが、所定階層のコンポーネントの固有鍵を用いて所定階層よりも一段階上位層のコンポーネントを暗号化する暗号化処理を実行する。また、上記暗号化処理は、最上位層よりも一段階下位層を所定階層としてから最下位層を所定階層とするまで一段階ずつ順に実行されることも可能である。これにより暗号化されたコンポーネントが不揮発メモリ１５に保存されている。
【０１１２】
また、上記コンポーネントが、所定階層の実行領域の固有鍵を用いて所定階層よりも一段階下位層の実行領域が暗号化される暗号化処理が、最上位層を所定階層としてから最下位層を所定階層とするまで一段階ずつ順に実行された後、Ａ−ＭＰＵ１６やＣ−ＭＰＵ１２に記憶されるようにしてもよい。
【０１１３】
また、最上位層の実行領域が、最上位層の実行領域の暗号化前に、ＩＭＥＩ等を含むデータを用いて暗号化されるようにすることも可能である。
【０１１４】
図３〜図６は、携帯電話端末１０が実施するＢｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅの一例を示すフローチャートである。ここでは、特に、完全性検証について示している。携帯電話端末１０は、Ｓｅｃｕｒｅ Ｂｏｏｔ０の実施後に、Ｓｅｃｕｒｅ Ｂｏｏｔ１／１’／２を実施する。
【０１１５】
まず、Ｓｅｃｕｒｅ Ｂｏｏｔ０において、内部ＲＯＭ１７は、自身のハッシュ値を計算してＰＣＲを設定し、Ｓｅｃｕｒｅ Ｆｌａｇ０をＯＮに設定する。続いて、Ｆｌａｇ０＝ＯＮなら、内部ＲＯＭ１７は、ＩＰＬ２２をＨＷ固有鍵とＭＲＴＭ固有鍵で復号してハッシュ値を計算し、ハッシュ期待値であるＲＩＭ＿Ｃｅｒｔと上記計算したハッシュ値とを比較することで、完全性を検証する。検証成功時には、内部ＲＯＭ１７が、ＭＲＴＭ１８へＩＰＬ２２のハッシュ値をＰＣＲに設定し、Ｓｅｃｕｒｅ Ｆｌａｇ１をＯＮに設定後、ＩＰＬ２２を起動する。一方、検証失敗時には、内部ＲＯＭ１６は、起動を停止する（ステップＳ１）。なお、以降の完全性検証においても、計算したハッシュ値はＲＩＭ＿Ｃｅｒｔとの比較が行われる。
【０１１６】
Ｆｌａｇ１＝ＯＮなら、ＩＰＬ２２は、ＤＣ２３をＭＲＴＭ固有鍵で復号して完全性を検証する。検証成功時には、ＩＰＬ２２は、ＭＲＴＭ１８へＤＣ２３のハッシュ値をＰＣＲに設定、Ｓｅｃｕｒｅ Ｆｌａｇ２をＯＮに設定後、ＤＣ２３を起動する。一方、検証失敗時には、ＩＰＬ２２は、起動を停止する（ステップＳ２）。
【０１１７】
なお、ここでは、ＤＣ２３がＶＭＭ２５、ＭＳ２４、ＭＢ１４を包含しており、ＤＣ２３の改ざん検証時には、ＶＭＭ２５、ＭＳ２４、ＭＢ１４の順に段階的に改ざん検証が行なわれる。これは、ＤＣ２３のバイナリファイル内にＶＭＭ２５、ＭＳ２４４、ＭＢ１４が含まれており、ＤＣ２３を検証すると一緒に検証されるためである。なお、ＤＣ２３がＶＭＭ２５、ＭＳ２４、ＭＢ１４を包含せずに、ＤＣ２３の改ざん検証に成功した場合に、ＶＭＭ２５、ＭＳ２４、ＭＢ１４の順に検証および起動を行なうようにしてもよい。
【０１１８】
なお、Ｓｅｃｕｒｅ Ｂｏｏｔ０の実装方法として、 完全性検証及び検証後の対象ソフトウェアの起動まで含めた全てをセキュアモードで処理する方法と、 完全性検証のみをセキュアモードで処理する方法が考えられる。いずれを採用するかは各プラットフォームのＭＳ２４の実装に応じて決定すべきである。
【０１１９】
ＤＣ２３の完全性検証後、携帯電話端末１０はＳｅｃｕｒｅ Ｂｏｏｔ１を実施する。
【０１２０】
Ｓｅｃｕｒｅ Ｂｏｏｔ１において、まず、Ｆｌａｇ２＝ＯＮなら、ＤＣ２３は、Ａ−ＯＳ０をＤＣ固有鍵で復号して完全性を検証する。検証成功時には、ＤＣ２３は、ＭＲＴＭ１８へＡ−ＯＳ０のハッシュ値をＰＣＲに設定し、Ｓｅｃｕｒｅ Ｆｌａｇ３をＯＮに設定後、Ａ−ＯＳ０を起動する。一方、検証失敗時には、ＤＣ２３が、携帯電話端末１０をリカバリーモードへ遷移させる（ステップＳ３）。
【０１２１】
続いて、Ｆｌａｇ３＝ＯＮなら、Ａ−ＯＳ０は、Ａ−Ａｐｐ０をＡ−ｖＭＲＴＭ０固有鍵で復号して完全性を検証する。検証成功時には、Ａ−ＯＳ０は、Ａ−ｖＭＲＴＭ０へＡ−Ａｐｐ０のハッシュ値をＰＣＲに設定し、Ｓｅｃｕｒｅ Ｆｌａｇ４をＯＮに設定後、Ａ−Ａｐｐ０を起動する。一方、検証失敗時には、Ａ−ＯＳ０が、携帯電話端末１０をリカバリーモードへ遷移させる（ステップＳ４）。
【０１２２】
続いて、Ｆｌａｇ４＝ＯＮなら、Ａ−Ａｐｐ０は、Ａ−Ｄａｔａ０（ＩＭＥＩ等）をＣ−Ａｐｐ０固有鍵で復号して完全性を検証する。検証成功時には、Ａ−Ａｐｐ０は、Ａ−ｖＭＲＴＭ０へＡ−Ｄａｔａ０のハッシュ値をＰＣＲに設定し、Ｓｅｃｕｒｅ Ｆｌａｇ５をＯＮに設定後、Ａ−Ｄａｔａ０をＡ−ｖＭＲＴＭ０にキャッシュする。一方、検証失敗時には、Ａ−Ａｐｐ０が、携帯電話端末１０をリカバリーモードへ遷移させる（ステップＳ５）。
【０１２３】
ＤＣ２３の完全性検証後、携帯電話端末１０はＳｅｃｕｒｅ Ｂｏｏｔ１’も実施する。Ｓｅｃｕｒｅ Ｂｏｏｔ１’の実施はＳｅｃｕｒｅ Ｂｏｏｔ１の実施と並行することが可能である。
【０１２４】
Ｓｅｃｕｒｅ Ｂｏｏｔ１’において、まず、Ｆｌａｇ２＝ＯＮなら、ＤＣ２３は、Ｃ−ＯＳ０をＤＣ固有鍵で復号して完全性を検証する。検証成功時には、ＤＣ２３は、ＭＲＴＭ１８へＣ−ＯＳ０のハッシュ値をＰＣＲに設定し、Ｓｅｃｕｒｅ Ｆｌａｇ３’をＯＮに設定後、Ｃ−ＯＳ０／Ｃ−Ａｐｐ０／Ｃ−Ｄａｔａ０をＣ−ＭＰＵ１２へ転送する。一方、検証失敗時には、Ｃ−ＯＳ０が、携帯電話端末１０をリカバリーモードへ遷移させる（ステップＳ３’）。
【０１２５】
続いて、Ｆｌａｇ３’＝ＯＮなら、ＭＢ１４は、Ｃ−ＯＳ０を起動し、Ｃ−ｖＭＲＴＭ０とＡ−ｖＭＲＴＭ０を用いて、Ｃ−ＯＳ０とＡ−ＯＳ０との間でＳＡＣ（Ｓｅｃｕｒｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｃｈａｎｎｅｌ）を確立する。ＳＡＣは、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）にように相互認証と通信路の暗号化を実現した通信路である。ＳＡＣ確立成功後、Ｃ−ＯＳ０は、Ｃ−Ａｐｐ０をＣ−ｖＭＲＴＭ０固有鍵で復号して完全性を検証する。検証成功時には、Ｃ−ＯＳ０は、Ｃ−ｖＭＲＴＭ０へＣ−Ａｐｐ０のハッシュ値をＰＣＲに設定し、Ｓｅｃｕｒｅ Ｆｌａｇ４’をＯＮに設定後、Ｃ−Ａｐｐ０を起動する。一方、検証失敗時には、Ｃ−ＯＳ０が、携帯電話端末１０をリカバリーモードへ遷移させる（ステップＳ４’）。
【０１２６】
続いて、Ｆｌａｇ４’＝ＯＮなら、Ｃ−Ａｐｐ０は、Ｃ−Ｄａｔａ０をＣ−Ａｐｐ０固有鍵で復号して完全性を検証する。検証成功時には、Ｃ−Ａｐｐ０は、Ｃ−ｖＭＲＴＭ０へＡ−Ｄａｔａ０のハッシュ値をＰＣＲに設定し、Ｓｅｃｕｒｅ Ｆｌａｇ５をＯＮに設定後、Ａ−Ｄａｔａ０をＡ−ｖＭＲＴＭ０にキャッシュする。一方、検証失敗時には、Ｃ−Ａｐｐ０が携帯電話端末１０をリカバリーモードへ遷移させる。
【０１２７】
ここでは、Ｃ−ＭＰＵ１２側で完全性検証を行うＳｅｃｕｒｅ Ｂｏｏｔ１’の実施方法を示したが、Ａ−ＭＰＵ１６側のＤＣ２３により、Ｃ−ＯＳ０のみではなく、Ｃ−Ａｐｐ０／Ｃ−Ｄａｔａ０も復号／完全性検証してからＣ−ＭＰＵ１２へ転送することも可能である。
【０１２８】
ＤＣ２３の完全性検証後、携帯電話端末１０はＳｅｃｕｒｅ Ｂｏｏｔ２を実施する。Ｓｅｃｕｒｅ Ｂｏｏｔ２の実施はＳｅｃｕｒｅ Ｂｏｏｔ１および１’の実施と並行することが可能である。
【０１２９】
Ｓｅｃｕｒｅ Ｂｏｏｔ２において、まず、Ｆｌａｇ２＝ＯＮ、Ｆｌａｇ５＝ＯＮ、かつＦｌａｇ５’＝ＯＮなら、ＤＣ２３は、Ａ−ＯＳ１をＤＣ固有鍵で復号して完全性を検証する。検証成功時には、ＤＣ２３は、ＭＲＴＭ１８へＡ−ＯＳ１のハッシュ値をＰＣＲに設定し、Ｓｅｃｕｒｅ Ｆｌａｇ６をＯＮに設定後、Ａ−ＯＳ１を起動する。一方、検証失敗時には、ＤＣ２３が携帯電話端末１０をリポートモードへ遷移させる（ステップＳ６）。
【０１３０】
続いて、Ｆｌａｇ６＝ＯＮなら、Ａ−ＯＳ１はＡ−Ａｐｐ１をＡ−ｖＭＲＴＭ１固有鍵で復号して完全性を検証する。検証成功時には、Ａ−ＯＳ１は、Ａ−ｖＭＬＴＭ１へＡ−Ａｐｐ１のハッシュ値をＰＣＲに設定し、Ｓｅｃｕｒｅ Ｆｌａｇ７をＯＮに設定後、Ａ−Ａｐｐ１を起動する。一方、検証失敗時には、Ａ−ＯＳ１が携帯電話端末１０をリポートモードへ遷移させる（ステップＳ７）。
【０１３１】
続いて、Ｆｌａｇ７＝ＯＮなら、Ａ−Ａｐｐ１は、Ａ−Ｄａｔａ１をＡ−Ａｐｐ１固有鍵で復号して完全性を検証する。検証成功時には、Ａ−Ａｐｐ１は、Ａ−ｖＭＬＴＭ１へＡ−Ｄａｔａ１のハッシュ値をＰＣＲに設定し、Ｓｅｃｕｒｅ Ｆｌａｇ８をＯＮに設定後、Ａ−Ｄａｔａ１をＡ−ｖＭＬＴＭ１にキャッシュする。検証失敗時には、Ａ−Ａｐｐ１が、リポートモードへ遷移させる（ステップＳ８）。
【０１３２】
なお、図２のようにＵＤが複数存在する場合、Ａ−ＭＰＵ１６のＵＤ２以降の確立方法はＵＤ１と同じである。
【０１３３】
また、セキュアモードにおけるＯＤ／ＵＤの確立は、セキュアモード遷移時に実行される。確立の内容は、直接ＭＲＴＭ１８にアクセスすることを除いて、ノーマルモードの場合と同様である。なお、図３では、ノーマルモードを想定している。
【０１３４】
セキュアモードで実行される保護ソフトウェアは、暗号化された状態で不揮発メモリ１５に保存されており、実行直前にＨＷ Ｐｌａｔｆｏｒｍ２１により復号及び完全性の検証が行われ、成功時のみ実行が許可される。
【０１３５】
このように、携帯電話端末１０は、Ａ−ＭＰＵ１６やＣ−ＭＰＵ１２が、個別に起動可能な複数のコンポーネント（プログラムを含む実行領域の一例）を階層的に有し、所定階層のコンポーネントが、所定階層のコンポーネントの固有鍵を用いて所定階層よりも一段階上位層のコンポーネントを復号化し、一段階上位層のコンポーネントについて所定の検証処理を実行し、検証処理に成功した場合、上記一段階上位層のコンポーネントを起動する起動時処理を実行する。また、上記起動時処理が、最下位層を上記所定階層としてから最上位層よりも一段階下位層を上記所定階層とするまで一段階ずつ順に実行されることが可能である。
【０１３６】
さらに、最上位層の実行領域が、最上位層の実行領域の起動後に、最上位層の実行領域の固有鍵を用いてＩＭＥＩ等のデータを復号化し、所定の検証処理を実行し、上記検証処理に成功した場合、ＩＭＥＩ等のデータを操作可能とする。
【０１３７】
次に、Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅにおける検証失敗時の挙動の一例について説明する。
【０１３８】
本実施形態では、検証失敗時に次の５つのパターンを想定している。携帯電話端末１０は、Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅにおけるレイヤの重要度に応じて、検証失敗時の挙動を変更することが可能である。つまり、つまり所定階層の重要度に基づく復旧処理を実行することが可能である。
【０１３９】
（１）無視して起動を続ける。
（２）起動を停止する。
（３）検証に失敗したコンポーネントをリポジトリサーバ（外部サーバの一例）からダウンロードした正しいコンポーネントに差し替える（リカバリーモードとも称する）。
（４）１１０番通報等の非常時通報機能のみ利用できる（エマージェンシーモードとも称する）。
（５）失敗をユーザに通知する（リポートモードとも称する）。この通知は、図示しない報知部によって行われる。
【０１４０】
リカバリーモードで処理が失敗した場合は、エマージェンシーモードへ遷移させる。ただし、ＩＭＥＩ及びＩＭＥＩ関連ソフトウェア等の通信に必要となるコンポーネントの完全性が保証されている場合のみ遷移させる。ＵＤでの失敗時はユーザ（携帯電話端末１０の所有者又はサービス提供者）に失敗内容を通知するリポートモードに遷移させ、ユーザにそれ以降の処理を判断させる。
【０１４１】
また、Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅにおけるレイヤの重要度に応じて検証失敗時の挙動を変更する以外に、レイヤの重要度に応じて完全性検証のレベル自体を変更することも可能である。例えば、起動を高速化するため、重要度が低いほどコンポーネントの検証範囲を狭くする、あるいは検証される確率を低くする。最低限、ある期間内には全コンポーネントの全範囲が検証されるよう実装する必要はあるが、重要度の低いレイヤの検証処理の一部を省略することで高速化することも可能である。
【０１４２】
さらに、復旧処理に失敗した場合には、復旧処理に失敗した所定階層（コンポーネント）よりも当該所定階層の重要度よりも高い重要度に基づく復旧処理を行うようにしてもよい。
【０１４３】
図３では、検証失敗時には、Ｓｅｃｕｒｅ Ｂｏｏｔ１および１’においてはリカバリーモード、Ｓｅｃｕｒｅ Ｂｏｏｔ２においてはリポートモードへ遷移することを説明しているが、各レイヤの重要度等に応じて、リカバリーモード、エマージェンシーモード、リポートモード、起動停止のいずれかに遷移すればよい。ただし、Ｓｅｃｕｒｅ Ｂｏｏｔ０においては、非常に重要度が高いため、検証失敗時には起動停止を行うようにする。また、リポートモードでは、例えば、ユーザインタフェース（ＵＩ）でユーザに向けてメッセージの表示等を行ったり、サービス提供サーバなどの外部サーバに対してメッセージを送信したりすることが可能である。
【０１４４】
次に、ＤＣ２３によるアクセス制御の一例について説明する。
【０１４５】
図２に示したように、携帯電話端末１におけるドメインは、Ａ−ＭＰＵ１６のＴＣＢ、Ａ−ＭＰＵ１６のノーマルモード０の仮想環境０／１／２、Ａ−ＭＰＵ１６のセキュアモード０／１／２、Ｃ−ＭＰＵ１２のノーマルモード０の１つ又は複数のエリアから構成される。例えば、ＯＤは、Ａ−ＭＰＵ１６のＴＣＢ、Ａ−ＭＰＵ１６のノーマルモード０の仮想環境０、A−ＭＰＵ１６のセキュアモード０、Ｃ−ＭＰＵ１２のノーマルモード０の複数エリアから構成される。ただし、ドメインの構成は上記構成に限られない。
【０１４６】
ここで、ＤＣ２３の役割の１つは、これらのＯＤに所属する複数エリア内において情報とリソースをフレキシブルに共有し、他ドメインへの情報流出とリソースを制御することにある。ＤＣ２３は、複数ＭＰＵを制御するＭＢ、複数の動作モードを制御するＭＳ２４、複数仮想環境を制御するＶＭＭ２５を監視し、ＯＤに対応するベースポリシとＵＤに対応するドメインポリシに従い、情報およびリソースアクセスを制御する。なお、ベースポリシおよびドメインポリシは、セキュリティポリシの一例である。
【０１４７】
ここで、エリアとは、Ａ−ＭＰＵ１６のノーマルモードのＯＤやＵＤ１やＵＤ２、Ａ−ＭＰＵ１６のセキュアモードのＯＤやＵＤ１やＵＤ２、Ｃ−ＭＰＵ１２のＯＤなどの実行領域を示すものである。
【０１４８】
携帯電話端末１０は、一例として、以下のようにＤＣ２３によるドメイン間情報流通の制御を行う。
【０１４９】
・あらかじめ、例えばＤＣ２３によって、エリアから他のエリアへ情報は必ずＤＣ２３を経由するように指定する。
・ＤＣ２３は、送信元エリアの属するドメインと送信先エリアの属するドメインが一致する場合のみ通信を許可する（ベースポリシ）。
・ＤＣ２３は、送信元エリアの属するドメインに予め設定されたドメインポリシが許可する場合は送信先エリアの属するドメインが異なる場合も通信を許可する。
・ＤＣ２３は、Ｓｅｃｕｒｅ Ｆｌａｇを確認し、ＦｌａｇがＯＦＦの部分があるエリアからの通信およびＯＦＦの部分があるエリアへの通信については禁止する。つまり、所定の検証処理に失敗したエリアとの間の通信を禁止する。
【０１５０】
また、携帯電話端末１０は、一例として、以下のようにＤＣ２３によるドメイン間リソース共有の制御を行う。図７にドメイン間リソース共有の一例を示す図である。
【０１５１】
・あらかじめ、あるエリアからＭＲＴＭ１８にアクセスする場合は、必ずＤＣ２３を経由するように指定する。
・ＭＲＴＭ１８はＳｅｃｕｒｅ Ｆｌａｇ０／１／２／３／６、Ａ−ｖＭＲＴＭ０はＳｅｃｕｒｅ Ｆｌａｇ４／５、Ｃ−ｖＭＲＴＭ０はＳｅｃｕｒｅ Ｆｌａｇ４’／５’、Ａ−ｖＭＬＴＭ１はＳｅｃｕｒｅ Ｆｌａｇ７／８を管理し、ＤＣ２３は所属するドメインからのアクセスしか許可しない（ベースポリシ）。
・セキュアモードにおけるエリアからは、直接ＤＣ２３を経由してＭＲＴＭ１８へアクセスすることを許可とする。図７では、一例としてＯＳからアクセスすることを示している。
・ノーマルモードにおけるエリアからは、仮想ＭＴＭ（ｖＭＲＴＭ又はｖＭＬＴＭ）経由以外のアクセスを許可しない。仮想ＭＴＭ経由の場合、ＤＣ２３は、ＭＲＴＭ１８のＰＣＲ／Ｓｅｃｕｒｅ ＦｌａｇをＲｅａｄ Ｏｎｌｙ（読み取り専用）に制御し、かつＭＲＴＭ１８以外のＰＣＲ／Ｓｅｃｕｒｅ Ｆｌａｇは参照も許可しない（ベースポリシ）。
・ＤＣ２３は、アクセス先エリアの属するドメインに予め設定されたドメインポリシが許可する場合には、アクセス元エリアの属するドメインが異なる場合もＰＣＲ／Ｓｅｃｕｒｅ Ｆｌａｇ参照を許可する。
【０１５２】
次に、Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅ後における完全性検証の一例について説明する。
【０１５３】
Ｃ−ＭＰＵ１２においてＩＭＥＩを利用する場合、ＳＡＣ経由でＩＭＥＩをロードしてＣ−ｖＭＲＴＭ０へキャッシュする。ただし、利用時又は定期的にＩＭＥＩおよびＩＭＥＩに関連するソフトウェアの完全性検証が必要と考えられる。この完全性検証は、ＩＭＥＩをＡ−ｖＭＲＴＭ０からリロードする際の流通経路となるソフトウェアをデータドリブンで検証することで、最小限の範囲を利用直前に検証するものである。なお、ＩＭＥＩをリロードする毎に完全性検証が発生する為、実装時はＣ−ｖＭＲＴＭ０のキャッシュの有効期間を定め、許容される負荷の範囲でリロードするべきである。
【０１５４】
具体的には、ＩＭＥＩ等のデータにＶｅｒｉｆｉｃａｔｉｏｎ Ｔａｇを設け、データ送信元コンポーネントはデータ送信先コンポーネントの完全性を実施し、検証成功時のみ送信することで実現できる。検証成功か否は、Ｖｅｒｉｆｉｃａｔｉｏｎ Ｔａｇ＝ＯＮか否かを判断する。また、リロード時も各コンポーネントにおける完全性検証結果をＭＴＭのＳｅｃｕｒｅ Ｆｌａｇに設定することで、事前の検証が失敗している場合には、各コンポーネントからＩＭＥＩをＣ−ＭＰＵ１２へ出力させない。なお、Ｖｅｒｉｆｉｃａｔｉｏｎ ＴａｇはＩＭＥＩ等のデータとともにＭＴＭに保存可能である。
【０１５５】
図８は、Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅ後における完全性検証の一例を示すフローチャートである。
【０１５６】
まず、Ｃ−ＭＰＵ１２は、Ｃ−ｖＭＲＴＭ０にキャッシュしているＩＭＥＩの有効期間が過ぎた場合などに、Ｃ−Ａｐｐ０がＡ−Ａｐｐ０へＩＭＥＩを要求する（ステップＳ１１）。
【０１５７】
続いて、Ａ−ＭＰＵ１６は、Ａ−Ａｐｐ０がＡ−ｖＭＲＴＭ０からＩＭＥＩを読み出す（ステップＳ１２）。なお、ＩＭＥＩはＡ−ｖＭＲＴＭ０又はＡ−ｖＭＲＴＭ経由でＭＲＴＭ１８にキャッシュされているとする。
【０１５８】
続いて、Ａ−ＭＰＵ１６は、Ｖｅｒｉｆｉｃａｔｉｏｎ ＴａｇをＯＮに設定してＩＭＥＩメッセージをＣ−Ａｐｐ０宛に送る（ステップＳ１３）。
【０１５９】
続いて、Ａ−ＭＰＵ１６またはＣ−ＭＰＵ１２は、ＩＭＥＩメッセージを受信した通信経路上のプログラム（ＰＧ）（Ａ−ＯＳ０、ＤＣ２３、またはＣ−ＯＳ０に含まれる）が、Ｖｅｒｉｆｉｃａｔｉｏｎ＿Ｔａｇ＝ＯＮか否か判定する。
【０１６０】
Ｖｅｒｉｆｉｃａｔｉｏｎ＿Ｔａｇ＝ＯＮの場合、Ａ−ＭＰＵ１６およびＣ−ＭＰＵ１２は、ＩＭＥＩを送ってきた送り元プログラムに対応するＳｅｃｕｒｅ ＦｌａｇがＯＮであるか否かを判定する（ステップＳ１５）。
【０１６１】
Ｓｅｃｕｒｅ ＦｌａｇがＯＮである場合、Ａ−ＭＰＵ１６およびＣ−ＭＰＵ１２は、送り先プログラムの改ざん検証を実行し（ステップＳ１６）、送り先プログラム（例えばＣ−ＯＳ０）の改ざんがないか判定する（ステップＳ１７）。
【０１６２】
送り先プログラムの改ざんがないと判定された場合、Ａ−ＭＰＵ２６およびＣ−ＭＰＵ２２は、送り先プログラムに対応するＳｅｃｕｒｅ ＦｌａｇをＯＮし、ＩＭＥＩメッセージを送り先プログラムに送信する（ステップＳ１８）。
【０１６３】
なお、ステップＳ１４〜Ｓ１８は、通信経路上のプログラム数だけ繰り返される。
【０１６４】
続いて、Ａ−ＭＰＵ１６およびＣ−ＭＰＵ１２は、例えばステップＳ１３に示すように、Ｃ−Ａｐｐ０へＩＭＥＩメッセージを送信したか否かを判定する。ＩＭＥＩメッセージを送信していない場合、ステップＳ１３の直前に戻る。
【０１６５】
ＩＭＥＩメッセージを送信されると、Ｃ−ＭＰＵ１２は、Ｃ−Ａｐｐ０がＩＭＥＩメッセージを受信する（ステップＳ２０）。
【０１６６】
続いて、Ｃ−ＭＰＵ１２は、送り元プログラムのＳｅｃｕｒｅ ＦｌａｇがＯＮであるか否かを判定する（ステップＳ２１）。
【０１６７】
送り元プログラムのＳｅｃｕｒｅ ＦｌａｇがＯＮである場合、Ｃ−ＭＰＵ１２は、ＩＭＥＩをＣ−ｖＭＲＴＭ０にキャッシュする（ステップＳ２２）。
【０１６８】
このように、Ｂｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅ後における完全性検証では、携帯電話端末１０は、例えば、ＩＭＥＩの利用時や有効期限が過ぎた場合に、Ｃ−ＭＰＵ１２がＩＭＥＩ等のデータの送信要求をＡ−ＭＰＵ１６へ行い、Ｃ−ＭＰＵ１２は、Ａ−ＭＰＵ１６とＣ−ＭＰＵ１２とを接続する通信路を構成するプログラムを含む実行領域に関する検証処理が成功した場合、Ａ−ＭＰＵ１６から送信されたデータを記憶する。
【０１６９】
携帯電話端末１０によれば、以下の効果が得られる。
【０１７０】
・複数ＭＰＵ等の演算処理部、複数モードに基づいてドメイン分割することができるため、複数の演算処理部を備える場合であっても、十分な利便性および安全性を考慮したドメイン分割を実施することが可能である。
【０１７１】
・従来のＴｒｕｓｔｅｄ ＢｏｏｔおよびＳｅｃｕｒｅ Ｂｏｏｔではソフトウェアの完全性計測または完全性検証のみであったが、本実施形態におけるＢｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅでは、ソフトウェアおよびデータ（ＩＭＥＩ等）の完全性検証まで行うことが可能である。したがって、プログラムのみに依存したセキュアブートではなく、保護したいデータにも依存させるセキュアブート（本実施形態におけるＢｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅ）が実行可能である。
【０１７２】
・携帯電話端末１０は、復号／改ざん検証時に一段階前の処理結果をＳｅｃｕｒｅ Ｆｌａｇにより確認すること、検証成功時にＳｅｃｕｒｅ Ｆｌａｇ＝ＯＮを設定すること、データまで起動プロセスで復号及び完全性検証することにより、所望のドメイン分割および完全性検証が実現できる。
【０１７３】
・コピーされたＩＭＥＩがコピー先端末で利用できないようにするために、Ｃｈａｉｎ−ｂｉｎｄｉｎｇによりＩＭＥＩをＨＷ Ｐｌａｔｆｏｒｍ２１／ＭＲＴＭ１８の固有鍵をルートとしてチェーンで暗号化することで、コピー先端末ではＩＭＥＩ及び関連ソフトウェアの全てが復号困難となる。
【０１７４】
・生産工程で不揮発メモリ１５に記載されたＩＭＥＩと無線通信路に出力されたＩＭＥＩの一致は、ＩＭＥＩがＯＤ確立後に完全性が保証された状態でＭＲＴＭにキャッシュされることで実現される。これは、前述したＣｈａｉｎ−ＵｎｂｉｎｄｉｎｇによるＩＭＥＩ自体の完全性検証のみではなく、ＩＭＥＩを利用するコンポーネントの完全性がＢｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅで保証され、かつＩＭＥＩの復号／検証処理がＳｅｃｕｒｅ Ｆｌａｇに依存して制御されていることからも保証される。さらに、ＩＭＥＩ利用時にＩＭＥＩドリブンで必要最小限のＩＭＥＩ関連ソフトウェアの検証を実行することで、ＩＭＥＩの保護を実現しつつ、効率的な通信側の処理を実現することができる。
【産業上の利用可能性】
【０１７５】
本発明は、複数の演算処理部を備える場合であっても、十分な利便性および安全性を考慮したドメイン分割を実行可能な情報処理装置および携帯電話装置等として有用である。
【図面の簡単な説明】
【０１７６】
【図１】本発明の実施形態にかかる携帯電話端末のハードウェア構成の一例を示す図
【図２】本発明の実施形態にかかる携帯電話端末における主にＣ−ＭＰＵ１２およびＡ−ＭＰＵ１６の分割されたドメインの一例を示す図
【図３】本発明の実施形態にかかるＢｏｏｔｓｔｒａｐ ＳｅｑｕｅｎｃｅのＳｅｃｕｒｅ Ｂｏｏｔ０の一例を示すフローチャート
【図４】本発明の実施形態にかかるＢｏｏｔｓｔｒａｐ ＳｅｑｕｅｎｃｅのＳｅｃｕｒｅ Ｂｏｏｔ１の一例を示すフローチャート
【図５】本発明の実施形態にかかるＢｏｏｔｓｔｒａｐ ＳｅｑｕｅｎｃｅのＳｅｃｕｒｅ Ｂｏｏｔ１’の一例を示すフローチャート
【図６】本発明の実施形態にかかるＢｏｏｔｓｔｒａｐ ＳｅｑｕｅｎｃｅのＳｅｃｕｒｅ Ｂｏｏｔ２の一例を示すフローチャート
【図７】本発明の実施形態にかかるドメイン間リソース共有の一例を示す図
【図８】本発明の実施形態にかかるＢｏｏｔｓｔｒａｐ Ｓｅｑｕｅｎｃｅ後における完全性検証の一例を示すフローチャート
【符号の説明】
【０１７７】
１０ 携帯電話端末
１１ 無線部
１２ Ｃ−ＭＰＵ
１３ 揮発メモリ
１４ ＭＢ（ＭＰＵ Ｂｒｉｄｇｅ）
１５ 不揮発メモリ
１６ Ａ−ＭＰＵ
１７ 内部ＲＯＭ
１８ ＭＲＴＭ
２１ ＨＷ Ｐｌａｔｆｏｒｍ
２２ ＩＰＬ
２３ ＤＣ
２４ ＭＳ
２５ ＶＭＭ
【特許請求の範囲】
【請求項１】
保護リソースを有しないノーマルモードおよび保護リソースを有するセキュアモードを含む複数の動作モードを有する情報処理装置であって、
複数の演算処理部と、
所定のセキュリティポリシに基づいてアクセス制御されるプログラムまたはデータを含む実行領域を示すドメインを生成するドメイン制御部と、
を有し、
前記ドメイン制御部は、前記複数の演算処理部および前記複数の動作モードに基づいて前記ドメインを生成する
情報処理装置。
【請求項２】
請求項１に記載の情報処理装置であって、
前記ドメイン制御部は、更に、前記動作モードの前記保護リソースに基づいてドメインを生成する
情報処理装置。
【請求項３】
請求項１に記載の情報処理装置であって、
前記ドメイン制御部は、更に、所定の実行領域を含む仮想環境に基づいて、ドメインを生成する。
【請求項４】
請求項１に記載の情報処理装置であって、
前記ドメイン制御部は、同一のセキュリティポリシに基づいてアクセス制御される実行領域を同一のドメインとする
情報処理装置。
【請求項５】
請求項４に記載の情報処理装置であって、
前記演算処理部は、複数の実行領域を示すエリアを有し、
前記ドメイン制御部は、送信元エリアから送信先エリアへ通信を行う際、前記送信元エリアと前記送信先エリアとが同一のドメインである場合に、通信を許可する
情報処理装置。
【請求項６】
請求項４に記載の情報処理装置であって、
前記演算処理部は、複数の実行領域を示すエリアを有し、
前記ドメイン制御部は、送信元エリアから送信先エリアへ通信を行う際、前記送信元エリアと前記送信先エリアとが異なるドメインである場合、かつ、前記セキュリティポリシに前記送信元エリアと送信先エリアとの間の通信を許可するための情報が含まれる場合に、通信を許可する
情報処理装置。
【請求項７】
請求項４に記載の情報処理装置であって、
前記演算処理部は、複数の実行領域を示すエリアを有し、
前記ドメイン制御部は、所定の検証処理に失敗したエリアとの間の通信を禁止する
情報処理装置。
【請求項８】
請求項１に記載の情報処理装置であって、
前記演算処理部は、個別に起動可能なプログラムまたはデータを含む実行領域を階層的に有し、
所定階層の実行領域は、当該所定階層の実行領域の固有鍵を用いて当該所定階層よりも一段階上位層の実行領域を復号化し、前記一段階上位層の実行領域について所定の検証処理を実行し、前記検証処理に成功した場合、前記一段階上位層の実行領域が有するプログラムを起動する起動時処理を実行する
情報処理装置。
【請求項９】
請求項８に記載の情報処理装置であって、
前記起動時処理は、最下位層を前記所定階層として最上位層よりも一段階下位層を前記所定階層とするまで一段階ずつ順に実行される
情報処理装置。
【請求項１０】
請求項８または９に記載の情報処理装置であって、
最上位層の実行領域は、当該最上位層の実行領域の起動後に、当該最上位層の実行領域の固有鍵を用いて所定のデータを復号化し、前記所定のデータについて所定の検証処理を実行し、前記検証処理に成功した場合、前記所定のデータを操作可能とする
情報処理装置。
【請求項１１】
請求項１０に記載の情報処理装置であって、
前記所定のデータは、当該情報処理装置を識別するための識別データを含むデータである
情報処理装置。
【請求項１２】
請求項８ないし１１のいずれか１項に記載の情報処理装置であって、
所定階層の実行領域は、前記検証処理に失敗した場合、当該所定階層の重要度に基づく復旧処理を実行する
情報処理装置。
【請求項１３】
請求項１２に記載の情報処理装置であって、
所定階層の実行領域は、前記復旧処理に失敗した場合、当該所定階層の重要度よりも高い重要度に基づく復旧処理を実行する
情報処理装置。
【請求項１４】
請求項１２または１３に記載の情報処理装置であって、
前記復旧処理は、当該情報処理装置の起動停止処理である
情報処理装置。
【請求項１５】
請求項１２または１３に記載の情報処理装置であって、
前記復旧処理は、前記所定階層の実行領域を外部サーバから取得した他の実行領域に差し替える処理である
情報処理装置。
【請求項１６】
請求項１２または１３に記載の情報処理装置であって、
前記復旧処理は、非常通報機能のみ利用可能とする処理である
情報処理装置。
【請求項１７】
請求項１２または１３に記載の情報処理装置であって、
前記復旧処理は、前記検証処理に失敗した旨を報知部に報知させる処理である
情報処理装置。
【請求項１８】
請求項１に記載の情報処理装置であって、
前記演算処理部は、個別に起動可能なプログラムまたはデータを含む実行領域を階層的に有し、
所定階層の実行領域は、当該所定階層の実行領域の固有鍵を用いて当該所定階層よりも一段階上位層の実行領域を暗号化する暗号化処理を実行する
情報処理装置。
【請求項１９】
請求項１８に記載の情報処理装置であって、
前記暗号化処理は、最上位層よりも一段階下位層を前記所定階層としてから最下位層を前記所定階層とするまで一段階ずつ順に実行される
情報処理装置。
【請求項２０】
請求項１８または１９に記載の情報処理装置であって、
最上位層の実行領域は、当該最上位層の実行領域の暗号化前に、当該最上位層の実行領域の固有鍵を用いて所定のデータを暗号化する
情報処理装置。
【請求項２１】
請求項１に記載の情報処理装置であって、
前記演算処理部は、所定のデータを備える第１の演算処理部と、第２の演算処理部とを有し、
前記第２の演算処理部は、前記第１の演算処理部へ前記所定のデータの送信要求を実行し、前記第１の演算処理部と当該第２の演算処理部とを接続する通信路を構成するプログラムを含む実行領域に関する検証処理が成功した場合、前記第１の演算処理部から送信された前記所定のデータを記憶する
情報処理装置。
【請求項２２】
請求項７、８、９、１０、２１のいずれか１項に記載の情報処理装置であって、更に、
前記検証処理の結果を示すセキュアフラグを有し、
前記演算処理部は、前記セキュアフラグに基づいて、前記検証処理に失敗したか否かを判定する
情報処理装置。
【請求項２３】
請求項２２に記載の情報処理装置であって、
前記演算処理部は、前記セキュアフラグに基づく検証処理の結果に応じて、異なる制御を行う
情報処理装置。
【請求項２４】
アンテナと、
操作入力を受け付ける入力部と、
前記アンテナを介して無線通信を行うための無線部と、
請求項１ないし２３のいずれか１項に記載の情報処理装置と
を有する携帯電話装置。
【請求項１】
保護リソースを有しないノーマルモードおよび保護リソースを有するセキュアモードを含む複数の動作モードを有する情報処理装置であって、
複数の演算処理部と、
所定のセキュリティポリシに基づいてアクセス制御されるプログラムまたはデータを含む実行領域を示すドメインを生成するドメイン制御部と、
を有し、
前記ドメイン制御部は、前記複数の演算処理部および前記複数の動作モードに基づいて前記ドメインを生成する
情報処理装置。
【請求項２】
請求項１に記載の情報処理装置であって、
前記ドメイン制御部は、更に、前記動作モードの前記保護リソースに基づいてドメインを生成する
情報処理装置。
【請求項３】
請求項１に記載の情報処理装置であって、
前記ドメイン制御部は、更に、所定の実行領域を含む仮想環境に基づいて、ドメインを生成する。
【請求項４】
請求項１に記載の情報処理装置であって、
前記ドメイン制御部は、同一のセキュリティポリシに基づいてアクセス制御される実行領域を同一のドメインとする
情報処理装置。
【請求項５】
請求項４に記載の情報処理装置であって、
前記演算処理部は、複数の実行領域を示すエリアを有し、
前記ドメイン制御部は、送信元エリアから送信先エリアへ通信を行う際、前記送信元エリアと前記送信先エリアとが同一のドメインである場合に、通信を許可する
情報処理装置。
【請求項６】
請求項４に記載の情報処理装置であって、
前記演算処理部は、複数の実行領域を示すエリアを有し、
前記ドメイン制御部は、送信元エリアから送信先エリアへ通信を行う際、前記送信元エリアと前記送信先エリアとが異なるドメインである場合、かつ、前記セキュリティポリシに前記送信元エリアと送信先エリアとの間の通信を許可するための情報が含まれる場合に、通信を許可する
情報処理装置。
【請求項７】
請求項４に記載の情報処理装置であって、
前記演算処理部は、複数の実行領域を示すエリアを有し、
前記ドメイン制御部は、所定の検証処理に失敗したエリアとの間の通信を禁止する
情報処理装置。
【請求項８】
請求項１に記載の情報処理装置であって、
前記演算処理部は、個別に起動可能なプログラムまたはデータを含む実行領域を階層的に有し、
所定階層の実行領域は、当該所定階層の実行領域の固有鍵を用いて当該所定階層よりも一段階上位層の実行領域を復号化し、前記一段階上位層の実行領域について所定の検証処理を実行し、前記検証処理に成功した場合、前記一段階上位層の実行領域が有するプログラムを起動する起動時処理を実行する
情報処理装置。
【請求項９】
請求項８に記載の情報処理装置であって、
前記起動時処理は、最下位層を前記所定階層として最上位層よりも一段階下位層を前記所定階層とするまで一段階ずつ順に実行される
情報処理装置。
【請求項１０】
請求項８または９に記載の情報処理装置であって、
最上位層の実行領域は、当該最上位層の実行領域の起動後に、当該最上位層の実行領域の固有鍵を用いて所定のデータを復号化し、前記所定のデータについて所定の検証処理を実行し、前記検証処理に成功した場合、前記所定のデータを操作可能とする
情報処理装置。
【請求項１１】
請求項１０に記載の情報処理装置であって、
前記所定のデータは、当該情報処理装置を識別するための識別データを含むデータである
情報処理装置。
【請求項１２】
請求項８ないし１１のいずれか１項に記載の情報処理装置であって、
所定階層の実行領域は、前記検証処理に失敗した場合、当該所定階層の重要度に基づく復旧処理を実行する
情報処理装置。
【請求項１３】
請求項１２に記載の情報処理装置であって、
所定階層の実行領域は、前記復旧処理に失敗した場合、当該所定階層の重要度よりも高い重要度に基づく復旧処理を実行する
情報処理装置。
【請求項１４】
請求項１２または１３に記載の情報処理装置であって、
前記復旧処理は、当該情報処理装置の起動停止処理である
情報処理装置。
【請求項１５】
請求項１２または１３に記載の情報処理装置であって、
前記復旧処理は、前記所定階層の実行領域を外部サーバから取得した他の実行領域に差し替える処理である
情報処理装置。
【請求項１６】
請求項１２または１３に記載の情報処理装置であって、
前記復旧処理は、非常通報機能のみ利用可能とする処理である
情報処理装置。
【請求項１７】
請求項１２または１３に記載の情報処理装置であって、
前記復旧処理は、前記検証処理に失敗した旨を報知部に報知させる処理である
情報処理装置。
【請求項１８】
請求項１に記載の情報処理装置であって、
前記演算処理部は、個別に起動可能なプログラムまたはデータを含む実行領域を階層的に有し、
所定階層の実行領域は、当該所定階層の実行領域の固有鍵を用いて当該所定階層よりも一段階上位層の実行領域を暗号化する暗号化処理を実行する
情報処理装置。
【請求項１９】
請求項１８に記載の情報処理装置であって、
前記暗号化処理は、最上位層よりも一段階下位層を前記所定階層としてから最下位層を前記所定階層とするまで一段階ずつ順に実行される
情報処理装置。
【請求項２０】
請求項１８または１９に記載の情報処理装置であって、
最上位層の実行領域は、当該最上位層の実行領域の暗号化前に、当該最上位層の実行領域の固有鍵を用いて所定のデータを暗号化する
情報処理装置。
【請求項２１】
請求項１に記載の情報処理装置であって、
前記演算処理部は、所定のデータを備える第１の演算処理部と、第２の演算処理部とを有し、
前記第２の演算処理部は、前記第１の演算処理部へ前記所定のデータの送信要求を実行し、前記第１の演算処理部と当該第２の演算処理部とを接続する通信路を構成するプログラムを含む実行領域に関する検証処理が成功した場合、前記第１の演算処理部から送信された前記所定のデータを記憶する
情報処理装置。
【請求項２２】
請求項７、８、９、１０、２１のいずれか１項に記載の情報処理装置であって、更に、
前記検証処理の結果を示すセキュアフラグを有し、
前記演算処理部は、前記セキュアフラグに基づいて、前記検証処理に失敗したか否かを判定する
情報処理装置。
【請求項２３】
請求項２２に記載の情報処理装置であって、
前記演算処理部は、前記セキュアフラグに基づく検証処理の結果に応じて、異なる制御を行う
情報処理装置。
【請求項２４】
アンテナと、
操作入力を受け付ける入力部と、
前記アンテナを介して無線通信を行うための無線部と、
請求項１ないし２３のいずれか１項に記載の情報処理装置と
を有する携帯電話装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２００９−１６９８４１（Ｐ２００９−１６９８４１Ａ）
【公開日】平成２１年７月３０日（２００９．７．３０）
【国際特許分類】
【出願番号】特願２００８−９４６９（Ｐ２００８−９４６９）
【出願日】平成２０年１月１８日（２００８．１．１８）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成２１年７月３０日（２００９．７．３０）
【国際特許分類】
【出願日】平成２０年１月１８日（２００８．１．１８）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]