JP4998019B2 - 状態表示制御装置 - Google Patents

Description

この発明は、状態表示制御装置に関し、特に、パソコン（ＰＣ）等のコンピュータに悪意のあるソフトウェアがインストールされた場合等において、不正アクセスの存在を検出して、ユーザに警告や信頼性情報などを報知するセキュリティ機能を備えた状態表示（信頼性表示）制御装置に関する。

今日、パソコン等のコンピュータは、オペレーティングシステム（ＯＳと呼ぶ）の管理のもと、多数のアプリケーションプログラムが起動され、種々の機能が実現されている。
アプリケーションプログラムの中には、ウイルスやスパイウェアのように、不正なアクセスや個人情報等を盗む目的を持った悪意のあるソフトウェアが存在し、これらのソフトウェアによる不正アクセス等を防止するため、種々の対策がとられている。
たとえば、パソコン（以下、ＰＣと呼ぶ）にＴＰＭ（Trusted Platform Module）と呼ばれるハードウェアＬＳＩを破壊不可能なように搭載し、不正なソフトウェアの存在の検出や、不正な認証を防止するセキュリティシステムが提案されている（特許文献１参照）。

また、１つのＰＣ上に、複数のＯＳを搭載し、不正アクセスを検出してセキュリティを向上させるシステムも提案されている。
たとえば、２つのＯＳを搭載し、一方のＯＳの管理下では、従来と同様に、ユーザが自由にインストールしたアプリケーションプログラムを動作させ、他方のＯＳの管理下では、IT管理者等によって信頼されたソフトウェアのみを動作させる。
ここで信頼されたソフトウェアとは、たとえば、アンチウイルスソフトウェア，パーソナルファイアウォールなど特殊な用途目的のソフトウェア群である。２つのＯＳのうち一方のＯＳを従来ＯＳと呼び、他方のＯＳを、Trusted OS（以下、T-OS）と呼ぶ。

また、Ｔ−ＯＳの管理下で動作するソフトウェア群は、表示装置に表示された特別な表示枠の中に、その処理内容の画面を表示させるように実行させられる。そのため、表示される内容は、一般に特殊な表示メモリ領域ＴＦＢ（Trusted Frame Buffer）に書き込まれる。ＴＦＢに書き込まれた情報が、その特別な表示枠（T-OS用枠）の中に表示される。

図１５に、従来のセキュリティシステムの概略構成の説明図を示す。
図１５は、１つのＰＣの構成の一部を示しており、ハードウェアとしてＣＰＵ，Display，Graphic Chipを備えている。
また、ＣＰＵによって従来ＯＳとＴ−ＯＳ（Trusted OS）が動作させられ、さらに、２つのＯＳは、ＶＭＭ（Virtual Machine Monitor）と呼ばれる管理ソフトウェアのもとに動作している。

また、Graphic Chipは、Displayへの表示内容を制御するＬＳＩであり、その中に、２つの表示メモリ領域（TFB，UTFB）を有する。
ＴＦＢ（Trusted Frame Buffer）は、Ｔ−ＯＳによってのみ使用されるメモリ領域であり、ＵＴＦＢ（Untrusted Frame Buffer）は、従来ＯＳによってのみ使用されるメモリ領域とする。
Displayは、ＣＲＴやＬＣＤのような一般的な表示装置であるが、従来ＯＳ用の表示枠と、Ｔ−ＯＳ用の表示枠を表示する。そしてそれぞれのＯＳの管理下で動作するソフトウェアによって表示要求がされた場合は、対応するＯＳ用の表示枠の中に、表示要求されたデータを表示する。

管理ソフトウェアＶＭＭは、主として従来ＯＳからの表示要求入力を受理する仮想Graphic部１と、Ｔ−ＯＳからの表示要求入力を受理する仮想Graphic部２と、Graphic Chipを制御するドライバ部（Graphic Chipドライバ）とを備える。
たとえば、従来ＯＳの管理下で動作するソフトウェアから何らかの表示要求があった場合、その表示要求入力を仮想Graphic部１が受理し、Graphic Chipドライバがその表示要求を解釈して、表示データとともにGraphic Chipに送る。
Graphic Chipは、表示要求を受理すると、それが従来ＯＳによるものである場合は、受信した表示データを、ＵＴＦＢへ書き込む。ＵＴＦＢに表示データが書き込まれると、Display上に表示された従来ＯＳ用の表示枠の中に、その表示データが表示される。

同様に、Display上には、Ｔ−ＯＳ用の表示枠が表示され、Ｔ−ＯＳの管理下で動作するソフトウェアからの表示要求があった場合に、その表示要求された表示データが、Ｔ−ＯＳ用の表示枠の中に表示される。
Displayには、２つの表示枠が表示されるが、表示枠の色を変えることなどにより、ユーザには、表示されている枠がどちらの表示枠であるかを知らせる。
Ｔ−ＯＳの管理下で動作するソフトウェアは、常に信頼された正当なソフトウェアであるとすると、Display上のＴ−ＯＳ用の表示枠に表示されている内容は、不正なソフトウェアによるものではなく、ユーザは信頼できる情報と考えて、表示内容を読み、必要なデータを入力したりする。
特開２００３−２７１２５４号公報

しかし、Displayに表示されるＴ−ＯＳ用の表示枠の色や表示位置などが固定されているとすると、その表示内容を模倣し不正な表示がされる可能性がある。たとえば、ＰＣに従来ＯＳの管理下において動作する不正なソフトウェアがインストールされ、その不正なソフトウェアで、Display上に、Ｔ−ＯＳ用の表示枠と同一の枠を表示させ、ユーザにその枠内に表示されている情報は、あたかもＴ−ＯＳによって信頼されているソフトウェアが表示したものであるかのような表示をさせることが可能である。

図１６に、このような不正ソフトウェアによって不正な表示がされる状態の説明図を示す。この場合、不正なソフトウェアは、従来ＯＳの管理下にあるので、表示要求された表示データは、すべてＵＴＦＢに書き込まれることになる。
しかし、不正なソフトウェアによって、ＵＴＦＢ上に、従来ＯＳ用の表示枠とＴ−ＯＳ用の表示枠をどちらも書き込ませるようにすることは可能であり、Displayを見ているユーザにとっては、Ｔ−ＯＳ用の表示枠が不正なソフトウェアによって表示されたものであるか否かの区別がつかず、その表示内容は、図１５に表示されたものと同一であるかのように見えてしまう。

このとき、たとえば、Ｔ−ＯＳ用の表示枠と偽っている枠に、ＩＤやパスワードを入力させる画面が表示されていたとすると、ユーザが何の疑いもなく、ＩＤやパスワードを入力してしまう可能性がある。
さらに、不正なソフトウェアの機能として、入力されたパスワード等をネットワークを介して他の特定のＰＣへ転送するような処理が組み込まれている場合は、そのパスワード等が盗まれてしまうことになる。

特に、本来のＴＦＢを介して表示されるＴ−ＯＳ用の正常な表示枠そのものや、枠内への表示内容が表示されていない場合には、不正ソフトウェアによって表示されたＴ−ＯＳ用の表示枠やその表示内容は、ユーザが信頼できるものと判断してしまう可能性が高く、ユーザのパスワードの入力を阻止することが難しい場合がある。
不正なソフトウェアは、種々の方法でＰＣに侵入し、ユーザが気がつきにくい形態で存在する場合もあるので、ユーザがDisplayの表示だけを信頼して、パスワード等の入力をするのは危険である。また、アンチウイルスソフトなどをインストールしたとしても、不正なソフトウェアの侵入を完全に防止することは困難であり、Displayに不正な表示がされる可能性は残る。

そこで、DisplayのＴ−ＯＳ用の表示枠に表示される内容は一応信頼あるものとして処理するものの、その表示内容が本当に信頼できる内容であるかどうかを確認することのできる仕組みを、ユーザに提供することが望まれる。

この発明は、以上のような事情を考慮してなされたものであり、本来のDisplayへの表示とは別に、不正なソフトウェアが存在しないことや表示内容の信頼性等を確認できる出力手段を備えた状態表示制御装置を提供することを課題とする。

この発明は、２つの基本機能管理部と、２つの基本機能管理部の管理下でそれぞれ動作する機能モジュールからの表示要求に基づいて、表示データを表示するデータ表示部と、前記基本機能管理部のうち一方の第１基本機能管理部の管理下で動作し、かつデータ表示部への表示を管理し、予め信頼性が確認された表示管理モジュールと、前記表示管理モジュールおよび他方の第２基本機能管理部からの表示要求を受理し、その表示要求の送信元が正当か否かを検査するＯＳ管理部と、前記ＯＳ管理部が検査した正当性の検査結果および前記表示管理モジュールからの表示要求に基づいて、信頼性判断情報を出力する出力部と、前記ＯＳ管理部が検査するための基準となる判断情報を予め記憶した信頼性情報管理部とを備え、前記ＯＳ管理部が、前記表示要求によりデータ表示部に表示データが表示された場合、前記判断情報に基づいて表示要求の送信元の正当性を検査し、データ表示部に表示されている表示データの表示状態を確認可能な情報を、出力部へ出力することを特徴とする状態表示制御装置を提供するものである。

これによれば、ユーザが出力部から出力される情報を確認することにより、データ表示部に表示されている状態の正当性を的確に判断でき、たとえば不正なソフトウェアによって表示された画面に対してユーザがデータの入力をすることを未然に防止することができ、データ表示部に表示されている表示状態の確認の信頼性を向上できる。
ここで、信頼性判断情報は、ユーザが、データ表示部に表示されているデータの信頼性を判断するための情報を意味する。この情報が視覚的な情報の場合は、図２の状態表示部およびキーボード表示部に表示される。

この発明において、前記第１基本機能管理部は、予め信頼性が確認された機能モジュールのみの動作を制御する信頼化オペレーティングシステムであることを特徴とする。
ここで、第１基本機能管理部は、図１の第２ＯＳに相当し、信頼性が確認された機能モジュールソフトウェアの動作を管理するTrusted OSに相当する。機能モジュールとは、特定の機能を実現するために作成されたアプリケーションプログラムを意味する。
また、他方の第２基本機能管理部は、図１の第１ＯＳに相当し、従来および現在市販されているパソコン等に搭載されているオペレーティングシステム（従来OS）に相当する。

また、この発明において、前記データ表示部は、第１基本機能管理部の管理下で動作する機能モジュールおよび前記表示管理モジュールによって表示要求された表示データを表示する第１表示枠と、第２基本機能管理部の管理下で動作する機能モジュールによって表示要求された表示データを表示する第２表示枠とを同時に表示することを特徴とする。
データ表示部は、図１の表示装置に相当し、起動された特定の機能モジュールによって表示されるべき表示データを表示するディスプレイである。ここで、第１表示枠とは、図１のＴ−ＯＳ枠を意味し、第２表示枠とは図１の従来ＯＳ枠を意味する。データ表示部には、ＣＲＴ，ＬＣＤ，有機ＥＬ，ＰＤＰなど、一般的に用いられている表示装置を用いることができる。

また、前記出力部は、データ表示部に表示されている表示データの表示状態を視覚的に確認可能な状態表示部を備えていることを特徴とする。
出力部は、ユーザに何らかの情報を提供するものであり、その出力方法は問わない。たとえば、情報を視覚的に確認することが可能な表示装置を用いることができる。状態表示部は、視覚的に確認する出力部の一つである。
状態表示部には、前記したようなＣＲＴ，ＬＣＤなどを用いることもできるが、ＬＥＤや、特定の文字，数字，図形，アイコンなどを表示可能な専用の表示デバイスを用いてもよい。
また、出力部には、情報を聴覚的に確認することのできる音声出力装置（スピーカ）や書面として出力できるプリンタなどを用いてもよい。

また、前記状態表示部が、前記第１表示枠の中に表示されている表示データが、前記第１基本機能管理部の管理下で動作する機能モジュールによる表示要求されたデータであることを示す特定状態表示をすることを特徴とする。
ここで、状態表示部は、機能モジュールから要求された表示データそのものを表示するものではなく、データ表示部に表示されるデータの表示状態を確認するための表示装置であることを意味する。そして、特に、データ表示部に表示される第１表示枠（T-OS枠）の中に表示される表示データの特定状態を確認するための表示をするものである。

ここで、特定状態とは、第１表示枠（T-OS枠）の中に表示されている表示データが、第１基本機能管理部（Trusted OS）の管理下で動作する機能モジュールによって表示要求されたデータであることを示す状態である。その特定状態表示を見れば、第１表示枠の表示状態が、信頼性のあるものかまたはないものであるかの確認ができる。
なお、特定状態表示は、後述する状態表示部５１およびキーボード表示部５２に表示される表示を意味する。

また、この発明において、前記信頼性情報管理部が、ＴＰＭ（Trusted Platform Module）からなり、前記判断情報が、少なくとも各機能モジュール，基本機能管理部，表示管理モジュール，ＯＳ管理部をそれぞれ特定するハッシュ値であることを特徴とする。
ここで、前記ＴＰＭは、起動時に測定された前記表示管理モジュールのハッシュ値を記憶することを特徴とする。
上記ハッシュ値は、後述するＴＰＭのハッシュ記憶部に記憶されるハッシュ値を意味する。

また、前記ＯＳ管理部は、前記表示管理モジュールを特定する認証データを予め記憶する記憶部と、表示要求の送信元の信頼性を認証する認証部とを備え、前記認証部が、前記ＴＰＭに記憶されていた表示管理モジュールのハッシュ値と、前記認証データとが一致した場合に、前記表示管理モジュールを正当と判断することを特徴とする。
ＯＳ管理部は、図１のＯＳ管理部（ＶＭＭ）に相当する。

さらに、前記ＴＰＭは、表示要求を暗号化するのに用いる鍵を記憶する鍵記憶部を備え、前記ＯＳ管理部は、前記表示要求に含まれる情報を暗号化する暗号部と、前記暗号部が暗号化処理をするための鍵を、前記ＴＰＭから取得する鍵交換部とをさらに備えることを特徴とする。
ここで、暗号化に用いる鍵は、後述する共通鍵ＫＥＹに相当する。

また、前記ＯＳ管理部は、前記表示管理モジュールからの表示要求を受理した場合、前記状態表示部に、前記特定状態表示をすることを特徴とする。
これは、後述する図９の表示例１に関連する。

さらに、前記ＯＳ管理部は、前記第２基本機能管理部からの表示要求を受理したが、前記表示管理モジュールからの表示要求を受理していない場合、前記状態表示部には、前記特定状態表示はしないことを特徴とする。
これは、後述する図１０の表示例２に関連する。

この発明によれば、表示要求された表示データを表示するデータ表示部とは別に、信頼性判断情報を出力する出力部を設けているので、ユーザは、出力部から出力される情報を確認することにより、データ表示部に表示されている状態の正当性を的確に判断でき、不正な表示画面に対するデータ入力の未然防止ができ、その結果、データ表示部へ表示する表示内容の信頼性を向上できる。

以下、図に示す実施例に基づいて本発明を詳述する。なお、本発明はこれによって限定されるものではない。
＜状態表示制御装置の構成＞
図１に、この発明の状態表示制御装置の一実施例の概略構成ブロック図を示す。
図１の状態表示制御装置は、たとえばパソコンのような情報処理装置の中に組み込まれた状態で提供される。
図１に示した各機能ブロックは、情報処理装置のこの発明に関係する主要な機能のみを示している。また、各機能ブロックは、ハードウェア又はソフトウェアで構成されるが、このうちＯＳ（２，３）と、ＯＳ管理部１は、ソフトウェアで構成されることが好ましい。

この発明の情報処理装置には、２つのＯＳ（基本機能管理部）が搭載される。
第１ＯＳ（２）は、ユーザがインストールしたアプリケーションプログラムの動作を管理する従来ＯＳであり、第２ＯＳ（３）は、信頼性が確認された正当なソフトウェア群の動作を管理するTrusted OS（T-OS）である。
このソフトウェア群とは、特定の管理担当者やＯＳベンダのみが、追加，修正，削除を行うことのできるソフトウェアであり、ＯＳベンダ等によって信頼性が検証されたソフトウェアである。また、Ｔ−ＯＳそのものを構成するソフトウェア群も、ＯＳベンダ等によって信頼性が検証されたものである。

第１ＯＳ（２）はＯＳ管理部１と通信する第１通信部２１を備える。第１通信部２１は、この発明では、アプリケーションプログラムからの表示命令を受けて、表示装置８に表示する情報を、ＯＳ管理部１に送信する機能を有する。
第２ＯＳ（３）は、この発明に特有な状態表示を管理および制御する表示管理部３０を備える。表示管理部３０は、第２ＯＳの管理下で動作するアプリケーションプログラムからの表示命令を受けて、表示装置８および出力部５へ表示する情報を、ＯＳ管理部１に送信する機能を有する。

表示管理部３０は、主として、エージェント３１と第２通信部３２を備える。エージェント３１は、主として、表示要求を監視し、出力部５に表示させる状態情報の表示制御をする部分である。
第２通信部３２は、第１通信部２１と同様に表示する情報をＯＳ管理部１に送信する部分であるが、エージェント３１からの指令のもと、出力部５に表示をするための情報をＯＳ管理部１へ与える部分である。

第１通信部２１は、後述する図２のグラフィックドライバ１（２２）と、ＫＢＣドライバ１（２１）に相当する。第２通信部３２は、後述するグラフィックドライバ２（３３）とＫＢＣドライバ２（３４）に相当する。

ＯＳ管理部１（VMM：Virtual Machine Monitor）は、ＣＰＵから直接制御されるソフトウェア群から構成され、２つのＯＳと、表示装置などの外部入出力機器との通信を制御する部分である。したがって、ＶＭＭ１は、論理的には２つのＯＳとＣＰＵとの間に位置する。
ＯＳ管理部１（ＶＭＭ）は、主として、表示入力部（１０，１１），表示通信部１６，認証通信部１７とからなる。
表示入力部は、主として第１ＯＳ（２）からの情報を受信する第１表示入力部１０と、第２ＯＳ（３）からの情報を受信する第２表示入力部１１とからなる。
表示通信部１６は、表示する内容を表示コントローラ７へ与える部分であり、後述する表示ドライバ（Graphic Chipドライバ）に相当する。

表示通信部１６は、第１表示入力部１０からの表示データと、第２表示入力部１１からの表示データを受け取り、表示コントローラ７へ与える。
認証通信部１７は、主として、第１ＯＳ（２）および第２ＯＳ（３）から送られてきた表示要求が正当なものか否かを判断した結果とその結果を報知するための表示情報を、報知制御部４へ送信する部分である。また、報知制御部（ＫＢＣチップ）４を初期化したり、その動作を制御するための情報を送信する部分でもある。認証通信部１７は、後述する認証ドライバに相当する。
報知制御部４の制御は、認証通信部１７のみが可能な構成とする。

第１および第２表示入力部（１０，１１）は、ともに、描画処理部（１２，１４）と、認証制御部（１３，１５）とを備える。
第１および第２描画処理部（１２，１４）は、その対応する上位ＯＳから送信されてきた表示データを受理し、表示通信部１６へ送る部分である。この描画処理部（１２，１４）で取り扱う表示データは、表示装置８に表示される。
第１描画処理部１２は、後述する仮想グラフィック１に相当し、第２描画処理部１４は、後述する仮想グラフィック２に相当する。

第１および第２認証制御部（１３，１５）は、主としてＯＳから要求された表示命令を受けて、報知制御部４へ出力する情報を生成する部分である。
第１認証制御部１３は、後述する仮想ＫＢＣ１に相当し、第２認証制御部１５は、後述する仮想ＫＢＣ２に相当する。
また、第２認証制御部１５は、第２通信部３２からの表示要求と、第１認証制御部１３からの表示要求に関する情報を受けて、その表示要求が正当なものか否かを判断して、その判断結果を認証通信部１７へ送信する部分でもある。
第２認証制御部１５の詳細構成とその動作については、後述する。

表示コントローラ７は、表示通信部１６から送られる表示データを、表示メモリ領域７０に展開し、表示装置にその表示データをさせる制御をする部分であり、後述するグラフィックチップに相当する。
ここで、この発明では、表示メモリ領域７０には、従来ＯＳ用の領域ＵＴＦＢ（Untrusted Frame Buffer）７１と、Ｔ−ＯＳ用の領域ＴＦＢ（Trusted Frame Buffer）７２とが設けられる。

表示装置８は、ＣＲＴやＬＣＤなどの表示デバイスであり、表示メモリ領域７０に格納された表示データを、表示装置８上の対応する部分に表示する。
この発明では、表示装置８の表示画面の中に、従来ＯＳ枠８１と、Trusted OS（T-OS）枠８２とを表示する。そしてＵＴＦＢ７１の領域に格納されたデータは、従来ＯＳ枠８１の中に表示され、ＴＦＢ７２の領域に格納されたデータは、Ｔ−ＯＳ枠８２の中に表示される。

従来ＯＳの管理下で動作する正当なソフトウェアが表示要求をした場合、その表示要求された表示データは、従来ＯＳ枠８１の中に表示される。
一方、Ｔ−ＯＳの管理下で動作する信頼性のある正当なソフトウェアが表示要求をした場合、その表示要求されたデータは、Ｔ−ＯＳ枠８２の中に表示される。
この表示装置８に対する表示制御と表示内容は、従来技術と同様である。

報知制御部４は、認証通信部１７から送信される情報（報知命令コマンド）を受信して、その情報に対応した報知出力を、出力部５へ与える部分である。
報知制御部４は、後述するＫＢＣチップに相当する。
また、報知制御部４は、主として、復号部４１，鍵受理部４２，報知出力部４３とから構成される。
鍵受理部４２は、ＴＰＭ６に記憶されている鍵ＫＥＹをＴＰＭ６から取得する部分である。
復号部４１は、認証通信部１７から送信されてきた情報を、鍵受理部４２が取得した鍵ＫＥＹを用いて、復元する部分である。
報知出力部４３は、復号部４１によって復元された情報を解釈して、出力部５に出力する情報を生成し、出力部５の動作を制御する部分である。

出力部５は、報知出力部４３からの指示に基づいて、現在の表示装置８の表示内容の状態を示す情報を、ユーザに報知する部分である。また、出力部５は、報知制御部４によってのみ制御され、２つのＯＳから直接制御できない構成とする。
報知には、たとえば文字，数字，図形，ＬＥＤの点消灯，点滅，ＬＥＤの表示色の変化など視覚的な報知や、音声による警告など聴覚的な報知があり、この他にも種々のものが考えられる。

以下では、主として、視覚的な報知である文字の表示とＬＥＤの点消灯による報知について説明する。
たとえば、出力部５には、Ｔ−ＯＳの管理下で動作するソフトウェアの動作状態（たとえば、数字による表示）や、表示装置８のＴ−ＯＳ枠８２に現在表示されている内容がＴ−ＯＳ管理下で動作する信頼性のあるソフトウェアによって表示されているか否かの状態を視覚的にわかる形態で表示する。

出力部５の状態表示部５１は、上記のような動作状態を、文字や数字を使用してユーザに視覚的に報知する部分である。たとえば、Ｔ−ＯＳ３の管理下で動作するソフトウェアから表示装置８へ表示要求がある場合、状態表示部５１に、特定アイコンや文字の表示あるいは、Ｔ−ＯＳの表示要求があったことを意味する番号の表示などを行う。
このような表示があった場合には、表示装置８のＴ−ＯＳ枠８２に表示されている内容は、Ｔ−ＯＳ管理下で動作する信頼性のあるソフトウェアによって表示されたものであることを意味する。
一方、上記表示がない場合は、Ｔ−ＯＳ枠８２には、Ｔ−ＯＳ管理下で動作する信頼性のあるソフトウェアによって表示されるべきものが何もないことあるいは、信頼性のあるソフトウェアから表示要求はないことを意味する。

この状態表示部５１に表示される状態は、図１に示したエージェント３１からの指示入力（表示要求）に基づいて、第２認証制御部１５，ＴＰＭ６，認証通信部１７，および報知制御部４を経由して与えられた状態であり、不正なソフトウェアの介在の有無にかかわらず、後述するようなこれらの機能ブロックの動作によりユーザが信頼できる状態となる。
したがって、ユーザは、状態表示部５１に表示された状態表示を確認することにより、たとえば、表示装置８のＴ−ＯＳ枠８２に表示されたパスワード入力画面に対して、パスワードを入力をするか否かを安心して決定することができる。

たとえば、状態表示部５１に、信頼性のあることを意味する状態表示（番号表示）があった場合に、表示装置８のＴ−ＯＳ枠８２にＩＤ等の入力を求める画面表示がされているとき、その表示された内容を信頼して、ユーザは、ＩＤやパスワードなどを入力する。
一方、状態表示部５１に信頼性のあることを意味する状態表示がなかった場合（状態表示なし）に、表示装置８のＴ−ＯＳ枠８２に、何らかの入力を求める画面表示がされているとき、ユーザは、状態表示部５１に状態表示が何もないことを確認することにより、現在の「入力を求める画面表示」は偽りの表示である可能性があると判断することができる。すなわち、その偽りの表示に対して、ユーザがＩＤ等を入力することを未然に防止できる。

ＴＰＭ６は、従来から利用されているセキュリティデバイスであり、ＣＰＵとともに、この中にハッシュ記憶部６１や鍵記憶部６２を備える。
ハッシュ記憶部６１は、ＰＣに電源を投入した時から順に起動される所定の管理ソフトウェア群（BIOS，ローダー，VMMなど）から送信されてくるハッシュ値を保持するメモリである。
たとえば、ソフトウェアが、ＢＩＯＳ，ローダー，ＶＭＭ，エージェント，Ｔ−ＯＳの順で起動する場合、ＢＩＯＳは自分自身のコードを測定し、その結果のハッシュ値，BIOSはローダーを測定し、その結果のハッシュ値，ローダーはＶＭＭを測定し、その結果のハッシュ値，VMMはエージェントを測定し、その結果のハッシュ値，エージェントはＴ−ＯＳを測定し、その結果のハッシュ値が、それぞれ、ハッシュ記憶部６１に保存される。

鍵記憶部６２は、この発明の第２認証制御部１５および報知制御部４の復号部４１で使用するための共通鍵ＫＥＹを予め保存しておくメモリである。
鍵ＫＥＹは、たとえば、ＶＭＭ１の起動時に、第２認証制御部１５で生成され、ＴＰＭの鍵記憶部６２へ送信されて予め保存される。
また、報知制御部４が、起動時に、共通鍵ＫＥＹを生成し、鍵受理部４２を介して、その鍵ＫＥＹをＴＰＭ６に送信し、ＴＰＭの鍵記憶部６２に記憶してもよい。

図２に、この発明の状態表示制御装置の一実施例の構成ブロック図を示す。
図２の機能ブロックにおいて、図１に示したブロックと同じ符号がついているものは、同一の機能を有するものとする。
図２において、第１ＯＳ（従来ＯＳ）２の管理下で動作する正当なソフトウェアにより、表示要求がされた場合、その表示要求に含まれる表示データはグラフィックドライバ１（２２）から、ＶＭＭ１の仮想グラフィック１（１２）へ送られ、さらに表示ドライバ１６に送られて、表示可能な情報に変換され、グラフィックチップ７に与えられる。
グラフィックチップ７では、表示可能な情報を、表示メモリ領域７０のＵＴＦＢ７１に展開し、表示装置８の従来ＯＳ枠８１の中に表示する。

第２ＯＳ（T-OS）３の管理下で動作する正常なソフトウェアにより表示要求がされた場合、表示要求に含まれる表示データは、グラフィックドライバ２（３３）から、ＶＭＭ１の仮想グラフィック２（１４）に送られ、さらに表示ドライバ１６に送られる。
そして、表示データは、表示可能な情報に変換されてグラフィックチップ７へ与えられ、ＴＦＢ７２のメモリ領域に展開されて、表示装置８のＴ−ＯＳ枠８２の中に表示される。

また、どちらかのＯＳから表示要求がＶＭＭ１へ送られるとき、それぞれのＯＳ（２，３）のＫＢＣドライバ（２１，３４）から、表示要求に伴う制御信号（セレクト信号，識別情報，ハッシュ値など）が対応する仮想ＫＢＣ（１３，１５）に与えられる。
このＫＢＣドライバ（２１，３４）は、ＶＭＭ１の仮想ＫＢＣ（１３，１５）を初期化する機能およびその動作を制御する機能を有する。

仮想ＫＢＣ２（１５）は、ＫＢＣドライバ２（３４）からの制御信号に基づいて、エージェント３１の認証等を行って、表示要求が正当か否かを判断し、その判断に基づく情報を報知制御部４に相当するＫＢＣチップ４へ送信する。
仮想ＫＢＣ２（１５）は、主として、受信部，送信部，記憶部，認証部，鍵交換部，暗号部を備える。これらについては後述する。

図２において、ＫＢＣチップ４は、この発明では出力部４へ報知する情報を生成する機能を有するが、ＫＢＣチップ４本来の機能である外部入出力機器の監視およびコントロール機能も有する。
たとえば、キーボードから入力されたキー情報を解釈して、押されたキー入力のコードを生成し、ＫＢＣドライバ（２１，３４）を介して、ＯＳ（２，３）へ送信する機能や、ＯＳからの指示に基づいてキーボードに付属されたＬＥＤを点消灯する機能、マウスなどのポインティング入力機器からの入力情報をＯＳへ転送する機能，バッテリ充電機能やバッテリの監視機能が含まれる。

出力部５には、状態表示をする表示デバイスとして、専用の状態表示部５１の他、キーボードに本来備えられているＬＥＤなどからなるキーボード表示部５２（以下、Status Displayとも呼ぶ）を含めてもよい。
また、キーボード表示部５２に、現在Ｔ−ＯＳからの表示要求があったことを示す専用のＬＥＤ（Trustedランプとも呼ぶ）を設けてもよい。

また、エージェント３１は、Ｔ−ＯＳ３内のみに存在する常駐ソフトウェアであり、出力部５への状態表示を制御するためのソフトウェアである。
エージェント３１の主な機能としては、Ｔ−ＯＳの管理下にあるソフトウェアからの表示要求を受信し、その表示要求が正当なものか否かを監視する機能、正当な場合に、グラフィックドライバ２（３３）を介して仮想グラフィック２（１４）に対して表示要求を送信する機能、表示要求の内容に対応した識別情報を生成する機能、生成した識別情報を、ＫＢＣドライバ２（３４）を介して仮想ＫＢＣ２（１５）へ送信する機能などがある。

エージェント３１が生成する識別情報は、図４に示すようなエージェントポリシーに基づいて生成する情報である。
識別情報には、たとえば、表示要求が正当であることを示す情報Ｊ１，表示要求に不正の可能性があることを示す情報Ｊ２などがある。
エージェントポリシーとは、出力部５に表示させる報知情報をどれにするかを記述した報知内容リストを意味する。エージェントポリシーは、IT管理者によって設定され、T-OS内に予め記憶される。
図４においては、一実施例として、３つのポリシーが示されている。たとえば、ポリシー１は、Ｔ−ＯＳの管理下のソフトウェアから表示要求があり、Ｔ−ＯＳ枠８２に何らかのメッセージを表示させる場合について示している。

このポリシー１の場合、図４には４通りのバリエーションを示している。
４通りのバリエーションから初期設定、あるいはユーザの設定入力により、いずれかを選択する。出力部５には、選択した項目に対応した表示がされる。
また、policy1-1として、Status Displayに番号を常に表示してもよいことを示している。あるいは、わずらわしい表示をできるだけしないようにするために、ユーザがキーボードの特定キーを押したときのみ、一定時間だけ番号を表示するようにしてもよいことを示している。

＜仮想ＫＢＣ２の構成＞
図３に、この発明の仮想ＫＢＣ２（１５）の一実施例の構成の説明図を示す。
仮想ＫＢＣ２以外の機能ブロックは、図２の中で、仮想ＫＢＣ２と直接関係のあるもののみ示している。
前記したように、仮想ＫＢＣ２は、受信部１０１，送信部１０２，認証部１０３，鍵交換部１０４，暗号部１０５，記憶部１０６とを備える。

受信部１０１は、認証ドライバ１７が受信した情報（たとえば、キー入力情報，マウス入力情報）を受理し、その受信情報を、ＯＳ（２または３）に与える部分である。
この発明では、２つのＯＳがあるので、受信情報を与える方法として、次の４通りが考えられる。
受信部１０１が受信した情報を、従来ＯＳとＴ−ＯＳの両方に与える場合（ケース１）、Ｔ−ＯＳのみに与える場合（ケース２）、従来ＯＳのみに与える場合（ケース３）、Ｔ−ＯＳには受信したすべての情報を与え、かつ従来ＯＳには一部のデータのみを与える場合（ケース４）がある。
この４つのケースのどれを採用するかは、予め固定的に初期設定してもよいが、Ｔ−ＯＳのＫＢＣドライバ２（３４）から与えられる選択信号（図示なし）により決定してもよい。

ケース４の場合、従来ＯＳにどの一部のデータを与えるかは、たとえば、ＫＢＣドライバ２（３４）からの指示情報に基づいて決定してもよい。
たとえば、その指示情報に、受信部が受信した情報のうち従来ＯＳに与えてはいけない情報が含まれている場合、その情報（たとえば個人情報）を削除した残りの受信情報を、従来ＯＳに与えるようにする。

仮想ＫＢＣ２へ表示要求を送信してくる送信元は、従来ＯＳ（２）の管理下で動作する機能モジュール（アプリケーションプログラム）と、Ｔ−ＯＳ（３）の管理下で動作する機能モジュール（アプリケーションプログラム）の２つである。
送信部１０２は、Ｔ−ＯＳおよび従来ＯＳからの表示要求に対応して作成された要求コマンドを受け、その要求コマンドに基づいて処理を実行する部分である。要求コマンドに基づいた処理とは、たとえば、要求コマンドが単純に表示装置８への表示要求である場合には、その要求コマンドをそのまま認証ドライバ１７へ送信する。
また、要求コマンドが出力部５へのアクセスを含むものである場合には、その要求コマンドの内容を解析することを認証部１０３に要求する。

具体例としては、Ｔ−ＯＳのＫＢＣドライバ２（３４）から送られてきた要求コマンドが、アドレスとそのアドレスに書き込むデータで構成されている場合、アドレス範囲が例えば0x0000〜0x1000という特定領域へのアクセスコマンドであれば、その要求コマンドを送信してきたソフトウェアの認証を行うよう、認証部１０３へ要求する。
また、仮想ＫＢＣ１（１３）を介して従来ＯＳのＫＢＣドライバ１（２１）から送られてきたコマンドが、出力部5へアクセスするような特定領域への要求コマンドであれば、その要求コマンドは受理せず、認証部１０３に対しても要求をしないようにする。すなわち、仮想ＫＢＣ１（１３）から送られてきた要求コマンドで、出力部5を制御しようとするコマンドは、キャンセルする。
これにより、従来ＯＳ下で動作する不正なソフトウェアが存在したとしても、その不正なソフトウェアによって出力部５へ表示させることを防止でき、出力部５にはＴ−ＯＳ管理下の信頼できるソフトウェアのみによる信頼できる表示が可能となる。

図３に示すように、従来ＯＳの管理下で動作するソフトウェアから表示要求があった場合は、ＫＢＣドライバ１（２１）、仮想ＫＢＣ１（１３）を介して、その表示要求に対応した要求コマンドが送信部１０２へ与えられる。
この要求コマンドは、たとえば、表示データ，出力すべきアドレス，このコマンドが仮想ＫＢＣ１から来たことを示す情報（送信元が仮想ＫＢＣ１であることを示す情報）とからなる。送信部１０２は、このコマンドの内容をチェックすることにより、従来ＯＳ側のソフトウェアから表示要求があったことがわかる。
Ｔ−ＯＳ側のＫＢＣドライバ２（３４）から、要求コマンドが与えられた場合も、同様にそのコマンドの内容をチェックすることにより、Ｔ−ＯＳ側のソフトウェアから表示要求があったことがわかる。

認証部１０３は、送信部１０２からの要求に基づいて、表示要求を送信してきた送信元のソフトウェアが信頼できるものか否か（正当か否か）を認証する部分である。この認証処理に、記憶部１０６に予め記憶された情報を用いる。
ＶＭＭ１の記憶部１０６には、Ｔ−ＯＳの管理下で動作するソフトウェアからの表示要求を管理するエージェント３１を特定する情報（以下、認証データと呼ぶ）を、予め記憶する。この認証データは、たとえば、IT管理者が、T-OS配布のときに、記憶部１０６に記録する。
また、認証部１０３は、認証のときに上記認証データと比較するデータをＴＰＭ６から取得する。比較するデータは、ＰＣの起動時に、ＴＰＭによって測定されたエージェント３１のハッシュ値であり、ＴＰＭ６のハッシュ記憶部６１に保存されているデータである。

すなわち、認証部１０３がＴ−ＯＳのエージェント３１が正当なものか否かの認証を行う場合、記憶部１０６に予め記憶された認証データと、ＴＰＭ６から取得されたエージェント３１のハッシュ値とが一致するか否かのチェックを行う。
一致しない場合は、エージェント３１が正当でないと判断され、エージェント３１からの表示要求は受理されず、出力部５にエージェントポリシーに従った表示を行う。たとえば、エージェント３１が不正な可能性があることを示す表示（!!OS!!）を行う。

一致した場合は、エージェント３１は信頼できると判断されるので、Ｔ−ＯＳからの表示要求を受理し、送信部１０２が受信した要求コマンドを、認証ドライバ１７に送信する。
このとき、受信した要求コマンドをそのまま認証ドライバ１７に送信するのではなく、暗号部１０５によって暗号化した後送信する。
暗号化するのは、必ずしも正しいVMMが動作しているとは限らないためである。もし暗号化しない場合は、不正なVMMが出力部5を自由に制御できる可能性があるからである。

暗号部１０５は、認証部１０３から得た要求コマンドを、鍵交換部１０４が取得した鍵ＫＥＹを用いて、暗号化する部分である。
鍵交換部１０４は、ＴＰＭ６の鍵記憶部６２に予め記憶されている鍵ＫＥＹを取得する部分である。また、後述するように、ＶＭＭ１などのソフトウェアが起動されたときに実行される鍵交換処理の中で、生成された鍵ＫＥＹを、ＴＰＭ６に送信する部分である。

認証部１０３は、上記したような認証が成功した場合、まず鍵交換部１０４を介して、鍵記憶部６２に記憶された鍵ＫＥＹを取得させる。次に、送信部１０２から与えられた要求コマンドを暗号部１０５に与えると、暗号部１０５は、その要求コマンドを、取得された鍵ＫＥＹで暗号化する。暗号化された要求コマンドは、認証ドライバ１７に与えられ、さらに、ＫＢＣチップ４に送信される。
ここで、エージェント３１から送信部１０２に与えられる要求コマンドのうち、出力部５へ出力される特定領域へのアクセスを示す要求コマンドとは、たとえば、特定領域を示すアドレス(例えば0x0000〜0x1000)，書き込みを示すフラグ，出力部5に手渡す表示データのような情報から構成されるデータである。

また、ＫＢＣチップ４では、認証ドライバ１７から送信された表示データ（暗号化された要求コマンド）を受信すると、復号部４１によって、その表示データを復元する。
このとき、鍵受理部４２によってＴＰＭ６の鍵記憶部６２から鍵ＫＥＹを取得させ、復号部４１は、取得された鍵ＫＥＹを用いて、表示データを復元する。
復元された表示データには、たとえば、状態表示部51で表示するアイコン種別・数値，キーボード表示部52のLED色などの情報が含まれる。
報知出力部４３は、これらの情報から出力部５に与える報知情報（状態表示情報）を生成し、出力部５へ送る。たとえば、状態表示部５１に、Ｔ−ＯＳからの表示要求があったことをアイコンで表示するための状態表示情報を生成し、状態表示部５１へ送信する。
以上が、仮想ＫＢＣ２（１５）と、それに関連する機能ブロックの概略動作説明である。

なお、認証部１０３が行う認証処理において、比較する一方のデータとして、記憶部１０６に予め記憶しておいた認証データを用いたが、これに限るものではない。
ＰＣの出荷時に、記憶部１０６などに予め記憶しておいたアクセス先情報（ＵＲＬ）を読み出して、そのＵＲＬに示された外部ＰＣにアクセスして、比較するべき認証データ（ハッシュ値）を取得してもよい。

＜鍵交換処理＞
ここでは、ＯＳやＶＭＭ１などのシステムの管理ソフトウェアが起動された直後や、Sleep状態からの復帰などの指定イベントが発生したときに実行される鍵交換処理について説明する。
この鍵交換処理は、ＶＭＭ１の仮想ＫＢＣ２（１５）と、ＫＢＣチップ４とで用いる共通の鍵ＫＥＹを生成し、両者で共有できるように、ＴＰＭ６の鍵記憶部６２に鍵ＫＥＹを保存する処理である。

図５に、この発明の鍵交換処理の一実施例のフローチャートを示す。
この処理は、仮想ＫＢＣ２が実行する処理である。
まず、ステップＳ１１において、TPMチップが生成する乱数を用いて共通鍵ＫＥＹを生成し、ＴＰＭチップ６に対して、共通鍵ＫＥＹを書込む命令を送信する。
ＴＰＭ６と仮想ＫＢＣ２とがＧＰＩＯバスで接続されている場合は、ＧＰＩＯバス経由で送信される。
書込み命令を受信したＴＰＭ６は、その書込み命令が正当なものか否かチェックする。このチェックは、ＴＰＭ６内のＣＰＵによって、所定の２つのハッシュ値を比較することによって行われる。

比較する一方のハッシュ値は、ＰＣの出荷前に、ＶＭＭ１の状態を示すハッシュ値を測定し、その測定値をＴＰＭに予め記憶したものである。他方のハッシュ値は、VMM1が起動する前に、BIOSによってそのコード全体が測定され、その結果であるハッシュ値がBIOSからＴＰＭ６に与えられたものである。
この２つのハッシュ値が一致した場合、ＴＰＭ６への書込み命令が正当なものであると判断され、鍵ＫＥＹの書込みが許可される。許可された場合、ＴＰＭ６の鍵記憶部６２に鍵ＫＥＹが書込まれ、許可したことが、ＴＰＭ６から仮想ＫＢＣ２へ通知される。
一方、一致しなかった場合は、書込みが許可されなかったことが、ＴＰＭ６から仮想ＫＢＣ２へ通知される。一致しなかった場合は、たとえば、ＶＭＭ１そのものが不正なソフトウェアである可能性がある。
ステップＳ１２において、ＴＰＭ６からの通知を確認することによりＴＰＭ６への書込みアクセスが許可されたか否かチェックされる。仮想ＫＢＣ２が許可されたことを認識すると、ステップＳ１３へ進み、そうでない場合は、ステップＳ１４へ進む。

ステップＳ１３において、ＧＰＩＯバス経由で鍵交換部104がＫＢＣチップ４と通信を行い、共通鍵ＫＥＹの共有に成功したことを、認証部103に通知する。
さらに、ステップＳ１５へ進み、予め設定されていた一定時間が経過したか否か、あるいは、指定したイベント（たとえばPCがSleep、休止状態，再起動処理）が発生したか否かチェックする。
指定イベントの発生あるいは一定時間が経過した場合には、ステップＳ１１へ戻り、同様の処理を繰り返し、共通鍵ＫＥＹを更新する。

ステップＳ１２で、書込みが許可されなかった場合、すなわちＴＰＭ６から不許可が通知された場合、ステップＳ１４において、ＴＰＭ６に対するアクセスが拒否されたことを示す情報を生成する。そして、鍵交換で異常のあったことを、仮想グラフィック２（１４）に送信し、表示装置８にその旨を表示させてもよい。

また、ＴＰＭ６に予め記録されていたハッシュ値が正しくないので、ＰＣベンダから正常な設定値をダウンロードして更新するようにユーザに促す表示を行ってもよい。
これによれば、ＰＣのユーザは、ＰＣの起動時等において、ＰＣの異常を知ることができ、実際の表示要求をする前の段落で、不正なＶＭＭ１あるいはＶＭＭ１内に存在する不正なソフトウェアによる不正アクセスを未然に防止できる。
また、鍵交換処理で、共通鍵の共有が成功した場合には、以後、ＫＢＣチップ４を介して、出力部５への報知出力（状態表示制御）が可能となる。

＜エージェントの状態表示制御処理＞
ここでは、Ｔ−ＯＳの管理下で動作するアプリケーションプログラムの１つであるエージェント３１の動作について、説明する。
エージェント３１は、Ｔ−ＯＳ３が起動された後に、Ｔ−ＯＳ３によって自動的に初期化され起動される。
図６に、この発明のエージェントの状態表示制御処理のフローチャートを示す。
ステップＳ２１において、Ｔ−ＯＳ管理下のアプリケーションプログラム（アプリソフト）から、表示要求、すなわち仮想グラフィック２（１４）への表示データの書込み要求があるか否か常にチェックする。要求があった場合は、ステップＳ２２へ進む。

ステップＳ２２において、表示要求（仮想グラフィック２への書込み要求）をしたアプリケーションプログラム（アプリソフト）の検査をする。具体的には、アプリケーションプログラムについている信頼された機関から発行された署名を読み出し、実行しようとしているアプリソフトのハッシュ値と比較して、正当であるか否かのチェックを行う。各アプリソフトのハッシュ値は、その起動時にエージェント３１によって測定され、ＴＰＭ６のハッシュ記憶部６１に保存されている。
署名されたものである場合は、エージェント３１は署名からハッシュ値を読み出し、ＴＰＭ６に保存しておいたハッシュ値と比較し一致すれば、そのアプリソフトは署名された正常なものであることを示す検査結果を返す。

一方、署名されたものでない場合は、エージェント３１は、そのアプリソフトは正常なソフトでないことを示す検査結果を返す。
ステップＳ２３において、署名から読み出したハッシュ値と、ＴＰＭから読み出したハッシュ値をチェックする。正常でないという結果であれば、ステップＳ２６へ進み、正常であるという結果であればステップＳ２４へ進む。

正常な場合、ステップＳ２４において、図４に示したエージェントポリシーを参照し、識別情報と色情報を生成する。ここで、識別情報とは、たとえば状態表示部51に表示するアイコン，ランダムな数値を意味する。色情報とは、たとえばキーボード表示部52のどのLEDを光らせるか、LEDの色、またその点灯パターン命令を意味する。
たとえば、T-OS上で正当なアプリソフトがメッセージを出した場合は、図４のエージェントポリシーに照らし合わせて、識別情報として、ランダムな数値からなるデータを生成する。また、色情報としては、Trustedランプ，常時点灯命令からなるデータを生成する。

次に、ステップＳ２５において、生成した識別情報を、仮想ＫＢＣ２（１５）と、仮想グラフィック２（１４）へ送信する。
仮想ＫＢＣ２へ送信された識別情報は、この後、仮想ＫＢＣ２の暗号部105で暗号されて、KBCチップ4経由で出力部5に手渡される。
一方、仮想グラフィック２（１４）へ送信された識別情報は、仮想グラフィック2で暗号化されて、TFB72に書き込みされる。

次に、ステップＳ２８において、Ｔ−ＯＳ管理下のアプリソフトによる表示要求（仮想グラフィック２への書込み）が終了したか否か、チェックする。書込みが終了していない場合は、ステップＳ２４へ戻り、同様の処理を繰り返す。表示要求の送信がすべて終了した場合は、ステップＳ２９へ進む。
ステップＳ２９では、出力部5を正当なアプリケーション表示がない時の状態に再設定するため、ステップＳ２４に示したのと同様の処理をする。すなわち、検査結果とエージェントポリシーを参照して、識別情報と色情報を生成する。
さらに、ステップＳ３０において、出力部5を正当なアプリケーション表示がない時の状態に再設定するのため、ステップＳ２５と同様の処理をする。すなわち、識別情報を仮想ＫＢＣ２と仮想グラフィック２へ送信する。
ステップＳ３０の後、ステップＳ２１へ戻り、以後処理を繰り返す。

また、ステップＳ２３において、検査結果が正常でなかった場合、ステップＳ２６へ進み、検査結果に問題があったことを示す識別情報を生成する。たとえば、Ｔ−ＯＳ管理下のアプリソフトに問題があることを意味するデータとして、“!!APP!!”を生成する。
ここで、識別情報には、たとえば、!!APP!!メッセージ、表示装置8に出力するより詳細なメッセージデータが含まれる。

そして、ステップＳ２７において、生成された識別情報を、仮想ＫＢＣ２と、仮想グラフィック２へ送信する。
識別情報を受信した仮想ＫＢＣ２は、識別情報の中のメッセージに基づいて出力部5を制御するコマンドを生成し、KBC4に対して発行する。これにより、出力部5に!!APP!!メッセージ表示が行われる。
一方、識別情報を受信した仮想グラフィック２は、識別情報の中のメッセージに基づいて、TFB72により詳細なメッセージを出力する。

ステップＳ２７の後、ステップＳ２１へ戻り、同様の処理を継続する。
以上がエージェントの処理の一実施例である。
このように、エージェントにおいて、表示要求をしてきたＴ−ＯＳ管理下のアプリケーションソフトが正当なものか否かの検査をしているので、Ｔ−ＯＳ管理下で動作する不正なソフトウェアが存在したとしても、その不正な表示要求などを未然に防止できる。

＜仮想ＫＢＣ２の動作フローの説明＞
図７に、仮想ＫＢＣ２の状態表示処理に関係するフローチャートの一実施例を示す。
ここでは、仮想ＫＢＣ２に対して表示要求などの要求を送信してきた要求元（送信元）をチェックし、出力部５に、チェック内容に対応した状態表示をさせる処理について説明する。
仮想ＫＢＣ２に対する要求元（送信元）は、前記したように従来ＯＳの管理下のプログラム（２）と、Ｔ−ＯＳ（３）の管理のプログラムの２つがある。
たとえば、従来ＯＳ（２）の管理下で動作する不正なアプリケーションソフトによる表示要求であり、その表示要求は、仮想ＫＢＣ１（１３）を介して、仮想ＫＢＣ２の送信部１０２へ与えられる。

また、もう一つはＴ−ＯＳ（３）の管理下で動作するアプリケーションソフトからの表示要求であり、その表示要求は、エージェント３１，ＫＢＣドライバ２（３４）を介して、仮想ＫＢＣ２の送信部１０２へ与えられる。
送信部１０２は、与えられた表示要求に含まれるデータ内容をチェックして表示要求がどちらからあったかを判断する。あるいは、従来ＯＳからの表示要求とＴ−ＯＳからの表示要求がハードウェア的に異なるポートから与えられる場合は、そのポートを認識することにより、どちらの表示要求かがわかる。

たとえば、仮に仮想ＫＢＣ１（１３）から、表示装置８のＴ−ＯＳ枠８２への不正な表示要求があったような場合は、そのような表示要求は認められていないので、以後の処理を中止する必要がある。
また、仮に仮想ＫＢＣ１（１３）から、出力部５の状態表示部５１への不正な表示要求があったような場合も、その表示要求は認められないので、以後の処理を中止する必要がある。

さらに、Ｔ−ＯＳ側のエージェント３１から仮想ＫＢＣ２へ送信要求があった場合においても、そのエージェントそのものが不正なソフトウェアによってなりすまされている可能性があるので、エージェント３１が不正なソフトウェアでないことをチェックする必要もある。
図７に示した仮想ＫＢＣ２の以下の処理では、このような不正アクセスを検出し未然に防止するとともに、出力部５に対して必要な状態表示を行う。

図７のステップＳ４１において、仮想ＫＢＣ２の呼び出しがあったか否かチェックする。呼び出しがあるまで、チェックを繰り返す。ここで、仮想ＫＢＣ２の呼出とは、KBCドライバ2(34)からの呼び出し,仮想KBC1からの呼び出しを意味する。
たとえば、Ｔ−ＯＳ管理下のエージェント３１から、表示要求があったか否かチェックする。これは、上記したように、送信部１０２が、仮想ＫＢＣ１（１３）から何らかの要求コマンドを受信したか、あるいはＫＢＣドライバ２（３４）から表示要求のコマンドを受信したかで、判断する。
ステップＳ４２において、呼び出しがあったが、その呼出元が仮想ＫＢＣ１（１３）か、そうでないかを判断する。
呼出元が仮想ＫＢＣ１（１３）である場合は、ステップＳ４７へ進む。そうでない場合は、Ｔ−ＯＳ側のエージェント３１からの表示要求であるので、ステップＳ４３へ進む。

ステップＳ４７において、仮想ＫＢＣ１から送信された表示要求コマンドのデータ内容をチェックし、その表示要求に従った表示要求処理をする。このとき状態表示命令データを認証ドライバ１７に送信する。
ただし、仮想ＫＢＣ１からの表示要求のうち、出力部５へ直接表示する要求は認められていないので、そのような出力部への不正表示を求めるデータは無視あるいは削除する。

仮想ＫＢＣ１から送られてくる表示要求のデータ内容は、たとえば仮想KBC1を示すフラグ，書き込み先アドレス，書込データから構成される。不正表示要求か否かは、この中のアドレスをチェックする。このチェックをした時、アドレスが出力部5への書き込みであることが認められた場合、それは不正な表示要求と判断されるので、破棄をする。
一方、仮想ＫＢＣ１から送られてきたデータ内容が、仮想KBC1を示すフラグ，出力部5以外を示すアドレス，書込データであったとする。このとき、仮想ＫＢＣ１からの表示要求は、正常なものであるので、たとえば、KBCチップ4に対する書込アドレス，書込データからなる状態表示命令データを生成し、認証ドライバ１７へ送信する。

たとえば、従来ＯＳ管理下の正常なアプリソフトからの表示要求のみがあり、Ｔ−ＯＳ管理下のソフトウェアからの表示要求がない場合は、T-OSからの表示要求終了時に、図4に示したエージェントポリシに従って生成した識別情報を保持し続ける。

この状態表示命令データを受信した認証ドライバ１７は、そのままＫＢＣチップ４へ与えるか、あるいは、その命令を解釈して出力部５に状態表示ができる形式に変換した後、表示命令をＫＢＣチップ４へ与える。
ＫＢＣチップ４は、与えられた表示命令に従って、出力部５への表示を制御する。
たとえば、従来ＯＳ管理下のアプリソフトによる表示要求のみで、Ｔ−ＯＳ側からの表示要求がない場合は、状態表示部５１には何も表示しないように制御するか（すなわち表示消去処理）、または「Un-Trust」というメッセージかあるいは所定のアイコンを表示させる。

一方、ステップＳ４３において、エージェント３１からの表示要求があった場合には、認証部１０３がエージェント３１が正常なものであるかどうかの検査を行う。
認証部１０３によるエージェントの検査は、前記したように、記憶部１０６に予め記憶されていたエージェントの認証データと、ＴＰＭ６から取得したエージェント３１に関係するハッシュ値とを比較することにより行う。一致すれば、エージェントの検査が成功（エージェントは正常）したことになる。一致しない場合は、エージェント３１そのものが正常でないと判断され、認証が失敗したことになる。
ステップＳ４４において、エージェント３１が正常と判断された場合は、ステップＳ４５へ進み、正常でない（認証が失敗した）と判断された場合は、ステップＳ４６へ進む。

ステップＳ４５において、認証部１０３は、エージェント３１から送信されてきた表示要求に従った状態表示要求処理をする。送信部１０２から表示要求データを受け取り、表示要求データを暗号化して、認証ドライバ１７へ送信する。
たとえば、エージェント３１から送信されてきた表示要求が、書込アドレス，識別情報を含むデータであったとする。この中のアドレス範囲から出力部５の状態表示部５１への表示要求であることがわかる。

認証部１０３は、暗号化のための鍵ＫＥＹを取得するため、鍵交換部１０４に鍵の取得要求を出す。
鍵の取得要求を受けた鍵交換部１０４は、ＴＰＭ６に対し、共通鍵ＫＥＹを出力する指示を出力する。ＴＰＭ６はこの指示が正当であることを確認し、正当な場合は、共通鍵ＫＥＹを出力する。これにより、認証部はＴＰＭの鍵記憶部６２に記憶されていた鍵ＫＥＹを取得する。
その後、認証部１０３は、取得された鍵ＫＥＹと、暗号化すべき表示要求のデータ内容を暗号部１０５へ与える。
なお、鍵の取得は、鍵交換部１０４を介さずに、認証部１０３が、直接ＴＰＭ６にアクセスして行ってもよい。

暗号部１０５は、表示要求のデータ内容を、鍵ＫＥＹで暗号化し、認証ドライバ１７へ送信する。
この後、認証ドライバ１７は、暗号化された表示要求データを受信すると、このデータをＫＢＣチップ４へ送信する。ＫＢＣチップ４は、暗号化された表示要求データを受信すると、復号部４１によって、このデータを復元する。
このとき、鍵受理部４２を介して、ＴＰＭ６から共通鍵ＫＥＹを取得し、共通鍵ＫＥＹを用いて、暗号化された表示要求データを復元する。

復元された表示要求データは、表示できる状態表示情報に変換された後、報知出力部４３から出力部５へ出力される。そして、出力部５は、状態表示情報に基づいて、状態表示部５１およびキーボード表示部５２に対して、要求されたとおりの状態表示を行う。
たとえば、Ｔ−ＯＳのアプリソフトからＴ−ＯＳ枠８２への表示要求があり、エージェント３１から出力部5へのランダム数値，Trustedランプ点灯の表示要求があった場合には、状態表示部５１にランダム数値の表示を行い、またキーボード表示部５２にあるTrustedランプ点灯を行う。

一方、ステップＳ４６において、このときエージェント３１が正常でないと判断されているので、エージェントが正常でないこと（問題があること）を示す状態表示の要求処理をする。すなわち正常でないことを報知するための状態表示要求データを認証部103が生成し、暗号部105が暗号して認証ドライバ１７へ送信する。
たとえば、状態表示要求データとしては、“!!OS!!”のようなメッセージを状態表示部５１に表示させるためのデータを生成する。

その後、認証ドライバ１７はエージェントが正常でないことを示す状態表示要求データをＫＢＣチップ４に送信する。
ＫＢＣチップ４は、そのデータを解釈して、復号部４１を介して、状態表示部５１へ表示できる表示データに変換して、報知出力部４３から出力する。
これにより、状態表示部５１に、エージェントが正常でないことがわかる状態表示がされ、ユーザは表示装置８に現在表示されている画面があやしいことなどを認識することができる。

＜ＫＢＣチップの状態表示処理＞
ＫＢＣチップ４は、前記したように、通常キーボードやマウスなどの種々の入出力デバイスの制御および監視を行うＬＳＩであるが、この発明では、このような通常の機能の他に、出力部５に対する状態表示制御処理を行う。
状態表示制御処理では、上記したように、認証ドライバ１７から送信されてくる状態表示要求データに基づいて、出力部５に表示させる形式の表示データを生成し、その表示データに基づいて、出力部５を制御する。受信した状態表示要求データが、暗号化されている場合は、ＴＰＭ６から共通鍵ＫＥＹを取得して要求データを復元してから、表示データを生成し、出力部５を制御する。

ただし、出力部５に、状態表示をさせる必要のない場合は、通常の入出力デバイスの制御だけを行うようにし、状態表示制御処理を停止させるようにしてもよい。
たとえば、ＫＢＣチップ４に、ＶＭＭ設定フラグＶＦを記憶するメモリ領域を設け、このフラグＶＦの値が０の場合は、通常の入出力デバイスの制御のみを行わせ、フラグＶＦの値が１の場合に、状態表示制御処理を起動させるようにしてもよい。
ＶＭＭ設定フラグＶＦは、状態表示制御処理の実行の有無を判断するフラグである。
状態表示をさせる必要のない場合とは、たとえば、意図的にＴ−ＯＳを起動させないときを意味する。

このＶＭＭ設定フラグＶＦは、たとえば、ＰＣの電源投入時に、ＢＩＯＳによって設定させるようにしてもよい。
電源を投入した直後に、まずＢＩＯＳが起動され、ＢＩＯＳは、ＢＩＯＳ設定値を用いて組み込まれたハードウェアデバイスを順に起動させ、初期化する。
ＫＢＣチップ４も初期化されるハードウェアデバイスの１つであるので、その初期化のときに、ＫＢＣチップ４のＶＭＭフラグＶＦのメモリ領域に、０または１を設定するようにすればよい。
ところで、Ｔ−ＯＳの起動の許可または禁止は、ユーザのＢＩＯＳ設定によって可能である。ＢＩＯＳ設定値として、Ｔ−ＯＳが起動するように設定されている場合は、ＢＩＯＳは、ＫＢＣチップ４のＶＭＭフラグＶＦを‘１’にセットする。一方、Ｔ−ＯＳが起動しないように設定されている場合は、ＢＩＯＳは、ＫＢＣチップ４のＶＭＭフラグＶＦを‘０’にセットする。

図８に、ＫＢＣチップの状態表示制御処理の一実施例のフローチャートを示す。
まず、ステップＳ５１において、ＫＢＣチップ４のＶＭＭ設定フラグＶＦの値が‘１’か否か確認する。１の場合状態表示制御処理を実行するために、ステップＳ５２へ進む。
一方、１でない場合（たとえば０の場合）、ステップＳ５７へ進み、状態表示制御処理を停止させるために、出力部の状態表示部５１などへの表示アクセスを禁止（Disable）し、通常の入出力デバイスの制御および監視動作のみを実行する。その後ステップＳ５１へ戻り、処理を繰り返す。

ステップＳ５２において、ＧＰＩＯバスから、鍵書込処理が発生したか否かチェックする。この鍵書込み処理が発生したか否かは、TPM6とGPIOバスで結線されているKBCチップ4のI/Oピンを監視し、アクセスの有無をチェックすることにより判断する。アクセスの有無は、KBCチップ4内のレジスタに保持される。たとえば、アクセスがあれば1、なければ0を保持する。
鍵書込処理は、たとえば、PC起動時やSleep、休止状態からの復帰時に発生する。
鍵書込処理が発生した場合、ステップＳ５５へ進み、共通鍵ＫＥＹを生成し、ＴＰＭ６に対し、共通鍵ＫＥＹの書込み要求を出力する。
すなわち、共通鍵ＫＥＹの生成は、前記した図５のように、仮想ＫＢＣ２（１５）がする場合もあるが、ＫＢＣチップ４がする場合もある。どちらが生成したとしても、その共通鍵ＫＥＹは、ＴＰＭ６に保存され、以後ＫＢＣチップ４と仮想ＫＢＣ２（１５）とで共有される鍵となる。

ステップＳ５６において、出力部５の状態表示部５１やキーボード表示部５２に表示されている状態を初期化する。
たとえば、状態表示部５１に、ＶＭＭに異常が発生していることを示す表示（!!VMM!!）などがされている場合、その表示を消去する。
その後、ステップＳ５１へ戻り、処理を繰り返す。

ステップＳ５２において、鍵書込処理が発生していない場合、ステップＳ５３へ進み、認証ドライバ17からＫＢＣ制御コマンドが受信されるか否か、チェックする。ＫＢＣ制御コマンドとは、前記した認証ドライバ１７から送信される状態表示要求データも含まれる。
ＫＢＣ制御コマンドが受信されない場合は、ステップＳ５２へ戻り、処理を繰り返す。

一方、受信された場合は、ステップＳ５４へ進み、その受信されたＫＢＣ制御コマンドに対応した制御を実行する。その後、ステップＳ５１へ戻り処理を繰り返す。
ステップＳ５４では、たとえば、認証ドライバ１７から状態表示要求データを受信した場合は、その内容を解釈し、前記したように必要に応じて、データの復元を行い、出力部５に対する状態表示制御を行う。

また、KBC4チップ内のGPIOバスからのアクセス有無を示すレジスタ値が、アクセス無しを指していれば、VMMに異常が発生したことを示す識別情報を出力部5に表示させる。たとえば、KBCチップ内レジスタにおいて、TPM6と結線されているGPIOバスからのアクセス無しを示す0を保持しているときに、認証ドライバ17から出力部5への書込データを受信した場合には、不正なVMMの起動があったと判断し、ＶＭＭ１に異常があったことを示す状態表示（“!!VMM!!”）を、状態表示部５１に表示させる表示データを生成し、出力部５へ送信する。

なお、ＶＭＭ設定フラグＶＦが１の場合、ＫＢＣチップ４は状態表示要求に関係するＫＢＣ制御コマンドのみを受理するものとし、通常の入出力デバイスを制御するＫＢＣ制御コマンドは無視するかまたは受理してもこれを異常として処理してもよい。この場合、フラグＶＦ＝１のときに、通常の入出力デバイスを制御するＫＢＣ制御コマンドを受信したとすると、ステップＳ５４において、ＶＭＭ１に異常があったことを示す状態表示をしてもよい。
以下に、状態表示の表示制御の具体例を説明する。

＜表示例１：正常動作の場合＞
ここでは、Ｔ−ＯＳの管理下で動作する正当なアプリケーションプログラムによって、表示装置８のＴ−ＯＳ枠８２への表示要求がされ、エージェント３１から、状態表示要求がされた場合について示す。
図９に、この表示例１の説明図を示す。
出力部５の状態表示は、Ｔ−ＯＳからの正常なアプリソフトによる表示要求があり、かつ、従来ＯＳの管理下の正常なアプリソフトからも表示要求がある場合を示している。
このとき、状態表示部５１に、Ｔ−ＯＳ管理下の正常なソフトウェアによる表示がされていることを意味する番号（ここでは４９２）を表示し、キーボード表示部５２には、Ｔ−ＯＳ枠８２に表示された画面がＴ−ＯＳ管理下の正常なソフトウェアによる表示であることを意味するTrustedランプを点灯させる。

これは、不正なソフトウェアが存在しない場合の例であるが、従来ＯＳ管理下のアプリソフトから要求される表示データは、表示メモリ領域７０の中のＵＴＢＦ７１に展開され、表示装置８の従来ＯＳ枠８１の中に、表示される。
一方、Ｔ−ＯＳ管理下のアプリソフトから要求される表示データは、表示メモリ領域７０の中のＴＢＦ７２に展開され、表示装置８のＴ−ＯＳ枠８２の中に表示される。
また、Ｔ−ＯＳ管理下のアプリソフトから表示要求があると、図６のステップＳ２２において、エージェント３１が、このアプリソフトの署名をチェックする。署名確認で、アプリソフトが正常なものであると判断されると、図６のステップＳ２４で識別情報が生成される。

そして、エージェント３１は、この識別情報を、仮想ＫＢＣ２と仮想グラフィック２へ送信する（ステップＳ２５）。
この後、仮想ＫＢＣ２は、図７のステップＳ４３に示すように、エージェント３１の検査を行う。この検査では、前記したように、エージェントに関する２つのデータの比較を行う。
図９の表示例１の場合、エージェントも正常であるとすると、ステップＳ４５の状態表示要求処理を行う。

ここで、識別情報を基に、ＫＢＣチップに送る表示要求データを作成し、暗号化した後、認証ドライバ１７へ送る。
図９の表示例１の場合は、たとえば、表示要求データの中に、ランダムに生成された数値，Trustedランプに対する点灯命令が含まれる。
暗号化された表示要求データは、認証ドライバ１７から、ＫＢＣチップ４へ送られ、図８のステップＳ５３において、そのデータがＫＢＣ制御コマンドの一つであると判断されると、復号した後、表示要求データの中の情報に基づいて、出力部に状態表示をする（ステップＳ５４）。

図９の場合は、表示要求データの中に含まれるランダムに生成された数値に基づいて、状態表示部５１に、「４９２」という数字を表示させる。また、表示要求データの中のTrustedランプに対する点灯命令に基づいて、キーボード表示部５２のTrustedランプを点灯させる。

＜表示例２：正常動作の場合＞
ここでは、Ｔ−ＯＳの管理下で動作する正当なアプリケーションプログラムによる表示要求がない場合で、従来ＯＳからの正常なアプリソフトによる表示要求がある場合について示す。
図１０に、この表示例２の説明図を示す。
このとき、状態表示部５１には、何も表示しない。言いかえれば、すべての表示を消去する。これにより、表示装置のＴ−ＯＳ枠８２には、Ｔ−ＯＳ管理下の正常なソフトウェアによる表示は行われていないことを示す。
また、キーボード表示部５２のTrustedランプも消灯させる。

すなわち、出力部５の表示がないときは、現在Ｔ−ＯＳ管理下のソフトウェアによる表示要求はないはずなので、もし、表示装置８に、Ｔ−ＯＳ枠８２が表示され、その枠内に画面が表示されていた場合は、その表示は何らかの不正ソフトウェアがどこかにインストールされていることによる不正な表示であると考えることができる。

図１０において、Ｔ−ＯＳの管理下で動作するアプリソフトによって表示されるデータはないので、表示メモリ領域７０のＴＢＦ７２には、何も展開されない。したがって、表示装置８には、Ｔ−ＯＳ枠８２は表示されず、その中に表示される画面もない。
従来ＯＳからの正常な表示要求があれば、その表示データがＵＴＢＦ７１に展開されて、表示装置８には、従来ＯＳ枠８１の中にその表示データが表示されるだけである。

この表示例２では、Ｔ−ＯＳ管理下のアプリソフトから表示要求はないので、エージェント３１は、ステップＳ２１の処理を繰り返す。
一方、従来ＯＳのアプリソフトから表示要求があるので、その表示要求により、仮想ＫＢＣ１を介して、仮想ＫＢＣ２が呼び出される（図７のステップＳ４２）。
この場合、たとえば、仮想ＫＢＣ１から仮想ＫＢＣ２に対して、仮想KBC1を示すフラグ，書き込み先アドレス，書込データからなる表示要求データが与えられる。

図７のステップＳ４７において、仮想ＫＢＣ２は、この表示要求データのうち、書込先アドレス，書込データに基づいて、状態表示命令データを作成する。
図１０の表示例２の場合は、状態表示部５１の表示を消去し、キーボード表示部５２のTrustedランプを消灯させることを意味する命令データが作成される。そしてこの命令データが認証ドライバ１７を介して、ＫＢＣチップ２へ送信される。
ＫＢＣチップ２において、受信された命令データはＫＢＣ制御コマンドの一つと判断されて、図８のステップＳ５４において、この命令データに基づく状態表示制御がされる。これにより、出力部５には、表示例２の図１０に示したような表示がされる。

＜表示例３＞
ここでは、不正なソフトウェアが従来ＯＳの管理下で動作しており、Ｔ−ＯＳ管理下のアプリケーションからは表示要求がない場合について説明する。この不正なソフトウェアは、Ｔ−ＯＳ枠８２を偽り、Ｔ−ＯＳ枠８２とともに、その枠の中に不正な表示をするものとする。
図１１に、表示例３の説明図を示す。
表示例３では、図１１に示すように、状態表示部５１には、「Un-trust」という文字を表示し、キーボード表示部５２のTrustedランプは消灯させる。

状態表示部５１の表示「Un-trusted」は、現在Ｔ−ＯＳからの表示要求はなく、従来ＯＳからの表示要求があり、表示装置８には、ＵＴＢＦ７１に展開された表示データの表示がされていることを意味する。
また、キーボード表示部５２のTrustedランプが消灯しているのは、図１０と同様に、Ｔ−ＯＳからの表示要求はなく、したがって、Ｔ−ＯＳ管理下の正常なアプリソフトによる表示データはないので、Ｔ−ＯＳ枠８２が表示されず、そのＴ−ＯＳ枠８２内への表示データの表示もないはずであることを示している。

この表示例３において、もし、従来ＯＳ管理下の不正アプリソフトが表示要求をした表示データが、図１１に示すようにＵＴＢＦ７１に展開されたとすると、表示装置８には、あたかも従来ＯＳ枠８１とＴ−ＯＳ枠８２とが表示され、なおかつどちらの表示枠の中にも表示データが表示されているような画面が表示される。
ユーザは、この表示装置８の画面を見ただけでは、不正なＴ−ＯＳ枠８２に、不正な表示がされていることがわからない場合がある。

しかし、表示例３の場合は、出力部５の２つの状態表示を見れば、Ｔ−ＯＳ枠８２とその表示内容は正常なアプリソフトによって表示されたものではないことがわかる。そこで、ユーザは、状態表示を確認することにより、偽りのＴ−ＯＳ枠８２に表示されている画面に対して、うっかり重要な個人データなどを入力するのを未然に防ぐことができる。

実施例３の場合は、Ｔ−ＯＳからの表示要求がないので、エージェントは、図６のステップＳ２１を繰り返す。
一方、従来ＯＳ管理下のアプリソフトから表示要求があるので、仮想ＫＢＣ２は、図７のステップＳ４２において仮想ＫＢＣ１からの呼出があったと判断し、ステップＳ４７の処理を実行する。
この実施例３の場合は、エージェント３１は、アプリソフト監視によってＴ−ＯＳからの表示要求はなく、従来ＯＳからの表示要求のみがあることがわかるので、状態表示部５１に、「Un-trust」を表示させ、キーボード表示部５２のTrustedランプを消灯させることを意味する状態表示命令データを作成し、認証ドライバ１７に送信する。

この後、状態表示命令データは、認証ドライバ１７を介して、ＫＢＣチップ４に送信される。ＫＢＣチップ４では、図８のステップＳ５２，Ｓ５３およびＳ５４の処理が実行され、出力部５に図１１に示したような状態表示がされる。

＜表示例４＞
ここでは、Ｔ−ＯＳからの正常アプリソフトによる表示要求はなく、ＶＭＭ１の中に、不正なソフトウェアモジュールＳＭが存在し、そのソフトウェアモジュールＳＭが、ＴＦＢ７２を利用して、表示装置８にＴ−ＯＳ枠８２とその枠内への画面表示をしている場合について説明する。
また、従来ＯＳからの正常アプリソフトによる表示要求があるものとする。ただし、この表示要求がない場合は、従来ＯＳ枠８１の表示がない点が異なるだけで、出力部５の表示は、この表示例４と同様である。
図１２に、表示例４の説明図を示す。
この場合は、状態表示部５１に、ＶＭＭ１に異常が発生していることを示す「!!VMM!!」を表示し、キーボード表示部５２のTrustedランプを消灯させる。

このとき、ユーザは状態表示部５１の表示内容を見れば、ＶＭＭ１が異常であることがわかる。したがって、現在表示装置８に表示されている画面は信用できないことがわかり、ユーザが重要なデータを入力するのを未然に防ぐことができる。
出荷時、およびＰＣを初めて立ち上げ処理をするときには、ＶＭＭ１には、このような不正なソフトウェアモジュールＳＭはないものとする。
また、この実施例４では、ＶＭＭ１の中に不正なソフトウェアモジュールＳＭが存在し、このソフトウェアモジュールＳＭは、出荷後ユーザが作業しているときに混入したものと考える。

そうするとこの不正なソフトウェアモジュールの存在は、ＰＣが起動させられ、さらにＶＭＭが起動して仮想ＫＢＣ２が鍵交換処理（図５）を行うときに、検出することができる。
すなわち、図５のステップＳ１１において、ＴＰＭ６に鍵の書き込み要求を行ったときに、ＴＰＭ６内で行われる書込み命令の正当性チェックによって検出される。
前記したように、このチェックでは、ＶＭＭ１の仮想ＫＢＣ２からの書込み命令が正当なものかを判断するために、出荷前にＴＰＭ６に予め記憶されたＶＭＭ１のハッシュ値を用いる。

ＶＭＭ１に不正なソフトウェアモジュールＳＭが存在しない場合は、ＢＩＯＳによって測定されたＶＭＭのハッシュ値は、ＴＰＭに予め記憶されたＶＭＭのハッシュ値と一致する。しかし、ＶＭＭ１に不正なソフトウェアモジュールＳＭが混入した場合は、ＢＩＯＳによって測定されたＶＭＭのハッシュ値は上記ＴＰＭに予め記憶されたＶＭＭのハッシュ値と異なるものになる。

したがって、２つのハッシュ値が一致しなくなるので、ＴＰＭ６のチェックで、書込み命令を許可しない旨が通知される。すなわち、図５のステップＳ１２において、ＴＰＭへの書込みが許可されなかったことが検出されるので、ステップＳ１４へ進み、書込み不許可の場合の処理をすることになる。
このステップＳ１４の処理において、仮想ＫＢＣ２は、ＶＭＭ１に異常が発生し、ＴＰＭへのアクセスが拒否されたことを示す情報を生成し、表示ドライバ16を経由して表示装置8に送信する。

一方、KBCチップ4は、BIOSによってVMM1が起動した事を示すVMM設定フラグが1になっているにも関わらず、VMM1からTPMのGPIOバスを通してのアクセスがない状態となる。その状態でKBCを初期化するコマンドを受信したＫＢＣチップ４は、出力部５の状態表示部５１に、「!!VMM!!」を表示するように、表示データを生成して、出力部５に与える。

また、この場合ＴＰＭから不許可の応答をもらうのでＶＭＭ１が正常でないことがわかり、結局Ｔ−ＯＳからの表示要求も正当なものか否か不明となるので、キーボード表示部５２のtrustedランプは消灯させることが好ましい。

＜表示例５＞
ここでは、Ｔ−ＯＳの管理下で動作するエージェント３１が不正なソフトウェアであり、この不正なエージェントからの表示要求がある場合について、説明する。また、従来ＯＳの管理下の正常なソフトウェアからの表示要求があるものとする。
図１３に、表示例５の説明図を示す。
この場合、Ｔ−ＯＳ側のソフトウェアが異常であるので、状態表示部５１に、Ｔ−ＯＳの異常が検出されたことを示す表示（たとえば“!!OS!!”）をする。
また、Ｔ−ＯＳ側の表示を管理するエージェントが不正ではあるが、その表示要求による表示データはＴＢＦ７２を介してＴ−ＯＳ枠８２に表示されるので、キーボード表示部５２のTrustedランプは点灯させる。

図１３に示すように、エージェント３１は不正なソフトウェアではあるが、あたかも正常なエージェントのように動作するとすれば、不正なエージェント３１からの表示要求は受理され、その表示要求により与えられた表示データはＴＢＦ７２に展開される。
したがって、ＴＢＦ７２に展開された表示データは、Ｔ−ＯＳ枠８２の中に表示されることになる。ただし、この場合、Ｔ−ＯＳ枠８２に表示された画面は、不正なエージェントからの表示要求であるので、不正な表示である可能性が高い。
この表示例５では、ユーザは状態表示部５１に表示される「!!OS!!」という表示内容を確認することにより、Ｔ−ＯＳに異常が発生したことを認識できる。

よって、ユーザはＴ−ＯＳ枠の表示内容は不正な可能性があるということを知ることができるので、Ｔ−ＯＳ枠内に表示される不正な表示画面に対して、重要なデータを入力することを未然に防止できる。

表示例５の場合は、図７のステップＳ４３におけるエージェントの検査により、エージェントが正常でないことが検出できる。
エージェント３１が不正なソフトウェアである場合、出荷時および初期起動時に起動させられるエージェント３１とは異なるものである。

したがって、出荷時などのエージェント３１は正規のものであり、この正規のエージェントに対応する認証データが、仮想ＫＢＣ２の記憶部１０６に予め記憶されているとすると、Ｔ−ＯＳ管理下で動作する不正エージェント３１が混入された後に、ＴＰＭで測定されるエージェント３１のハッシュ値は、認証データと異なるものとなる可能性が高い。
よって、図７のステップＳ４４で、エージェント３１が正常でないと判断された場合には、ステップＳ４６の処理が実行される。
この処理により、認証部103にてエージェント異常を示すメッセージの生成，暗号部１０５によるメッセージの暗号、暗号メッセージをKBCチップ4への送信が行われるので、図１３の表示例５に示したような表示がされる。

＜表示例６＞
ここでは、Ｔ−ＯＳの管理下で動作するアプリケーションプログラムが不正なソフトウェアであり、そのアプリケーションプログラムから不正な表示要求がある場合について、説明する。
また、従来ＯＳの管理下で動作する正常なソフトウェアからの表示要求があるものとする。
図１４に、表示例６の説明図を示す。

この場合、出力部５に表示される状態は表示例５と類似する。ただし、状態表示部５１に表示される文字情報が異なる。
エージェントの検査（図６のステップＳ２２）によって、Ｔ−ＯＳの管理下のアプリソフトが正常でないことがわかるので、図１４に示すように、たとえば「!!APP!!」という表示をする。
また、エージェントは正当なソフトウェアであるとすると、エージェントからの表示要求も正当なものであるので、Ｔ−ＯＳ枠８２へ表示する表示データはＴＢＦ７２に展開される。したがって、キーボード表示部５２のTrustedランプは点灯させる。

この表示例６の場合もユーザは状態表示部５１の「!!APP!!」という警告表示を確認することで、不正なソフトウェアが存在することを知ることができ、不正な画面表示に対して、重要なデータを入力するのを未然に防止することができる。
この表示例６の場合、不正なアプリケーションプログラムから、エージェント３１に対して、不正な表示要求が出される。表示要求そのものが不正か否かはわからないが、エージェントは、この表示要求を受理したことにより図６のステップＳ２２の処理を実行する。

すなわち、エージェント３１は、表示要求をしたアプリソフトの検査を実行する。そして、ＴＰＭ６から、アプリソフトのハッシュ値を読み込み前記したような署名チェックが行われ、表示要求をしたアプリソフトが、正常であるか否かがチェックされる。
ＴＰＭ６内のアプリソフトに関係するハッシュ値と署名内のハッシュ値が一致しないことがわかると、アプリソフトは正常でないという結果になるので、エージェントは、ステップＳ２６とＳ２７の処理を実行することになる。
ステップＳ２６では、表示要求をしたアプリソフトが正常でないことを示す識別情報が生成される。たとえば、!!APP!!という警告メッセージ，その警告メッセージの詳細、出力部5への書込アドレスなどからなる識別情報が生成される。

そして、ステップＳ２７において、生成された識別情報が仮想ＫＢＣ２へ送信される。
この識別情報をエージェントから受け取った仮想ＫＢＣ２は、図７のステップＳ４２において、ステップＳ４３へ進み、エージェントの検査をする。
エージェントが正常なものであるとすると、ステップＳ４４において、ステップＳ４５へ進み、状態表示要求処理を行う。このとき、エージェントからの表示要求には、!!APP!!という警告メッセージ，出力部5への書込アドレスなどのデータが含まれるので、図１４に示したような状態表示をするための表示データが生成され、ＫＢＣチップ４へ送信される。
これにより、出力部５には、図１４に示したような状態表示がされる。

以上のように、この発明のいくつかの状態表示の例を示したが、これに限るものではない。
その他、あらゆる機能ブロックに、種々の形態で不正なソフトウェアが侵入することが、考えられるが、前記したようなエージェントや仮想ＫＢＣ２などの状態表示の処理を行うことにより、出力部５に表示される状態表示によって、何らかの異常があることをユーザに報知することができる。
ユーザが出力部５の状態表示を確認することにより、表示装置８に正当らしき表示がされている場合でも、ユーザが重要なデータの入力をするのを未然に防止することができる。

この発明の状態表示制御装置の構成図である。 この発明の状態表示制御装置の一実施例の構成図である。 この発明の仮想ＫＢＣ２の一実施例の構成図である。 この発明のエージェントポリシー内容の一実施例の説明図である。 この発明の仮想ＫＢＣ２における鍵交換処理のフローチャートである。 この発明のエージェントの状態表示制御処理のフローチャートである。 この発明の仮想ＫＢＣ２の状態表示処理のフローチャートである。 この発明のＫＢＣチップの状態表示制御処理のフローチャートである。 この発明の状態表示の表示例１の説明図である。 この発明の状態表示の表示例２の説明図である。 この発明の状態表示の表示例３の説明図である。 この発明の状態表示の表示例４の説明図である。 この発明の状態表示の表示例５の説明図である。 この発明の状態表示の表示例６の説明図である。 従来のセキュリティシステムの概略構成の説明図である。 従来のシステムにおいて、不正ソフトウェアによる不正な表示状態の説明図である。

符号の説明

１ ＯＳ管理部（ＶＭＭ）
２ 第１ＯＳ（従来ＯＳ）
３ 第２ＯＳ（Trusted OS，T-OS）
４ 報知制御部（ＫＢＣチップ）
５ 出力部
６ ＴＰＭ
７ 表示コントローラ（グラフィックチップ）
８ 表示装置
１０ 第１表示入力部
１１ 第２表示入力部
１２ 第１描画処理部（仮想グラフィック１）
１３ 第１認証制御部（仮想ＫＢＣ１）
１４ 第２描画処理部（仮想グラフィック２）
１５ 第２認証制御部（仮想ＫＢＣ２）
１６ 表示通信部（表示ドライバ）
１７ 認証通信部（認証ドライバ）
２１ 第１通信部（ＫＢＣドライバ１）
２２ グラフィックドライバ１
３０ 表示管理部
３１ エージェント
３２ 第２通信部
３３ グラフィックドライバ２
３４ ＫＢＣドライバ２
４１ 復号部
４２ 鍵受理部
４３ 報知出力部
５１ 状態表示部
５２ キーボード表示部
６１ ハッシュ記憶部
６２ 鍵記憶部
７０ 表示メモリ領域
７１ ＵＴＦＢ
７２ ＴＦＢ
８１ 従来ＯＳ枠
８２ Ｔ−ＯＳ枠
１０１ 受信部
１０２ 送信部
１０３ 認証部
１０４ 鍵交換部
１０５ 暗号部
１０６ 記憶部

Claims (11)

1. 第１基本機能管理部の管理下で動作する、予め信頼性が確認されたモジュールからの表示要求に基づいて、第１表示枠内において第１の表示データを表示し、第２基本機能管理部の管理下で動作するモジュールからの表示要求に基づいて、第２表示枠内において第２の表示データを表示するデータ表示部と、
   自装置内で前記第１の表示データの表示に関わり且つ不正な、ソフトウェアが実行された場所と、前記第１基本機能管理部及び前記第２基本機能管理部の作動状態又は非作動状態とを特定する特定部と、
   前記特定された場所と前記第１基本機能管理部及び前記第２基本機能管理部の作動状態又は非作動状態との組み合わせパタンに応じた報知パタンで報知する報知部と、
   を具備することを特徴とする状態表示制御装置。
2. 前記第１基本機能管理部が、前記予め信頼性が確認されたモジュールのみの動作を制御する信頼化オペレーティングシステムであることを特徴とする請求項１の状態表示制御装置。
3. 前記データ表示部は、前記第１表示枠と、前記第２表示枠とを同時に表示することを特徴とする請求項１の状態表示制御装置。
4. 前記報知部は、前記データ表示部に表示されている表示データの表示状態を視覚的に確認可能な状態表示部を備えていることを特徴とする請求項３の状態表示制御装置。
5. 前記第１表示枠の中に表示されている前記第１の表示データが、前記第１基本機能管理部の管理下で動作するモジュールによって表示要求されたデータであることを示す特定状態表示を、前記状態表示部がすることを特徴とする請求項４の状態表示制御装置。
6. 前記表示要求の送信元が正当か否かを検査するための基準となる判断情報を予め記憶し且つＴＰＭ（Trusted Platform Module）からなる信頼性情報管理部を具備し、前記判断情報が、少なくとも各モジュール、前記基本機能管理部をそれぞれ特定するハッシュ値であることを特徴とする請求項１の状態表示制御装置。
7. 前記ＴＰＭは、起動時に測定された前記予め信頼性が確認されたモジュールのハッシュ値を記憶することを特徴とする請求項６の状態表示制御装置。
8. 前記特定部が、前記予め信頼性が確認されたモジュールを特定する認証データを予め記憶する記憶部と、前記表示要求の送信元の信頼性を認証する認証部とを備え、前記認証部が、前記ＴＰＭに記憶されていた前記予め信頼性が確認されたモジュールのハッシュ値と、前記認証データとが一致した場合に、前記予め信頼性が確認されたモジュールを正当と判断することを特徴とする請求項７の状態表示制御装置。
9. 前記ＴＰＭは、前記表示要求を暗号化するのに用いる鍵を記憶する鍵記憶部を備え、前記特定部は、前記表示要求に含まれる情報を暗号化する暗号部と、前記暗号部が暗号化処
   理をするための鍵を、前記ＴＰＭから取得する鍵交換部とをさらに備えることを特徴とする請求項８の状態表示制御装置。
10. 前記特定部は、前記予め信頼性が確認されたモジュールからの表示要求を受理した場合、前記状態表示部に、前記特定状態表示をすることを特徴とする請求項５の状態表示制御装置。
11. 前記特定部は、前記第２基本機能管理部からの表示要求を受理したが、前記予め信頼性が確認されたモジュールからの表示要求を受理していない場合、前記状態表示部には、前記特定状態表示はしないことを特徴とする請求項５の状態表示制御装置。

Images