(57)【要約】      （修正有）【課題】通信相手の接続許可の有無、及び改竄の有無の組み合わせに応じて、適切な処理を実行することを可能とする技術を提供する。【解決手段】通信装置との通信を実行する情報処理装置１１０であって、前記通信装置が接続許可されていることを証明する証明手段と、前記通信装置のソフトウェアが改竄されていないことを証明する証明手段と、前記認証手段による認証結果と前記証明手段による証明結果とに応じて、前記情報処理装置を制御する制御手段１１３を有する。【選択図】図１
2014174677.tif 000002
【特許請求の範囲】
【請求項１】
通信装置との通信を実行する情報処理装置であって、
前記通信装置が接続許可されていることを認証する認証手段と、
前記通信装置のソフトウェアが改竄されていないことを証明する証明手段と、
前記認証手段による認証結果と前記証明手段による証明結果とに応じて、前記情報処理装置を制御する制御手段を有することを特徴とする情報処理装置。
【請求項２】
前記制御手段は、前記認証手段による認証結果と証明手段による証明結果とに応じて、送信すべきメッセージを制御することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記制御手段は、前記認証手段による認証処理が成功、かつ、前記証明手段による証明処理が共に成功した場合に、前記通信装置との通信を許可するメッセージを送信することを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記制御手段は、前記認証手段による認証処理が成功、かつ、前記証明手段による証明処理が失敗した場合に、改竄通知を送信することを特徴とする請求項２又は請求項３に記載の情報処理装置。
【請求項５】
前記制御手段は、前記認証手段による認証処理が失敗、かつ、前記証明手段による証明処理が成功した場合に、接続登録通知を送信することを特徴とする請求項２乃至４の何れか１項に記載の情報処理装置。
【請求項６】
前記制御手段は、前記認証手段による認証処理が失敗、かつ、前記証明手段による証明処理が失敗した場合に、接続拒否通知を送信することを特徴とする請求項２乃至５の何れか１項に記載の情報処理装置。
【請求項７】
前記通信装置のソフトウェアは複数のプログラムから構成されており、
更に、
前記通信装置内のソフトウェアがプログラム毎に改竄されていないことを証明する第２の証明手段と、
前記通信装置が提供するサービスを特定するサービス特定手段と、
前記特定されたサービスに依存するプログラムを特定するプログラム特定手段とを有し、
前記制御手段は、前記認証手段による認証に成功、かつ、前記特定されたプログラムが改竄されていない場合に、前記特定されたサービスを利用するために通信装置へアクセスすることを特徴とする請求項１に記載の情報処理装置。
【請求項８】
更に、
前記通信装置内のソフトウェアのバージョンを特定するバージョン特定手段と、
前記特定したバージョンが、前記ソフトウェアの何れかのバージョンに含まれることを確認する第３の証明手段とを有し、
前記制御手段は、前記認証手段に成功、かつ、前記第３の証明手段により前記特定したバージョンが何れかのバージョンに含まれることを確認された場合に、前記通信装置内のソフトウェアを更新することを特徴とする請求項１に記載の情報処理装置。
【請求項９】
更に、
前記通信装置に送信すべきデータが、前記認証手段による認証処理、及び／或いは前記証明手段による証明処理を必要とするか否かを示す送信データの属性を特定する属性特定手段と、
前記特定された送信データの属性に応じて、前記認証手段、及び／或いは前記証明手段を実行するか否かを制御する第２の制御手段とを有することを特徴とする請求項１に記載の情報処理装置。
【請求項１０】
前記制御手段は、前記認証手段による認証結果と前記証明手段による証明結果と前記特定された属性とに応じて、前記情報処理装置を制御することを特徴とする請求項９に記載の情報処理装置。
【請求項１１】
通信装置との通信を実行する情報処理装置の制御方法であって、
認証手段が、前記通信装置が接続許可されていることを認証する認証工程と、
証明手段が、前記通信装置のソフトウェアが改竄されていないことを証明する証明工程と、
制御手段が、前記認証工程による認証結果と前記証明工程による証明結果とに応じて、前記情報処理装置を制御する制御工程を有することを特徴とする情報処理装置の制御方法。
【請求項１２】
前記制御工程は、前記認証工程による認証結果と証明工程による証明結果とに応じて、送信すべきメッセージを制御することを特徴とする請求項１１に記載の情報処理装置の制御方法。
【請求項１３】
前記制御工程は、前記認証工程による認証処理が成功、かつ、前記証明工程による証明処理が共に成功した場合に、前記通信装置との通信を許可するメッセージを送信することを特徴とする請求項２に記載の情報処理装置の制御方法。
【請求項１４】
前記制御工程は、前記認証工程による認証処理が成功、かつ、前記証明工程による証明処理が失敗した場合に、改竄通知を送信することを特徴とする請求項１２又は請求項１３に記載の情報処理装置の制御方法。
【請求項１５】
前記制御工程は、前記認証工程による認証処理が失敗、かつ、前記証明工程による証明処理が成功した場合に、接続登録通知を送信することを特徴とする請求項１２乃至１４の何れか１項に記載の情報処理装置の制御方法。
【請求項１６】
前記制御工程は、前記認証工程による認証処理が失敗、かつ、前記証明工程による証明処理が失敗した場合に、接続拒否通知を送信することを特徴とする請求項１２乃至１５の何れか１項に記載の情報処理装置の制御方法。
【請求項１７】
コンピュータを、請求項１乃至１０の何れか１項に記載の情報処理装置が有する各手段として機能させるためのコンピュータプログラム。
【請求項１８】
請求項１７に記載のコンピュータプログラムを格納することを特徴とするコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置の認証、及び改竄検知に関する。
【背景技術】
【０００２】
遠隔のコンピュータと通信する際に、当該コンピュータとの通信が許可されていることを確認するための機器認証技術がある。機器認証に失敗した際に、ネットワークへのアクセスを禁止することが提案されている（特許文献１参照）。また、認証を実行し、認証に失敗した場合に、新規登録することも提案されている（特許文献２参照）。
【０００３】
一方、コンピュータをネットワークに接続する際、当該コンピュータ内部のソフトウェア、及びハードウェアが改竄されていないことを確認するための機器証明技術がある。機器証明に失敗した場合には、ネットワークへの接続を禁止することが提案されている（特許文献３参照）。また、ソフトウェアが正常か否かを判定し、正常でない場合には、ソフトウェアを自動的に更新することも提案されている（特許文献４参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平１１−３３１１８１号公報
【特許文献２】特開２００５−２５０５４１号公報
【特許文献３】特開２００５−２３６８５０号公報
【特許文献４】特開２００７−３２３３４９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、機器認証に成功し、かつ、機器証明に失敗した場合のことは考慮されていない。よって、従来技術によれば、機器認証に成功したか否かを判定しないため、機器証明に失敗した場合に、接続許可されていないコンピュータのソフトウェアを自動的に更新してしまう可能性がある。同様に、機器証明に成功し、かつ、機器認証に失敗した場合のことは考慮されていない。よって、従来技術によれば、機器証明に成功したか否かを判定しないため、機器認証に失敗した場合に、改竄されているコンピュータを新規登録してしまう可能性がある。
【０００６】
本発明は係る問題点に鑑みなされたものであり、通信相手の接続許可の有無、及び改竄の有無の組み合わせに応じて、適切な処理を実行することを可能とする技術を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するため、情報処理装置によれば、前記通信装置が接続許可されていることを認証する認証手段と、前記通信装置が改竄されていないことを証明する証明手段と、前記認証手段による認証結果と前記証明手段による証明結果に応じて、前記情報処理装置を制御する制御手段とを有することを特徴とする。
【発明の効果】
【０００８】
通信相手の接続許可の有無、及び改竄の有無の組み合わせに応じて、適切な処理を実行することが可能となる。
【図面の簡単な説明】
【０００９】
【図１】実施形態における情報処理装置の構成を説明するブロック図である。
【図２】実施形態におけるシステムの構成を説明する図である。
【図３】実施形態における接続処理のフローを説明する図である。
【図４】実施形態における認証・証明処理のフローを説明する図である。
【図５】実施形態におけるサービス利用処理のフローを説明する図である。
【図６】実施形態における接続処理のフローを説明する図である。
【図７】実施形態におけるデータ送信処理のフローを説明する図である。
【図８】実施形態における機器認証処理のフローを説明する図である。
【図９】実施形態における機器証明処理のフローを説明する図である。
【発明を実施するための形態】
【００１０】
［第１の実施形態］
＜情報処理装置の構成＞
はじめに、図１を用いて、本実施の形態に適応可能な情報処理装置について説明する。図１は本実施形態に係る情報処理装置の基本構成を示す図である。同図において、情報処理装置１１０は、例えば一般に普及しているパーソナルコンピュータである。図１に示すように、本実施形態における情報処理装置１１０は、ＲＯＭ１１、ＨＤＤ１２、ＴＰＭ１３、ＲＡＭ１４、及びＣＰＵ１９から構成される。
【００１１】
ＲＯＭ１１は、物理的、或いは論理的な書き換えが不可能な不揮発性メモリであり、ＢＩＯＳ１５、不図示の各種プログラム、及びデータを記憶可能な補助記憶部である。ＢＩＯＳ１５は情報処理装置１１０全体を制御するプログラムである。また、ＢＩＯＳ１５は、情報処理装置１１０に電源が投入された際、情報処理装置内部で最初に起動されるプログラムである。
【００１２】
ＨＤＤ１２は、ｂｏｏｔ  ｌｏａｄｅｒ１６、ｋｅｒｎｅｌ１７、モジュール群１８、及び種々のデータを記憶可能な補助記憶部である。ここで、ｂｏｏｔ  ｌｏａｄｅｒ１６は起動するｋｅｒｎｅｌ１７の制御をするプログラムである。ｋｅｒｎｅｌ１７は、種々のモジュールのロード、ＲＡＭ１４のメモリ管理、及び不図示のキーボードや画面出力などの入出力機能を制御するプログラムである。モジュール群１８は、ワードプロセッサ、表計算、データベース管理、ネットワークブラウジング、映像・音声再生、印刷、通信など、情報処理装置１１０の利用者が実行したい作業を機能として提供するプログラムである。本実施形態ではモジュール群１８が３つのモジュールｍｏｄｕｌｅ  Ａ、ｍｏｄｕｌｅ  Ｂ、及びｍｏｄｕｌｅ  Ｃから構成されているものとして説明するが、本発明はこれに限定されることなく、より多くのモジュールから構成されていても良い。
【００１３】
ＴＰＭ１３は、耐タンパー性を有するセキュリティチップである。耐タンパー性とは、外部からの解析を困難にすると共に、外部から解析しようとした場合に内部に記憶されているプログラム、或いはデータを破壊することにより自己防衛する特性である。また、ＴＰＭ１３は、ＮｖＲＡＭ１１１、ＰＣＲ１１２、及び制御部１１３から構成されている。ＮｖＲＡＭ１１１は不揮発性メモリであり、後述するデジタル署名の生成に必要な秘密鍵（クライアント秘密鍵、及びサーバ秘密鍵）、公開鍵（クライアント公開鍵、及びサーバ公開鍵）、及び公開鍵証明書を記憶する。ＰＣＲ１１２は揮発性メモリであり、前述した、ＢＩＯＳ１５、ｂｏｏｔ  ｌｏａｄｅｒ１６、ｋｅｒｎｅｌ１７、及びモジュール群１８のハッシュ値に基づいた値を記憶する。制御部１１３は後述する電子署名生成処理、及びＰＣＲ１１２への登録処理などを実行する。ここで登録処理とは、ＴＰＭ１３の外部から入力されたデータのハッシュ値を次の式に従って計算し、計算した値を所定のＰＣＲに記憶する機能である。
【００１４】
ＤＡＴＡ＿ｉ＋１＝Ｈ（ＤＡＴＡ＿ｉ｜ＩＮＰＵＴ）                （式１）
ここで、ＩＮＰＵＴは、ＴＰＭ１３外部から入力されたデータ、或いはそのハッシュ値である。ＤＡＴＡ＿ｉはＴＰＭ１３に登録する時点で既にＰＣＲに記録されている値である。Ｈ（ｘ）は値ｘに対するハッシュ関数（圧縮関数）である。「ｘ｜ｙ」は値ｘと値ｙの連結である。ＤＡＴＡ＿ｉ＋１は外部から値ＩＮＰＵＴが入力された場合に計算される結果値であり、ＤＡＴＡ＿ｉ＋１が所定のＰＣＲに記憶されることになる。本実施形態では、ＴＰＭ１３にはＰＣＲ０、ＰＣＲ１、ＰＣＲ２、及びＰＣＲ３という４つのＰＣＲが搭載されているものとして説明する。また、ＰＣＲ０はＢＩＯＳ１５、ＰＣＲ１はｂｏｏｌ  ｌｏａｄｅｒ１６、ＰＣＲ２はｋｅｒｎｅｌ１７、そしてＰＣＲ３はモジュール群１８（ｍｏｄｕｌｅ  Ａ、ｍｏｄｕｌｅ  Ｂ、及びｍｏｄｕｌｅ  Ｃ）のハッシュ値をＩＮＰＵＴとして登録するものとする。
【００１５】
以上説明したＰＣＲへの登録処理は、情報処理装置１１０が起動する際に実行される。ここで、情報処理装置１１０の起動処理について説明する。情報処理装置１１０に電源が投入されると、まずＢＩＯＳ１５が実行される。その後、ＢＩＯＳ１５、ｂｏｏｔ  ｌｏａｄｅｒ１６、ｋｅｒｎｅｌ１７、モジュール群１８の順にロード・実行する。ここで、モジュール群１８に含まれるｍｏｄｕｌｅ  Ａ、ｍｏｄｕｌｅ  Ｂ、及びｍｏｄｕｌｅ  Ｃは選択的にロード・実行することも可能である。即ち、ロード・実行されないモジュールもある。また、ｍｏｄｕｌｅ  Ａ、ｍｏｄｕｌｅ  Ｂ、及びｍｏｄｕｌｅ  Ｃのロード・実行の順序は特に定める必要はなく、必要な時に必要なモジュールがロード・実行される。
【００１６】
本実施形態では、以上説明した起動処理中に、前述したＰＣＲへの登録処理を実行する。即ち、ＢＩＯＳ１５は自分自身のハッシュ値を算出し、算出したハッシュ値を式１に従ってＰＣＲ０へ登録する。そして、ＢＩＯＳ１５はｂｏｏｔ  ｌｏａｄｅｒ１６のハッシュ値を算出し、算出したハッシュ値を式１に従ってＰＣＲ１へ登録する。その後、ｂｏｏｔ  ｌｏａｄｅｒ１６を起動する。起動したｂｏｏｔ  ｌｏａｄｅｒ１６はｋｅｒｎｅｌ１７のハッシュ値を算出し、算出したハッシュ値を式１に従ってＰＣＲ２へ登録する。その後、ｋｅｒｎｅｌ１７を起動する。起動したｋｅｒｎｅｌ１７は、モジュール（ｍｏｄｕｌｅ  Ａ、ｍｏｄｕｌｅＢ、或いｍｏｄｕｌｅ  Ｃ）が必要となった場合にモジュールのハッシュ値を算出し、算出したハッシュ値を式１に従ってＰＣＲ３へ登録する。ｋｅｒｎｅｌ１７は、モジュールが必要になる毎に登録処理を繰り返し実行する。
【００１７】
以上説明した一連の登録処理により、情報処理装置１１０への電源投入後の所定の時点において、情報処理装置１１０で実行している全てのプログラムの状態がハッシュ値としてＰＣＲ内に記憶されていることに留意されたい。
【００１８】
さて、図１に戻って説明を続ける。ＲＡＭ１４は揮発性メモリであり、ＣＰＵ１９にて処理を行うために一時的にプログラムや各種データ（動作状態）を一時的に格納しておく主記憶部である。
【００１９】
ＣＰＵ１９は、情報処理装置１１０内の各部の動作を制御、或いはＲＡＭ１４にロードされたプログラムを実行することのできる電子回路である。
【００２０】
以上、本実施形態における情報処理装置１１０の構成について説明した。
【００２１】
＜システム構成＞
次に、図２を用いて本実施形態におけるシステム構成について説明する。
【００２２】
図２（Ａ）は本実施形態に適応可能なシステムの概要を示す図である。図２（Ａ）に示すように、本実施形態におけるシステムはサーバ２１、及びクライアントＡ２２から構成される。サーバ２１とクライアントＡ２２とは、有線、或いは無線の通信回線を用いて接続されており、互いにデータを通信可能となっている。本実施形態ではサーバ２１がクライアントＡ２２と通信する際に、クライアントＡ２２がサーバ２１と通信することが許可されていることを確認するものとする。この処理を機器認証と呼ぶ。同様に、本実施形態ではサーバ２１がクライアントＡ２２と通信する際に、クライアントＡ内部のソフトウェア、及びハードウェアが改竄されていないことを確認するものとする。この処理を機器証明と呼ぶ。
【００２３】
本実施形態では、サーバ２１がクライアントＡ２２の機器認証、及び機器証明を実行するものとして説明をする。しかしながら、本発明はこれに限定されることなく、クライアントＡ２２がサーバ２１の機器認証、及び機器証明を実行したり、サーバ２１、及びクライアントＡ２２が夫々互いに機器認証、及び機器証明を実行するようにしてもよい。
【００２４】
また、図２（Ｂ）に示すように、クライアントＡ２２とは異なるクライアントＢ２３をサーバ２１と接続するようにしてもよい。この場合、ユーザはクライアントＢ２３を用いて、後述するクライアントＡ２２との接続処理、データ送信処理、サービス利用処理をサーバ２１に対して指示することが可能となる。
【００２５】
＜接続処理フロー＞
次に、図３（Ａ）を用いて本実施形態におけるサーバ２１とクライアントＡ２２の接続処理のフローを説明する。以下のフローは、前述した情報処理装置１１０の構成を備えるサーバ２１上でソフトウェアとして実現され、各ステップは該当するプログラム及びそれを実行するＣＰＵ１９によって実現する。
【００２６】
図３（Ａ）は、本実施形態に適応可能な接続処理の流れを示すフローチャートである。
【００２７】
サーバ２１がクライアントＡ２２と通信を開始する際、まずステップＳ３１で、状態フラグを「００」に初期化する。状態フラグとは、サーバ２１がクライアントＡ２２との機器認証、及び機器証明の状態を管理するためのフラグであり、ＲＡＭ１４などに保持する。状態フラグは２ビットで構成され、１ビット目は機器認証の結果（認証結果）、そして２ビット目は機器証明の結果（証明結果）を示す。夫々「０」は機器認証、或いは機器証明されていないことを示し、「１」は機器認証、或いは機器証明されていることを示す。
【００２８】
次にステップＳ３２で、接続先であるクライアントＡ２２から接続要求を受信すると、ステップＳ３３で、接続要求を受信したクライアントＡ２２と認証・証明処理を実行する。認証・証明処理の過程で、ＲＡＭ１４に保持している状態フラグが認証、及び証明結果に応じて更新される。本実施形態における、認証・証明処理の詳細は後述する。
【００２９】
クライアントＡ２２と認証・証明処理が完了すると、ステップＳ３４は状態フラグの値に応じて次に実行すべき処理を切り替える。
【００３０】
もし状態フラグが「１１」の場合、処理をステップＳ３５に進める。ステップＳ３５では、クライアントＡ２２はサーバ２１と通信することが許可されており、かつ、改竄されていないものとして、クライアントＡ２２と通常接続する。また、同時に通常接続可能であることを知らせるメッセージを送信しても良い。
【００３１】
もし状態フラグが「１０」の場合、処理をステップＳ３６に進める。ステップ３６では、クライアントＡ２２はサーバ２１と通信することが許可されているものの、ソフトウェア、或いはハードウェアが改竄されているものとして、アップデートが必要であることを知らせるメッセージ（改竄通知）を送信する。或いは、サーバ２１がクライアントＡ２２のソフトウェアを更新する処理を実行しても良い。或いは、クライアントＡ２２が改竄されていることを知らせるメッセージを送信しても良い。
【００３２】
もし状態フラグが「０１」の場合、処理をステップＳ３７に進める。ステップ３７では、クライアントＡ２２はソフトウェア、及びハードウェアが改竄されていないものの、サーバ２１と通信することが許可されていないものとして、クライアントの登録が必要であることを知らせるメッセージ（接続登録通知）を送信する。或いは、サーバ２１上でクライアントＡ２２を登録するための処理を実行しても良い。或いは、クライアントＡ２２が接続許可されていないことを知らせるメッセージを送信しても良い。
【００３３】
もし状態フラグが「００」の場合、処理をステップＳ３８に進める。ステップＳ３８では、クライアントＡ２２はサーバ２１と通信することが許可されておらず、かつ、ソフトウェア、或いはハードウェアが改竄されているものとして、接続拒否することを知らせるメッセージを送信する。
【００３４】
尚、ステップＳ３５、ステップＳ３６、ステップＳ３７、及びステップＳ３８におけるメッセージの送信先は特に限定されることはない。例えば、サーバ２１のユーザ及び／或いは管理者、クライアントＡ２２のユーザ及び／或いは管理者、或いは図２に示したシステムの管理者にメールなどの手段で送信してもよい。或いは、サーバ２１、及び或いはクライアントＡ２２の不図示の画面上に表示するようにしても良い。
【００３５】
ステップＳ３５、ステップＳ３６、ステップＳ３７、及びステップＳ３８の後、サーバ２１は接続処理を終了する。
【００３６】
＜認証・証明処理フロー＞
次に、前述した図３のステップＳ３３における認証・証明処理の詳細について、図４（Ａ）を用いて説明する。図４（Ａ）において、ステップＳ４１、ステップＳ４３、ステップＳ４４、ステップＳ４５、ステップＳ４７、及びステップＳ４８の一連のフローはサーバ２１で実行される。一方、ステップＳ４２、及びステップＳ４６はクライアントＡ２２で実行される。
【００３７】
まず、ステップＳ４１はクライアントＡ２２において実行されるステップＳ４２と通信することにより、クライアントＡ２２がサーバ２１と通信することが許可されていることを確認するための機器認証を行う。ステップＳ４１、及びステップＳ４２の詳細は後述する。
【００３８】
そして、ステップＳ４３では機器認証が成功したか否かの判断を実行する。もし機器認証に成功したならば、ステップＳ４４でＲＡＭ１４に保持されている状態フラグの１ビット目の値を「１」に変更し、処理をステップＳ４５に進める。これにより、状態フラグは認証成功したことを示すようになる。一方、ステップＳ４３で機器認証に失敗したと判断したならば、状態フラグは変更せず、処理をステップＳ４５に進める。
【００３９】
次に、ステップＳ４５は、クライアントＡ２２において実行されるステップＳ４６と通信することにより、クライアントＡ２２のソフトウェア、及びハードウェアが改竄されていないことを確認するための機器証明を行う。ステップＳ４５、及びステップＳ４６の詳細は後述する。
【００４０】
そして、ステップＳ４７では機器証明が成功したか否かの判断を実行する。もし機器証明に成功したならば、ステップＳ４８でＲＡＭ１４に保持されている状態フラグの２ビット目の値を「１」に変更し、認証・証明処理を終了する。これにより、状態フラグは証明成功したことを示すようになる。一方、ステップＳ４７で機器証明に失敗したと判断したならば、状態フラグは変更せず、認証・証明処理を終了する。
【００４１】
＜機器認証処理フロー＞
次に、前述した図４のステップＳ４１における機器認証処理、及びステップＳ４２における機器認証データ生成処理の詳細について、図８を用いて説明する。図８において、ステップＳ８１、ステップＳ８４、及びＳ８５のフローは機器認証処理としてサーバ２１で実行される。一方、ステップＳ８２、及びステップＳ８３のフローは機器認証データ生成処理としてクライアントＡ２２で実行される。
【００４２】
まず、ステップＳ８１では、クライアントＡ２２に対してクライアント証明書を要求する。クライアントＡ２２はステップＳ８２でクライアント証明書要求を受信する。クライアント証明書要求を受信すると、ステップＳ８３で、クライアントＡ２２内のＨＤＤ１２などに予め保持されているクライアント証明書を取得し、サーバ２１に送信する。クライアント証明書とは、不図示の認証局がクライアントの正当性を証明するために発行するものであり、認証局によるデジタル署名を含むデータである。
【００４３】
ステップＳ８３が送信したクライアント証明書は、サーバ２１がステップＳ８４で受信する。クライアント証明書を受信した後、ステップＳ８５はクライアント証明書の正当性を検証するために、クライアント証明書に含まれるデジタル署名を検証する。また、必要に応じて、クライアント証明書内に記載されているクライアントの識別子が、前述したＳ３２（図３）において接続要求を送信したクライアントの識別子と一致することを確認しても良い。さらに、予めサーバ２１への接続を許可するクライアントの識別子の一覧をデータベースとしてＨＤＤ１２などに保持しておき、クライアント証明書内に記載されているクライアントの識別子が、前述したデータベースに含まれていることを確認しても良い。一連の処理により、クライアントＡ２２の正当性が確認された場合は機器認証成功とし、確認されない場合は機器認証失敗とする。
【００４４】
ステップＳ８５でクライアント証明書を検証した後、機器認証処理を終了する。
【００４５】
＜機器証明処理フロー＞
次に、前述した図４のステップＳ４５における機器証明処理、及びステップＳ４６における機器証明データ生成処理の詳細について、図９（Ａ）を用いて説明する。図９（Ａ）において、ステップＳ９１、ステップＳ９２、ステップＳ９６、ステップＳ９７、及びステップＳ９８の一連のフローは機器証明処理としてサーバ２１で実行される。一方、ステップＳ９３、ステップＳ９４、及びステップＳ９５の一連のフローは機器証明データ生成処理としてクライアントＡ２２で実行される。
【００４６】
まず、サーバ２１はステップＳ９１で乱数を生成し、生成した乱数をステップＳ９２がクライアントＡ２２に送信する。クライアントＡ２２はステップ９３で、サーバ２１が送信した乱数を受信する。
【００４７】
次に、ステップＳ９４で、クライアントＡ２２は図１に示したＴＰＭ１３を用いて、ステップＳ９３で受信した乱数、及びＰＣＲ１１２に登録されているＰＣＲ値から、ＮｖＲＡＭ１１１に保持されているクライアント秘密鍵を用いてデジタル署名を生成する。ここで、クライアントＡ２２は前述した起動処理により、夫々ＰＣＲ０にはＢＩＯＳ１５、ＰＣＲ１にはｂｏｏｔ  ｌｏａｄｅｒ１６、ＰＣＲ２にはｋｅｒｎｅｌ１７、及びＰＣＲ３にはモジュール群１８のハッシュ値が登録されていることに留意されたい。
【００４８】
そして、ステップＳ９５では、ＨＤＤ１２などに保持されているクライアント公開鍵、ＰＣＲ１１２に登録されているＰＣＲ値、及びステップＳ９４で生成したデジタル署名をサーバ２１に送信する。サーバ２１はステップＳ９６で、クライアントＡ２２が送信したクライアント公開鍵、ＰＣＲ値、及びデジタル署名を受信する。
【００４９】
ステップＳ９６で一連のデータを受信した後、ステップＳ９７では、ステップＳ９６で受信したデジタル署名をＰＣＲ値、及びクライアント公開鍵を用いて検証する。そして検証に成功した場合、ステップＳ９８で、予めデータベースとしてＨＤＤ１２などに保持してあるクライアントのＰＣＲ値と、ステップＳ９６が受信したＰＣＲ値とが一致するかを比較する。一致した場合は機器証明成功とし、一致しない場合は機器証明失敗とする。
【００５０】
ステップＳ９６でＰＣＲ値を比較した後、機器証明処理を終了する。
【００５１】
以上、本実施形態における接続処理に含まれる一連のフローについて説明した。本実施形態によれば、認証、或いは証明処理に失敗した場合に、単に接続拒否するだけでなく、接続するために必要な次の処理を通知することにより、接続できない場合の原因を特定しやすくなる。特に、認証処理だけに失敗したのか、或いは証明処理だけに失敗したのかを、状態フラグが「１０」か、或いは「０１」かによって区別して原因特定できるようになる。
【００５２】
以上説明したフローチャートでは、ステップＳ３４において状態フラグの値に応じて、ステップＳ３５、ステップＳ３６、ステップＳ３７、及びステップＳ３８を切り替えるようにしていた。しかしながら本発明はこれに限定されることなく、状態フラグと事後処理を対応付けたテーブルを用意しておき、このテーブルを参照することにより事後処理を選択するようにしても良い。この場合の接続処理フローの変形例を図３（Ｂ）のフローチャートを用いて説明する。
【００５３】
図３（Ｂ）において、ステップＳ３１、ステップＳ３２、ステップＳ３３は図３（Ａ）と同様の処理であるため説明は省略する。
【００５４】
ステップＳ３３で認証・証明処理が完了した後、ステップＳ３９で状態フラグを用いて、状態フラグに対応する事後処理を特定する。このために、本実施形態では図３（Ｃ）に示すようなテーブルをＨＤＤ１２などに備える。図３（Ｃ）に示すテーブルは、状態フラグと事後処理を対応付けたものであり、所定の状態フラグの時に実行すべき事後処理が記載されている。図３（Ｃ）に示す例では、状態フラグが「１１」の場合事後処理として通常接続を選択し、同様に「１０」の場合要アップデート通知、「０１」の場合要登録通知、「００」の場合接続拒否通知を選択することを示している。そして、ステップＳ３９で事後処理を特定した後、ステップＳ３１０で特定した事後処理を実行する。
【００５５】
このような処理フローにより、図３（Ｃ）に示したテーブルを更新するだけで、所定の状態の時に必要な処理を変更することが可能となる。
【００５６】
以上、本実施形態における接続処理の変形例について説明した。
【００５７】
［第２の実施形態］
以上説明した実施形態では、サーバ２１はクライアントＡ２２との機器認証、及び機器証明の結果、認証だけ成功した場合には、クライアントＡ２２は改竄されているものとし、アップデートが必要であることを知らせるメッセージを送信するようにしていた。
【００５８】
一方、本発明によれば、サーバ２１がクライアントＡ２２のサービスを利用するような場合、クライアントＡ２２の改竄検知された機能に応じて、当該サービスを利用できるようにすることも可能である。以降では、この場合の実施形態について説明する。
【００５９】
本実施形態における情報処理装置、及びシステム構成は、夫々図１、及び図２に示したものと同様のものが適用可能であるため説明は省略する。
【００６０】
＜サービス利用処理のフロー＞
以降では図５を用いて本実施形態において、サーバ２１がクライアントＡ２２のサービスを利用する場合のサービス利用処理のフローを説明する。以下のフローは前述した情報処理装置１１０の構成を備えるサーバ２１上でソフトウェアとして実現され、各ステップは該当するプログラム及びそれを実行するＣＰＵ１９によって実現する。
【００６１】
図５（Ａ）は、本実施形態に適応可能なサービス利用処理の流れを示すフローチャートである。
【００６２】
サーバ２１がクライアントＡ２２のサービスを利用する際、まずステップＳ３３で、利用するサービスを提供するクライアントＡ２２と認証・証明処理を実行する。ステップＳ３３における認証・証明処理は、前述した図３における認証・証明処理と同様に、図４（Ａ）に示した認証・証明処理が実行される。ただし、本実施形態では図４（Ａ）におけるステップＳ４５の機器証明処理、及びステップＳ４６の機器証明データ生成処理が第１の実施形態と異なるため、これについて図９（Ｂ）を用いて説明する。
【００６３】
図９（Ｂ）は本実施形態に適応可能な機器証明処理、及び機器証明データ生成処理のフローを説明するフローチャートである。図９（Ｂ）において、図９（Ａ）と同様の処理をするものは同一の符号を付与するものとし、詳細な説明は省略する。
【００６４】
サーバ２１はステップＳ９１で乱数を生成した後、ステップＳ９９でＨＤＤ１２などに予め保持してあるサーバ公開鍵、及び生成した乱数をクライアントＡ２２に送信する。クライアントＡ２２はステップＳ９１０で、サーバ２１が送信したサーバ公開鍵、及び乱数を受信する。
【００６５】
次に、ステップＳ９４でデジタル署名を生成した後、ステップＳ９１１でＨＤＤ１２などに保持している起動ログを受信したサーバ公開鍵で暗号化する。ここで本実施形態における起動ログについて説明する。
【００６６】
起動ログとは情報処理装置１１０がＴＰＭ１３にＰＣＲ値を登録する際に、登録するＰＣＲの番号、登録するハッシュ値、及び当該ハッシュ値を算出する際に用いたプログラム名を順次記録したデータである。図９（Ｃ）に本実施形態における起動ログの例を示す。図９（Ｃ）はＢＩＯＳ１５、ｂｏｏｔ  ｌｏａｄｅｒ１６、及びｋｅｒｎｅｌ１７が起動した後、ｍｏｄｕｌｅ  Ａ、ｍｏｄｕｌｅ  Ｂ、及びｍｏｄｕｌｅ  Ｃが順に起動した場合の起動ログの例を示している。図９（Ｃ）に示すように、起動ログがＴＰＭ１３へ登録するプログラム毎にそのハッシュ値を記録していることに留意されたい。この起動ログを用いることにより、後述するようにプログラム毎に改竄検知することが可能となる。
【００６７】
さて、図９（Ｂ）に戻って説明を続ける。ステップＳ９１１で起動ログを暗号化した後、ステップＳ９１２はクライアント公開鍵、ＰＣＲ１１２に登録されているＰＣＲ値、ステップＳ９１１で暗号化した起動ログ、及びステップＳ９４で生成したデジタル署名をサーバ２１に送信する。クライアント公開鍵はＮｖＲＡＭ１１１、或いはＨＤＤ１２などに保持しておけばよい。サーバ２１はステップＳ９１３で、クライアントＡ２２が送信したクライアント公開鍵、ＰＣＲ値、起動ログ、及びデジタル署名を受信する。
【００６８】
ステップＳ９１３で一連のデータを受信した後、ステップＳ９７では、ステップＳ９１３で受信したデジタル署名を検証する。そして検証に成功した場合、ステップＳ９８で、ステップＳ９１３が受信したＰＣＲ値と、予めデータベースとしてＨＤＤ１２などに保持してあるクライアントのＰＣＲ値とが一致するかを比較する。一致する場合機器証明成功とし、一致しない場合は機器証明失敗とする。
【００６９】
ステップＳ９８でＰＣＲ値を比較した後、ステップＳ９１４では暗号化されている起動ログをサーバ秘密鍵で復号する。そして、ステップＳ９１５では、ステップＳ９１４で復号した起動ログ（例えば、図９（Ｃ））のプログラムのハッシュ値と、予めサーバ２１のＨＤＤ１２などに保持してあるプログラムのハッシュ値を、プログラム毎に比較する。そして各プログラムの比較結果を証明結果テーブルとしてＨＤＤ１２などに保存する。図５（Ｂ）は本実施形態における証明結果テーブルの例である。図５（Ｂ）に示す例では、クライアントＡ２２の機器証明結果がプログラム毎（ＢＩＯＳ、ｂｏｏｔ  ｌｏａｄｅｒ、ｋｅｒｎｅｌ、ｍｏｄｕｌｅ  Ａ、ｍｏｄｕｌｅ  Ｂ、ｍｏｄｕｌｅ  Ｃ）に保存されている。「○」は改竄されていないことを示し、「×」は改竄されていることを示す。また、サーバ２１に複数のクライアントが接続する場合、接続するクライアント毎に証明結果を保存しておいても良い。図５（Ｂ）に示す例では、クライアント００１、クライアント００２、及びクライアント００３の３つのクライアントの機器証明結果が記録されている。また、このうちクライアント００２のｍｏｄｕｌｅ  Ａが改竄されていることを示している。
【００７０】
ステップＳ９１５において起動ログを確認した後、機器証明処理を終了する。
【００７１】
以上、本実施形態における機器証明処理について説明した。
【００７２】
さて、図５に戻って説明を続ける。ステップＳ３３において認証・証明処理を実行した後、ステップＳ５１では利用するサービス、及びサービスを利用する所望のクライアントを特定する（サービス特定）。例えば、サーバ２１の利用者が所望のクライアントを不図示のユーザインターフェイスを用いて、夫々特定する。そして、ステップＳ５２では、ステップＳ５１で特定したクライアントの状態フラグを、ＨＤＤ１２などに保存されている証明結果テーブルから取得する。図９（Ｂ）に示す例では、もしステップ５１でクライアント００１が特定された場合、状態フラグとして「１１」が取得されることになる。
【００７３】
そして、ステップＳ５３では、ステップＳ５２で取得した状態フラグの値に応じて次に実行すべき処理を切り替える。
【００７４】
もし状態フラグが「１１」の場合、処理をステップＳ５４に進める。ステップＳ５４では、クライアントＡ２２はサーバ２１と通信することが許可されており、かつ、改竄されていないものとして、サーバ２１はクライアントＡ２２のサービスを利用する。
【００７５】
もし状態フラグが「１０」の場合、処理をステップＳ５５に進める。ステップＳ５５では、ステップＳ５１で特定した利用サービスから、予めＨＤＤ１２に保持されているサービス‐プログラム対応表を用いて、利用サービスが依存するプログラムを特定する。サービス‐プログラム対応表とは、所定のサービスがどのプログラムに依存しているかを示した表である。本実施形態におけるサービス‐プログラム対応表の例を図９（Ｃ）に示す。図９（Ｃ）に示す例では、「○」は依存していることを示し、「×」は依存していないことを示している。例えば、サービスＡはｍｏｄｕｌｅ  Ａ、及びｍｏｄｕｌｅ  Ｂには依存しており、ｍｏｄｕｌｅ  Ｃには依存していないことを示している。ステップＳ５５でプログラム特定を行った後、ステップＳ５６は特定したプログラムの証明結果を証明結果テーブルから取得する。ステップＳ５５で複数のプログラムを特定した場合には、特定した全てのプログラムの証明結果を取得するようにする。そして、ステップＳ５７では、ステップＳ５７で所得したプログラムの証明結果に基づいて、その後に実行すべき処理を切り替える。即ち、取得した全てのプログラムの証明結果が「○」である場合には、処理をステップＳ５４に進める。一方、少なくとも一つの証明結果が「×」である場合には、処理をステップＳ５８に進める。
【００７６】
もし状態フラグが「００」、或いは「０１」の場合、処理をステップＳ５８に進める。ステップＳ５８では、クライアントＡ２２はサーバ２１と通信することが許可されていない、或いは、サービスを利用するためのプログラムが改竄されているものとして、サービス拒否することを知らせるメッセージを送信する。
【００７７】
ステップＳ５４、及びステップＳ５８の後、サーバ２１はサービス利用処理を終了する。
【００７８】
以上、本実施形態における接続処理の変形例について説明した。
【００７９】
本実施形態によれば、サーバ２１がクライアントＡ２２のサービスを利用する際、当該サービスに依存するプログラムが改竄されているか否かを判定し、改竄されていなければ当該サービスを利用することが可能となる。これにより、クライアントＡ２２におけるサービス可用性を向上させることが可能となる。
【００８０】
［第３の実施形態］
以上説明した実施形態では、サーバ２１はクライアントＡ２２の機器証明が失敗した場合に、常にクライアントＡ２２が改竄されているものと判断していた。実際には、機器証明に失敗した場合に必ずしもクライアントＡ２２が改竄されていることはなく、例えばクライアントＡ２２のアップデートされるべきソフトウェアがアップデートされていない場合も機器認証に失敗することになる。これは図９のステップＳ９８におけるＰＣＲ値の比較において、サーバ側のＰＣＲ値とクライアント側のＰＣＲ値が一致しないことに起因する。
【００８１】
しかしながら本発明によれば、サーバ２１がクライアントＡ２２の機器証明に失敗した場合に、機器証明に失敗した原因がソフトウェアをアップデートしていないのか、或いはそれ以外の原因（例えば、改竄）なのかを判断することも可能である。さらに、判断した結果に応じて、その後の処理を切り替えることも可能である。以降では、この場合の実施形態について説明する。
【００８２】
本実施形態における情報処理装置、及びシステム構成は、夫々図１、及び図２に示したものと同様のものが適用可能であるため説明は省略する。
【００８３】
＜接続処理のフロー＞
以降では図６を用いて、本実施形態においてサーバ２１がクライアントＡ２２と接続する際の接続処理のフローを説明する。以下のフローは前述した情報処理装置１１０の構成を備えるサーバ２１上でソフトウェアとして実現され、各ステップは該当するプログラム及びそれを実行するＣＰＵ１９によって実現する。
【００８４】
図６（Ａ）は、本実施形態に適応可能な接続処理の流れを示すフローチャートである。尚、図６（Ａ）は前述した図３の変形例であり、図３と同様の処理をするものは同一の符号を付与するものとし、説明は省略する。
【００８５】
ステップＳ３３において認証・証明処理が完了すると、ステップＳ６１では状態フラグの値に応じて次に実行すべき処理を切り替える。状態フラグが「１１」、「０１」、及び「００」の場合は、図３の場合と同様に夫々ステップＳ３５、ステップＳ３７、及びステップＳ３８に処理を進める。
【００８６】
一方、もし状態フラグが「１０」の場合は、処理をステップＳ６２に進める。ステップＳ６２では、クライアントＡ２２のモデル、及びバージョンを特定する。クライアントＡ２２のモデル、及びバージョンの情報は、ステップ３３における認証・証明処理の過程でクライアントＡ２２から取得するようにすればよい。
【００８７】
ステップＳ６２でクライアントＡ２２のモデル、及びバージョン特定を行った後、ステップＳ６３において、特定したモデルの全てのバージョンのＰＣＲ値を取得する。このため、サーバ２１にはクライアントＡ２２の全てのモデル、及び全てのバージョンに対応するソフトウェアのＰＣＲ値をモデル・バージョンのＰＣＲ値情報として保持しておくようにする。図６（Ｂ）は、サーバ２１に保持するモデル・バージョンのＰＣＲ値情報の例である。図６（Ｂ）はクライアントＡ２２としてモデルＡ、及びモデルＢの２つが存在し、かつ、モデルＡにはバージョン１．０、１．１、及びバージョン１．２の３つのバージョンが存在する場合の例である。図６（Ｂ）の例では、ステップＳ６２でクライアントＡ２２がモデルＡと特定された場合、ステップＳ６３は、モデルＡのバージョン１．０、１．１、及び１．２の全てのＰＣＲ値を取得するようにする。
【００８８】
そしてステップＳ６４では、ステップＳ６３で取得したバージョンのＰＣＲ値の何れかが、ステップＳ３３の過程で取得したクライアントＡ２２のＰＣＲ値と一致するかが判断される。尚、クライアントＡ２２のＰＣＲ値は、前述した様にステップＳ３３における認証・証明処理内のステップＳ９６（図９）において、クライアントＡ２２から取得していることに留意されたい。そして、クライアントＡ２２のＰＣＲ値がいずれかのバージョンのＰＣＲ値に一致する場合は、クライアントＡ２２はソフトウェアアップデートが実行されていないものと判断し、処理をステップＳ６５に進める。一方、何れのバージョンのＰＣＲ値にも一致しない場合は、改竄されていることを知らせるメッセージを送信する。
【００８９】
ステップＳ６５、及びステップＳ６６の後、接続処理を終了する。
【００９０】
以上、本実施形態における接続処理の一連のフローについて説明した。本実施形態によれば、機器証明に失敗した場合に、機器認証に失敗した原因がソフトウェアアップデートをしていないことか、或いはそれ以外の原因（例えば、改竄）なのかを判断し、判断結果に応じて、その後の処理を切り替えることが可能となる。
【００９１】
［第４の実施形態］
以上説明した実施形態では、サーバ２１はクライアントＡ２２の機器認証、及び機器証明が共に成功した場合に限り、クライアントＡ２２と通常接続する例について説明した。この結果として、機器認証、及び機器証明の両方に成功しないとサーバ２１はクライアントＡ２２にデータを送信できないことになる。これにより、例えばクライアントＡ２２が企業内に存在し、サーバ２１が保持している社内文書をクライアントＡ２２に送信する場合、接続許可されていない、或いは改竄されているクライアントＡ２２に社内文書を送信してしまうことを禁止できる。一方、サーバ２１が社外を含めて一般に公開しているようなコンテンツを保持しており、これをクライアントＡ２２に送信する場合も、機器証明に失敗したクライアントＡ２２には送信できない。前述したように、機器証明に失敗する原因としては、クライアントＡ２２の改竄の他に、ソフトウェアアップデートをしていない場合も考えられる。以降では、このような改竄以外の原因による機器認証の失敗を考慮し、サーバ２１からクライアントＡ２２へ送信するコンテンツの属性と認証・証明処理の結果の両方に応じて、当該コンテンツの送信を制御する場合の例を説明する。
【００９２】
本実施形態における情報処理装置、及びシステム構成は、夫々図１、及び図２に示したものと同様のものが適用可能であるため説明は省略する。
【００９３】
＜データ送信処理のフロー＞
以降では図７（Ａ）を用いて、本実施形態においてサーバ２１がクライアントＡ２２へデータを送信する際のデータ送信処理のフローを説明する。以下のフローは前述した情報処理装置１１０の構成を備えるサーバ２１条でソフトウェアをして実現され、各ステップは該当するプログラム及びそれを実行するＣＰＵ１９によって実現する。
【００９４】
図７（Ａ）は、本実施形態に適応可能なデータ送信処理の流れを示すフローチャートである。
【００９５】
サーバ２１がクライアントＡ２２へデータを送信する際、まずステップＳ７１で、送信対象となる送信データの属性フラグ、及び状態フラグを共に「００」に初期化する。状態フラグは前述したものと同様であるため、ここでは属性フラグについて説明する。属性フラグとは、送信データの属性を管理するためのフラグであり、予め送信データ毎に設定しておき、ＨＤＤ１２などに保持しておく。属性フラグは、状態フラグと同様に２ビットで構成され、１ビット目は機器認証、そして２ビット目は機器証明の必要の有無を示す。夫々、「０」は機器認証、或いは機器証明が必要ないことを示し、「１」は機器認証、或いは機器証明が必要であることを示している。
【００９６】
次にステップＳ７２で、クライアントＡ２２へ送信すべき送信データの属性フラグを特定する（属性特定）。本実施形態では、予め送信データ毎の属性値を属性テーブルに設定しておき、ステップＳ７２は送信データから属性テーブルに基づいて属性フラグを特定するようにする。ここで本実施形態における属性テーブルの例を、図７（Ｂ）に示す。図７（Ｂ）に示す例では、社内文書、社外印刷専用データ、テスト印刷ページ、及び社外販用文書データに、夫々「１１」、「１０」、「０１」、及び「００」の属性フラグが設定されている。この例では、例えば社内文書は機器認証、及び機器証明の両方が必要であることを示し、テスト印刷ページは機器認証は必要ないが、機器証明は必要あることを示している。
【００９７】
ステップＳ７２で送信データの属性を特定した後、ステップＳ７３において、判定付き認証・証明処理を実行する。認証・証明処理の過程で、ＲＡＭ１４に保持している状態フラグが認証、及び証明結果に応じて更新される。本実施形態における判定付き認証・証明処理では、ステップＳ７２で特定した送信データの属性フラグを参照し、属性フラグのビットが「１」である場合にだけ機器認証、或いは機器証明を実行する。即ち、属性フラグのビットが「０」である場合には、対応する状態フラグのビットは（ステップＳ７１で初期化した）「０」のままであることに留意されたい。本実施形態における判定付き認証・証明処理の詳細は後述する。
【００９８】
判定付き認証・証明処理の後、ステップＳ７４において、ステップＳ７３で更新された状態フラグと、ステップＳ７２で特定された属性フラグの排他的論理和（ＥＸＯＲ）を算出する。例えば、ステップＳ７３で状態フラグが「１０」に更新され、ステップＳ７２で属性フラグとして「１１」が特定された場合は、状態フラグ「１０」と属性フラグ「１１」の排他的論理和である「０１」が算出されることになる。
【００９９】
ここで、ステップＳ７４における排他的論理和の結果の意味について説明する。排他的論理和の結果が「０」である場合、これは属性フラグのビットと状態フラグのビットが一致していることを示す。即ち、送信データが機器認証、或いは機器証明が必要な場合、夫々クライアントＡ２２との機器認証、或いは機器証明に成功していることを意味する。一方、排他的論理和の結果が「１」である場合、これは属性フラグのビットと状態フラグのビットが一致しないことを示す。即ち、送信データが機器認証、或いは機器証明が必要にも関わらず、夫々クライアントＡ２２との機器認証、或いは機器証明に失敗していることを意味する。
【０１００】
例えば、前述した排他的論理和の結果が「０１」である場合、最初のビット「０」は以下のいずれかの状況であることを示す。
【０１０１】
（１）  ステップＳ７２で送信データの属性フラグとして「０」が特定され、かつ、（ステップＳ７２では機器認証は実行されず）状態フラグは「０」である。
【０１０２】
（２）  ステップＳ７２で送信データの属性フラグとして「１」が特定され、かつ、ステップＳ７２では機器認証に成功し、状態フラグは「１」である。
【０１０３】
一方、２番目のビット「１」は以下の状況であることを示す。
【０１０４】
（３）  ステップＳ７２で送信データの属性フラグとして「１」が特定され、かつ、ステップＳ７２で機器証明に失敗し、状態フラグは「０」である。
【０１０５】
繰り返しになるが、ステップＳ７３では、特定した送信データの属性フラグを参照し、属性フラグのビットが「１」である場合にだけ機器認証、或いは機器証明を実行するようにしている。このため、属性フラグのビットが「０」、かつ、状態フラグのビットが「１」であるという状況はないことに留意されたい。
【０１０６】
さて、図７（Ａ）に戻って説明を続ける。ステップＳ７４で状態フラグと属性フラグの排他的論理和を算出した後、ステップＳ７５では排他的論理和の結果に応じて次に実行すべき処理を切り替える。
【０１０７】
もし排他的論理和の結果が「００」の場合、処理をステップＳ７６に進める。ステップＳ７５では、特定された属性フラグに必要な機器認証、及び機器証明に成功しているものと判断し、クライアントＡ２２にデータを送信する。
【０１０８】
もし排他的論理和の結果が「０１」の場合、処理をステップＳ３６に進める。ステップＳ７５では、機器認証には成功している、或いは必要ないが、機器証明は必要であるにも関わらず失敗しているものと判断し、アップデートが必要であることを知らせるメッセージを送信する。
【０１０９】
もし排他的論理和の結果が「１０」の場合、処理をステップＳ３７に進める。ステップＳ７５では、機器証明には成功している、或いは必要ないが、機器認証は必要であるにも関わらず失敗しているものと判断し、クライアントの登録が必要であることを知らせるメッセージを送信する。
【０１１０】
もし排他的論理和の結果が「１１」の場合、処理をステップＳ３８に進める。ステップＳ７５では、機器認証、及び機器証明共に失敗しているものと判断し、接続拒否することを知らせるメッセージを送信する。
【０１１１】
ステップＳ７６、ステップＳ３６、ステップＳ３７、及びステップＳ３８の後、サーバ２１はデータ送信処理を終了する。
【０１１２】
＜判定付き認証・証明処理フロー＞
次に、前述した図７のステップＳ７３における判定付き認証・証明処理の詳細について、図４（Ｂ）を用いて説明する。尚、図４（Ｂ）は前述した図４（Ａ）の変形例であり、図４（Ａ）と同様の処理をするものは同一の符号を付与するものとし、説明は省略する。
【０１１３】
まず、ステップＳ４９は、前段のステップＳ７２で特定した送信データの属性フラグの１ビット目が「１」であるか否かの判断を実行する。もし「１」であるならば、当該送信データには機器認証が必要であるものと判断し、処理をステップＳ４１へ進める。一方、もし「０」であるならば、当該送信データには機器認証が必要ないものと判断し、処理をステップＳ４１０へ進める。この場合、状態フラグの１ビット目は「０」のまま更新されないことに留意されたい。
【０１１４】
ステップＳ４１、ステップＳ４２、ステップＳ４３、及びステップＳ４４における一連の処理の後、ステッＳ４１０は、前段のステップＳ７２で特定した送信データの属性フラグの２ビット目が「１」であるか否かの判断を実行する。もし「１」であるならば、当該送信データには機器証明が必要であるものと判断し、処理をステップＳ４５へ進める。一方、もし「０」であるならば、当該送信データには機器証明が必要ないものと判断し、処理を完了する。この場合、状態フラグの２ビット目は「０」のまま更新されないことに留意されたい。
【０１１５】
以上、本実施形態におけるデータ送信処理に含まれる一連のフローについて説明した。本実施形態によれば、クライアントＡ２２への送信データに必要となる機器証明、及び機器認証だけを実行すればよいため、送信データに必要のない機器証明、及び機器認証を省略することが可能となり、結果としてデータ送信処理を効率化できる。
【０１１６】
＜その他の変形例＞
以上本発明にかかる実施形態を説明したが、先に説明したように、情報処理装置は、通常のパーソナルコンピュータ等の汎用情報処理装置であって、それ上で動作するコンピュータプログラムで実現できるものである。よって、本発明はコンピュータプログラムをその範疇とすることは明らかである。また、通常、コンピュータプログラムは、ＣＤＲＯＭ等のコンピュータ可読記憶媒体に記憶されており、それをコンピュータの対応するドライブにセットしてシステムにコピーやインストール処理することで実行可能となる。よって、本発明は当然にそのようなコンピュータ可読記憶媒体をもその範疇とすることも明らかである。
【図１】
2014174677.tif 000003
【図２】
2014174677.tif 000004
【図３】
2014174677.tif 000005
【図４】
2014174677.tif 000006
【図５】
2014174677.tif 000007
【図６】
2014174677.tif 000008
【図７】
2014174677.tif 000009
【図８】
2014174677.tif 000010
【図９】
2014174677.tif 000011