JP2008005156A - 情報処理端末および状態通知方法 - Google Patents

Abstract

【課題】サーバに対して情報処理端末の状態を通知する際に、プライバシーとセキュリティを両立させることができる情報処理端末、状態通知システムおよび状態通知方法を提供する。
【解決手段】情報処理端末１０は、エントリごとに通知可能な相手を判定する公開有無判定部１００１と、エントリを隠蔽するログ隠蔽部１００２と、複数の通知相手についてハッシュの更新を指示するログ複数測定部１００３と、通知相手向けのログを構成し署名させるログ構成部１００４と、検証を要求する検証要求部１００５と、通知可能な相手の判定に用いるポリシーを記憶するポリシー記憶手段１００６と、エントリを記憶するログ記憶手段１００７と、を備え、エントリに通知相手ごとの適した隠蔽処理などの処理を施したもののハッシュによる累積を指示する。
【選択図】図１

Description

本発明は、ネットワークを介してさまざまなサービスを提供するサーバに、それらのサービスを受けるパソコンなどの情報処理端末が、自端末の状態を通知する技術に関する。

近年、ネットワークを介して提供されるサービスは、音楽や映像といった著作物の提供や、企業の機密情報の送受、オンラインバンキングなど、多岐かつ高価なものになってきている。多岐に渡るサービスに対応するため、パソコン、携帯端末、携帯電話、デジタル家電などの情報処理端末には、多くのクライアントソフトウェアがインストールされる。また、それらのソフトウェアにはサービスを受ける機能そのものの他に、高価な情報を保護するための機能が実装されている。

こうしたサービスで得られる価値が高まるにつれ、情報処理端末上のソフトウェアに不正な変更を加えるなどの方法でソフトウェアが課している制限を迂回されることによる被害が深刻化しており、サービスを提供しようとしている情報処理端末のクライアントソフトウェアおよびそれが動作するオペレーティングシステムを含んだ実行環境に不正な変更が加えられていないかどうか検証する必要性が増している。

そうした必要性に応えるため、ＴＣＧ(Trusted Computing Group)などによって、情報処理端末において実行されているソフトウェアの情報を正確に伝える技術が提案されている。上記のＴＣＧなどによって提案されている技術は、例えば特許文献１に公開されている。

図１４は、ＴＣＧなどによって提案されている技術に基づき、検証サーバ１４１０が情報処理端末１４００上で実行されているソフトウェアを検証するシステムの一例を示しており、情報処理端末１４００には、ＴＰＭ(Trusted Platform Module)１４０１と呼ばれる耐タンパモジュールが実装され、このモジュールによりセキュリティ上重要な情報である秘密鍵やハッシュ値を保護し、またセキュリティ上重要な処理を安全に実行する。

情報処理端末１４００は、ＣＰＵ１４０２が起動時からＢＩＯＳやローダ、カーネルといった実行されるソフトウェアのコードのハッシュを計算し、ＴＰＭ１４０１に記憶させる。ＴＰＭ１４０１は、この情報処理端末の状態を検証しようとする外部の存在である検証サーバ１４１０に対して、デジタル署名したハッシュを提示可能なため、検証サーバ１４１０が正しいハッシュと比較することで情報処理端末が正しいコードが実行された状態にあることを証明することが可能である。

ハッシュをとる対象は、より一般化され、ソフトウェアが起動した、ドライバがロードされた、のように生起したイベントについての情報を表現したデータ（以下エントリと呼ぶ）も含む。この形式の場合、プログラム名やそのコードのハッシュをエントリに入れることも可能であり、各エントリを結合した情報（以下イベントログあるいは単にログと呼ぶ）の内容が保証対象になる。

具体的には、情報処理端末１４００のＣＰＵ１４０２は、BIOS, Loader, Kernel, App A, App Bとソフトウェアのコードを実行する際に、それぞれのハッシュを計算し（ハッシュ計算１４２１）、計算したハッシュ１４２２をＴＰＭ１４０１に送信し、さらに、そのエントリ１４２４をイベントログ１４０３に追加して記憶する。ＴＰＭ１４０１はハッシュ１４２２が送られてくると、既に記憶している値と送られてきた値を連結し、ハッシュ演算を実行して、ひとつのハッシュにしてＰＣＲ（Platform Configuration Register）１４０４に記憶する（累積演算処理１４２３）。

このように後から改ざん検知の対象になるデータが増えた場合でも、順序も含めてひとつのハッシュで保証することが可能である。状態を累積していくため、以降このハッシュを累積ハッシュと呼ぶ。またこのようにハッシュを計算して累積していく処理を測定とも呼ぶ。

検証サーバ１４１０が情報処理端末１４００上で実行されているソフトウェアを検証する場合、まず、検証サーバ１４１０から情報処理端末１４００にチャレンジ１４２５が送信され、ＴＰＭ１４０１は、受信したチャレンジ１４２５とＰＣＲ１４０４に格納された累積ハッシュとを連結してそれに電子署名を施し（電子署名処理１４２６）、さらに、証明書と、イベントログ１４０３と連結して検証情報１４２７として検証サーバ１４１０に送信する。

検証サーバ１４１０は、まず、証明書の署名を検証し、次に、電子署名を検証し、次に、受信したイベントログ１４０３のエントリと検証データＤＢ１４１１に登録されているエントリとを照合し、さらに、改めて累積ハッシュを算出して受信した検証情報１４２７に含まれる累積ハッシュと照合し、さらにチャレンジ１４２５と受信した検証情報１４２７に含まれるチャレンジとを照合することで、情報処理端末１４００上で実行されているソフトウェアを検証する。

このように、署名された累積ハッシュだけでなく、イベントログも通知することにより、より詳細に及んだ検証をすることも可能である。累積ハッシュにより、このイベントログも正しいことを検証することが可能なためである。

現実的には、ソフトウェアはいくつかの階層からなり、下層が同じであっても上層が違うなどの場合があるため、組み合わせが多様であり、全ての状態に一つの累積ハッシュを割りあてると検証が困難になりうる。そのため、ＴＰＭは複数の累積ハッシュを保持可能になっており、PCR0からPCR15まで１６個のレジスタがあり、ＣＰＵ１４０２はハッシュをＴＰＭに送る際にどの累積ハッシュを更新するか番号（以下累積ハッシュ番号）で指定する。
特表２００２−５３６７５７号公報

しかしながら、検証サーバ１４１０にイベントログを通知することによって、より詳しい検証が可能である反面、この場合、どのようなソフトウェア、どのようなネットワークサービスを利用しているかといったことまでが検証サーバ１４１０側に知られることになるので、プライバシー情報の漏洩が懸念され、セキュリティとの兼ね合いを考慮にいれるべきである。

プライバシー情報保護の観点からは、実行状態を通知する対象である対象サーバに応じて、通知する内容の一部を削除または隠蔽できるのが望ましい。しかしながら、前記従来の構成では、累積ハッシュの更新後にイベントログを変更すると、改ざんされたと解釈されるため、イベントログの内容を削除したり隠蔽したりするような変更はできない。

本発明は、前記従来の課題を解決するもので、プライバシー情報を保護しながら、イベントログの改ざん検知が可能な形で、自端末の状態を通知することが可能な情報処理端末を提供することを目的とする。

本発明の情報処理端末は、状態の変化を示すデータであるエントリを記録し、エントリを結合したログを通知する情報処理端末であって、エントリが通知可能か否かを通知相手ごとに判定する公開有無判定手段と、隠蔽処理を施したエントリを生成するログ隠蔽手段と、エントリを記憶するログ記憶手段と、ログの改ざん検知に用いるエントリの累積を通知相手ごとに保持する累積記憶手段と、前記公開有無判定手段の判定結果に基づきエントリの通知が不可の通知相手に対応する前記累積記憶手段が保持するエントリの累積は隠蔽処理を施したエントリに基づいて更新し、エントリの通知が可能な通知相手に対応する前記累積記憶手段が保持するエントリの累積は隠蔽処理を施していないエントリに基づいて更新するよう指示するログ複数測定手段と、前記公開有無判定手段の判定結果に基づき通知相手に対して通知が不可のエントリは隠蔽処理を施したエントリとなり通知相手に対して通知が可能なエントリは隠蔽処理を施していないエントリとなるように前記ログ記憶手段が記憶しているエントリから通知相手に通知するログを生成するログ構成手段と、通知相手に対応する前記累積記憶手段が保持するエントリの累積に電子署名を施したデータと前記ログ構成手段が生成したログとを含むデータを前記通知相手に送信する検証要求手段と、を備える。

そのため、通知相手ごとに送信するログの内容を変えてプライバシー情報を保護でき、なおかつ、改ざん検知が可能なように状態の累積を行うことができる。すなわち、アプリＢというアプリケーションが起動しているにもかかわらず、アプリＡに成りすまして、イベントログでは、アプリＡが起動しているようにすることや、実際にはアプリＣ（スパイウェアなど）が起動しているにもかかわらず、イベントログには何の痕跡も残さないようにするイベントログの改ざんを検知可能な形でサーバに通知するとともに、各エントリの隠蔽の有無を通知相手ごとに変えてプライバシー情報を保護することができる。

また、本発明の情報処理端末は、前記累積記憶手段が保持するエントリの累積がエントリの累積ハッシュであることを特徴とする。

そのため、通知相手では、受信したログに対して累積ハッシュを計算し、受信したエントリの累積と照合することで、ログが改ざんされていないことを検証することができ、また、情報処理端末では累積記憶手段に必要となるメモリの容量を小さくすることが出来る。

また、本発明のセキュアデバイスは、情報処理端末の状態の変化を示すデータであるエントリの累積を保持する累積記憶手段と、前記累積記憶手段に保持されるエントリの累積の更新を行う累積演算手段と、前記エントリの累積に電子署名を行う署名手段と、前記情報処理端末から受信したログを検証する検証手段と、サービスを提供するサービスサーバと、を備える。

そのため、通知相手ごとに送信するログの内容を変えてプライバシー情報を保護し、なおかつ、改ざん検知が可能なようにサーバ等の相手に通知するので、相手は、通知されたログを検証、確認したうえで正当なユーザにサービスを提供することができる。また、重要な個人情報をセキュアデバイスに格納しておき、検証に成功したサービスサーバにだけ個人情報の取得や操作を許可することで、安全に個人情報を利用することが可能になる。

また、本発明のセキュアデバイスは、実行環境を提供する実行環境提供手段と、実行環境を記憶する実行環境記憶手段と、をさらに備える。

そのため、自身が提供した実行環境からのアクセスのみ許可するといったアクセス制御が可能になる。すなわち、実行環境のソフトウェアは、セキュアデバイスから情報処理端末へ提供されるので、セキュアデバイスは、情報処理端末上で実行環境を実現するために、どのソフトウェアが起動されているべきかを知っており、情報処理端末から受信したログと照合することで、自身が提供した実行環境からのアクセスかどうかを判断し、自身が提供した実行環境からのアクセスのみ許可することにより、セキュリティを向上させることができる。

また、本発明の情報処理端末のログ複数測定手段は、通知相手が異なる場合であってもエントリの累積の値が同じになる場合には、前記累積記憶手段には一つのエントリの累積として保持されるように更新を指示する。

そのため、余分な累積ハッシュの更新演算を省くことができるので、エントリの累積を更新する処理を高速化することができる。

また、本発明の情報処理端末は、ログ隠蔽手段が、マスターキーを保持し、エントリＩＤを前記マスターキーにより暗号化したものから暗号鍵を生成し、エントリを前記暗号鍵で暗号化するものである。

そのため、事後の開示要求に応えるために保持しておかなければならない情報をなくすことができるので、情報処理端末の記憶容量を削減することができる。

また、本発明の情報処理端末は、ログ隠蔽手段が、暗号鍵をランダムに生成し、エントリを前記暗号鍵で暗号化するものであり、前記暗号鍵を隠蔽情報として記憶する隠蔽情報記憶手段を備える。そのため、暗号鍵をランダムにすることができ、セキュリティを向上させることができる。

また、本発明の情報処理端末は、ログ隠蔽手段がエントリの内容の一部または全部を削除するものである。そのため、通知相手に応じて公開できる内容を制限することができ、セキュリティを向上させることができる。

また、本発明の情報処理端末は、エントリごとに異なるエントリＩＤを付与するＩＤ付与手段と、エントリごとの隠蔽に関する隠蔽情報をエントリＩＤと対応づけて記憶する隠蔽情報記憶手段と、隠蔽されたエントリの開示を要求された際に、エントリＩＤに対して隠蔽を解除する情報を取得ないしは生成し、要求してきた相手に開示してよいか判断し、開示してよいと判断した場合に、隠蔽を解除する情報または解除したエントリを渡すログ開示判定手段とを、さらに備える。

そのため、通知時には隠蔽したエントリを、必要に応じて後から解除できるので、情報処理端末上で発生した不具合や不正について分析する際など、必要に応じて隠蔽した情報を後から開示することが可能である。

また、本発明の情報処理端末は、ログ開示判定手段が、開示してよいか判断する際に、隠蔽を解除したエントリを利用者に提示し、利用者にエントリを開示してよいか指定させるものである。

そのため、利用者自身が、開示するエントリの内容を確認し、開示してよいか判断することができるので、利用者のプライバシー保護を向上させることができる。

また、本発明の状態通知方法は、情報処理端末が自端末の状態変化の履歴であるログをサーバに通知する方法であって、通知可能でないサーバ向けにエントリを隠蔽してログを生成するステップと、前記ログと、前記ログに対応する累積ハッシュに電子署名を施したデータと、前記電子署名を検証するための証明書とを連結した署名付ログを生成するステップと、前記署名付ログを前記サーバに送信するステップと、を有する。

そのため、サーバでは、まず、電子署名を検証することで、累積ハッシュ自体が改ざんされていないことが確認でき、さらに、累積ハッシュを照合することで、受信したエントリのログが、改ざんされていないことが確認できるので、通知相手ごとに送信するログの内容を変えてプライバシー情報を保護し、なおかつ、改ざん検知が可能なようにサーバに通知することができる。

本発明の情報処理端末によれば、通知するサーバによって各エントリの隠蔽の有無を変えることでプライバシー情報を保護しながら、イベントログの改ざん検知が可能な形で通知することが可能である。また、本発明の情報処理端末によれば、サービスを受ける上で、情報処理端末上で発生した不具合や不正について分析する際など、必要に応じて隠蔽した情報を後から開示することが可能である。

以下本発明の実施の形態について、図面を参照しながら説明する。

（第１の実施形態）
本発明の第１の実施形態では、耐タンパな記憶領域と処理装置を実装するセキュアモジュールを搭載した情報処理端末であり、起動時からイベントログを蓄積し、累積ハッシュを更新し、イベントログと、そのイベントログに対応する累積ハッシュに電子署名を施したデータと、その電子署名を検証するための証明書とを連結したデータ（以下では、この連結したデータを「署名付ログ」と呼ぶ）をサーバに送信し、検証してもらうことで、サービスを受ける情報処理端末について記載する。

図１は、本発明の第１の実施形態における構成図である。図１を用いて構成を述べる。情報処理端末１０は、エントリをどのサーバに対して公開可能かを判定する公開有無判定部１００１と、公開しないサーバ向けにエントリに隠蔽処理を施すログ隠蔽部１００２と、隠蔽しないエントリと隠蔽したエントリの両方を受けとり公開有無判定部１００１の判定結果に従って複数の累積ハッシュの更新を指示するログ複数測定部１００３と、通知サーバに応じたログを構成するログ構成部１００４と、署名付ログをサーバに通知し検証を要求する検証要求部１００５と、ポリシーデータを記憶するポリシー記憶手段１００６と、エントリを記憶するログ記憶手段１００７と、エントリにエントリＩＤを付与するＩＤ付与部１００８と、どのような隠蔽をしたかの隠蔽情報を記憶する隠蔽情報記憶手段１００９と、入力されたエントリＩＤに対応するエントリの開示の可否を判定するログ開示判定部１０１０と、サーバからサービスを受けるサービスクライアント１０１１と、を備えている。

セキュアモジュール２０は、ハッシュと累積ハッシュ番号を受けとり対応する累積ハッシュを更新する累積演算部２００１と、累積ハッシュによる電子署名を演算する署名部２００２と、累積ハッシュを記憶する累積ハッシュ記憶手段２００３と、を備えている。セキュアモジュール２０は望ましくは、耐タンパ性を備えている。

サーバ３０は、署名付ログを検証する検証部３００１と、隠蔽情報を受けとってエントリの隠蔽を解除するログ開示部３００２と、ログを保存するログ保存手段３００３と、ログを検証するためのデータが記録されたサーバＤＢ３００４と、サービスを提供するサービスサーバ３００５と、を備えている。

情報処理端末１０は、例えばパソコンや携帯電話であり、公開有無判定部１００１、ログ隠蔽部１００２、ログ複数測定部１００３、ログ構成部１００４、検証要求部１００５、ＩＤ付与部１００８、ログ開示判定部１０１０、サービスクライアント１０１１は、情報処理端末１０が備えるＣＰＵによって実行されるソフトウェアとして実現される。また、ポリシー記憶手段１００６、ログ記憶手段１００７、隠蔽情報記憶手段１００９は、ＨＤＤや半導体メモリなどの記憶装置によって構成される。

セキュアモジュール２０は、例えばＴＰＭのような耐タンパ性を持ったチップであり、搭載された処理装置により累積演算部２００１、署名部２００２が実現され、搭載された記憶装置により累積ハッシュ記憶手段２００３が実現される。

サーバ３０は、例えば高性能なパソコンであり、検証部３００１、ログ開示部３００２、サービスサーバ３００５などは備えられたＣＰＵによって実行されるソフトウェアとして実現される。また、ログ保存手段３００３、サーバＤＢ３００４は、ＨＤＤや半導体メモリなどの記憶装置によって構成される。

次に図５を用いて、イベント発生時にハッシュを累積する測定の動作について述べる。情報処理端末１０で発生したイベント情報のエントリはＩＤ付与部１００８に渡される。ＩＤ付与部１００８はエントリにそのエントリを一意に特定可能なエントリＩＤを付与する（ＩＤ付与 ステップＳ１０１）。

公開有無判定部１００１は、エントリをどのサーバに対して公開可能かをポリシー記憶手段１００６に記憶されているポリシーデータを用いて判定する（公開有無判定 ステップＳ１０２）。なお、この場合、そのエントリのソフトウェアの提供者、または、情報処理端末１０を含む情報システムのシステム管理者、または、情報処理端末１０の利用者は、そのポリシーデータを誰に公開可能にするかを設定することができる。

ログ隠蔽部１００２は、エントリをログ記憶手段１００７に記憶して、さらに、公開しないサーバ向けにエントリに隠蔽処理を施す（ログ隠蔽 ステップＳ１０３）。このとき、ログインペイ部１００２は、どのような隠蔽をしたかを表す隠蔽情報を隠蔽情報記憶手段１００９に記憶する。

隠蔽処理は、例えば、ランダムに生成した鍵で暗号化を施すことであり、その場合は、その暗号鍵をエントリＩＤと対応づけて隠蔽情報として記憶する。あるいは、マスターキーと呼ばれる機器固有の暗号鍵を秘匿しておき、エントリＩＤをこのマスターキーで暗号化したデータから隠蔽に用いる鍵を生成してもよい。また、他の隠蔽処理としては、完全に削除してしまってもよいし、一部の情報だけを残すようにしてもよい。その場合、事後に開示を可能にする場合は、エントリそのものを隠蔽情報として記憶する。

ログ複数測定部１００３は、隠蔽しないエントリと隠蔽したエントリの両方を受けとり公開有無判定部１００１の判定結果に従って複数の累積ハッシュの更新をセキュアモジュール２０に対して指示する（ログ複数測定 ステップＳ１０４）。より具体的には各サーバに対応した累積ハッシュに、必要に応じて隠蔽処理の施されたエントリのハッシュの累積処理を、セキュアモジュール２０に累積ハッシュ番号とハッシュを渡して指示する。

セキュアモジュール２０の累積演算部２００１は、ハッシュと累積ハッシュ番号を受けとり、対応する累積ハッシュを更新する。累積ハッシュは累積ハッシュ記憶手段２００３に記憶される（累積演算処理 ステップＳ１０５）。

次に図６（ａ）（ｂ）を用いて、サービスクライアントがサービスサーバに対して状態を通知する動作について述べる。この動作により、サービスクライアントは、サービスサーバからサービスを受けるために、現在の情報処理端末の状態が、望ましい状態にあることを、サービスサーバが確認できるよう通知する。まず、サービスクライアント１０１１は、検証要求部１００５に検証を要求する（検証要求 ステップＳ１１１）。

検証要求部１００５は、ログ構成部１００４に署名付ログを要求する（署名付ログ要求 ステップＳ１１２）。ログ構成部１００４は、ログ記憶手段１００７から対応するエントリを取りだし、必要に応じて隠蔽処理を施して、通知サーバに応じたログを構成し、通知サーバに応じた累積ハッシュ番号を指定して署名部２００２に署名を要求する（署名要求 ステップＳ１１３）。

署名部２００２は、指定された累積ハッシュ番号の累積ハッシュに対する電子署名を演算する（署名処理 ステップＳ１１４）。この電子署名の演算は、典型的には累積ハッシュをセキュアモジュール２０の署名鍵により処理する演算であり、ＲＳＡ等のよく知られた手法で演算する。同じデータ列に対するハッシュは同じ値になり、アルゴリズムによっては電子署名の結果も同じものになるため、サーバから受け取った乱数を使う、エントリにタイムスタンプを含むなどして、再送攻撃に対する対策を施すことが望ましい。

この電子署名は、再構成されたログに対応する累積ハッシュに対する電子署名であり、署名部２００２から電子署名を受信した検証要求部１００５は署名付ログを生成し、この署名付ログが検証部３００１に送られる（署名付ログ送信 ステップＳ１１５）。

検証部３００１は、署名付ログを受信し、まず、証明書を検証し、さらに証明書に含まれる公開鍵を用いて累積ハッシュに施された署名の検証により累積ハッシュが改ざんされていないことを確認し、受信したエントリのログから累積ハッシュを計算し、受信した累積ハッシュと照合することで、受信した累積ハッシュとエントリのログに不整合が無いことを検証する。
さらに、サーバＤＢ３００４からログを検証するためのデータを取りだして、ログを検証する（ログ検証 ステップＳ１１６）。また、検証部３００１は受信した署名付ログをログ保存手段３００３に保存する。

サービスサーバ３００５は、サービスクライアント１０１１の動作状態が問題ないことの確認を受け、サービスを提供する（サービス提供 ステップＳ１１７）。望ましくは、この一連の通知・検証の通信の中でサービスクライアント１０１１とサービスサーバ３００５との間でセッション鍵を共有し、サービス提供時の通信に用いる。

次に図７および図６（ｃ）を用いて、情報処理端末１０がサーバ３０に通知した時には隠蔽したエントリを開示する動作について述べる。

情報処理端末１０のログ開示判定部１０１０は、エントリＩＤにより指定されたエントリの開示の可否を判定し（ログ開示判定 ステップＳ１２１）、開示可能と判定された際に、隠蔽情報記憶手段１００９からそのエントリの隠蔽情報を取りだし、開示先に送信する（隠蔽情報送信 ステップＳ１２２）。

ログの開示要求者は、例えば、動作の不具合を発見した利用者、または、不正の疑いを持ったサーバ管理者であり、開示を要求するエントリをエントリＩＤで指定する。開示の判定は、ログ開示判定部１０１０が一定のルール（例えば、認証済みの利用者、または、認証済みのサーバからの要求に対してのみ開示するなど）に従って自動的に行う。開示される情報にはプライバシー情報が含まれる場合があるので、利用者から入力される指示をログ開示判定部１０１０が行う開示判定の要素に含めるようにしても良い。この場合、利用者は、エントリの内容と開示の必要性から判断し、情報処理端末に指示を入力する。また、エントリの開示の要求では、エントリＩＤではなく隠蔽したエントリをログ開示判定部１０１０に入力してもよい。また、エントリの開示先に対して、隠蔽情報ではなく隠蔽を解除したエントリを送信するようにしてもよい。

サーバ３０のログ開示部３００２は、隠蔽情報を受けとってログ保存手段３００３から隠蔽されたエントリを取りだし、エントリの隠蔽を解除する（隠蔽解除 ステップＳ１２３）。

次に図８を用いてデータの具体例について説明する。図８(a)は、エントリのデータの具体例である。一行目は、エントリＩＤである。二行目は、イベントが発生した時刻を表わすタイムスタンプである。三行目はイベントのタイプを表わしており、ここでは、コンポーネントがロードされたことを示している。ロード以外には例えばアンロードがタイプとしてありうる。四行目は、関与したコンポーネントを特定できる名前である。五行目は、コンポーネントのハッシュである。六行目は、バージョンを表わしている。イベントのタイプによっては、不要な行もある。

図８(c)は、ポリシーのデータの具体例である。一行目は、サービスの名称である。二行目は、サービスから提供されたコンポーネント名の一覧である。三行目は、サービスを提供するサーバの名称である。この他に、通知を許可するサーバ（あるいはサービス）の名称を含められてもよい。

これから具体例について説明するが、まず概要を述べる。情報処理端末では、電源が入るとＢＩＯＳ、Ｌｏａｄｅｒ、Ｋｅｒｎｅｌの順に実行され、そのイベントが測定される。その後、Ｋｅｒｎｅｌの機能により、測定やアプリケーションの実行がなされる。

発生したイベントはどのサービスに属するものか判別され、さらにどのサーバに通知して良いかが判断され、測定される。このとき通知してもよいサーバに対応する累積ハッシュに対しては平文のままのエントリが累積され、通知してはいけないサーバに対応する累積ハッシュに対しては一部が暗号化されたエントリが累積される。

アプリケーションがサーバに接続する時など必要な時に、そのサーバに対して通知すべきログがエントリから構成され、対応する累積ハッシュに署名がつけられサーバに送信される。サーバは、受け取ったログが改ざんされていないか検証し、改ざんがされていないことを確認すると、ログを検証する。ログの内容から、必要な正規のコンポーネントが起動していることを確認し、サービスを提供する。

サービス提供開始後、他のサービスのコンポーネントが存在することで不具合が発生し、当該コンポーネントのエントリの中身をサーバの管理者に確認してもらうために開示する。

次に図９を用いて第１の実施形態の具体例について説明する。この具体例において、システムについてのログはサーバによって変えることなく常に全て送信されるため、効率上、別に測定する。そのため、システム測定部を新たに設けたが、この構成は必須ではない。

まず、コンポーネントが実行されるとイベントが発生し、エントリが生成される。このエントリには前述のタイムスタンプ、タイプ、名前、ハッシュ、バージョンが記載される。この例では、ＢＩＯＳ、Ｌｏａｄｅｒ、Ｋｅｒｎｅｌ、Ａｐｐ Ａ、Ａｐｐ Ｂ、Ａｐｐ Ｃの順で実行される。ＢＩＯＳ、Ｌｏａｄｅｒ、Ｋｅｒｎｅｌ、Ａｐｐ Ａ、Ａｐｐ Ｂ、Ａｐｐ Ｃは、それぞれ、複数のコンポーネントを含んでいても良く、その場合にも個々のコンポーネントの実行に対してエントリが生成される。Ａｐｐ Ａは、サービスＡのクライアントソフトウェアである。同様にＡｐｐ Ｂ、Ａｐｐ ＣはそれぞれサービスＢ、サービスＣのクライアントソフトウェアである。この後の説明は、厳密にはｋｅｒｎｅｌより後の測定について当てはまるが、ＢＩＯＳ、Ｌｏａｄｅｒ、Ｋｅｒｎｅｌについても同様の処理が行われたものとする。

ＩＤ付与部１００８は、生成されたエントリに順に数字を割りあてていく。この数字は、１から始まり、単調に増加する。この値は電源を切ってもリセットされず保持される。

公開有無判定部１００１は、エントリＩＤの割り当てられたエントリを受けとり、ポリシー記憶手段１００６に記憶されているポリシーを利用して、エントリをどのサーバに対して通知してよいか判定する。コンポーネントの属するサービスとそのサービスに対応するサーバを特定し、そのサーバへは通知可能と判定する。

その他、関連するサーバへの通知を認めてもよい。その場合はポリシーにその旨記載される。この例では、ＢＩＯＳ、Ｌｏａｄｅｒ、Ｋｅｒｎｅｌがシステムのエントリ、Ａｐｐ ＡがサーバＡへ通知可能、Ａｐｐ ＢがサーバＢに通知可能、Ａｐｐ ＣはサーバＡとサーバＢに通知可能と判定されている。

図８(a)に例示したエントリと図８(c)に例示したポリシーＡおよび(d)に例示したポリシーＢを用いて具体的に説明する。

公開有無判定部１００１は、エントリから名前ｄｒｍ−ｂ．ｄｌｌを得て、ポリシーのＳｅｒｖｉｃｅＦｉｌｅｓ欄にその名前が含まれているか探していく。ポリシーＡ（図８(c)）の中には、含まれていないが、ポリシーＢ（図８(d)）の中には含まれているので、Ａｐｐ Ｂに対応するエントリであることがわかる。そのポリシーＢのＳｅｒｖｅｒ欄の内容が通知可能なサーバ名であり、この例では、ｄｒｍ．ｅｘａｍｐｌｅ．ｏｒｇである。こうして、ｄｒｍ．ｅｘａｍｐｌｅ．ｏｒｇ（これがサーバＢであるとする）に通知可能、他には通知不可と判定される。

望ましくはデータベースを用いるなど名前からサービスを高速に探すために、名前からサービスを索けるよう効率的なデータの保持の仕方をする。

ログ隠蔽部１００２は、システムに属するエントリの場合はシステム測定部１０１４にそのままエントリを渡す。それ以外の場合は、エントリに隠蔽処理を施し、ログ複数測定部１００３にもとのエントリと隠蔽したエントリを渡す。なお、図中、エントリにかかっている斜線は隠蔽処理が施されていることを図示している。

隠蔽処理の例を説明する。エントリＩＤとタイムスタンプは隠蔽せずに残すものとする。まず、隠蔽する部分の平文のハッシュを計算し、三行目に挿入する。次に、エントリＩＤをマスターキーで暗号化したデータから暗号化に使う鍵を生成する。最後に、エントリの四行目以降を暗号化することで隠蔽処理とする。図８(b)に隠蔽したエントリの例を示した。この方法では、隠蔽情報として特に何も保存しなくてよい。一行目をサーバから受けとることで復号するための鍵を生成できるからである。この暗号化に使う鍵をランダムに生成する場合はエントリＩＤと鍵を対応づけて記憶しておく。

ログ記憶手段１００７には、もとのエントリと通知可能なサーバ一覧を記憶させる。隠蔽処理を施したエントリも記憶させておくと通知時の処理が高速になるが、余分に記憶させることになるため、ログ記憶手段１００７の容量に応じて使いわける。

システム測定部１０１４は、エントリのハッシュを計算し、システムに対応した累積ハッシュ番号とともに累積演算部２００１に送信する。累積演算部２００１は、システムに対応した累積ハッシュである累積ハッシュＳに累積する。

ログ複数測定部１００３は、もとのエントリと隠蔽されたエントリを受けとり、全サーバに対して、各サーバ向けに処理されたエントリのハッシュを各サーバに対応した累積ハッシュ番号とともに累積演算部２００１に送信する。累積ハッシュ番号は、初めてエントリを累積するときにまだ使用されていない累積ハッシュの番号が割り当てられ、後の使用のためにサーバに対応付けて記憶される。

累積演算部２００１は、サーバＡに対するエントリのハッシュは累積ハッシュＡに、サーバＢに対するエントリのハッシュは累積ハッシュＢにと、各サーバに対応する累積ハッシュに累積する。図９に示した具体例の場合、累積ハッシュＡには、Ａｐｐ Ａに関連するエントリはエントリのハッシュがそのまま累積され、Ａｐｐ Ｂに関連するエントリは隠蔽されたエントリのハッシュが累積される。逆に、累積ハッシュＢには、Ａｐｐ Ａに関連するエントリは隠蔽されたエントリのハッシュが累積され、Ａｐｐ Ｂに関連するエントリはエントリのハッシュがそのまま累積される。

累積の際には、まだ起動されていないアプリケーションに対応するサービスのサーバに対する累積ハッシュついても累積することになる。多くのサービスは、自身のサーバにしか通知を許可しないことが想定される。起動されていないアプリケーションに対応するサービスのサーバに対する累積ハッシュに対しては、他のサービスのエントリが累積されていくため、多くの場合、隠蔽されたエントリが累積される。この場合、まだ起動されていない複数のアプリケーションに対応するサービスのサーバに対するそれぞれの累積ハッシュの値は等しくなる。この性質を用いて、起動するまでは一つの累積ハッシュとして累積しておき、必要に応じて、分岐して累積していくと累積に必要な演算量を減らすことができる。

以上が累積の流れである。続いて通知について説明する。サービスを受けるサービスクライアントが、通知のためにログ構成部に通知サーバ名を渡して、署名されたログを要求する。

ログ構成部１００４は、ログ記憶手段１００７から、エントリを取りだし連結してログを構成する。この際、通知サーバ名が通知可能なサーバ一覧に含まれている場合はそのまま、含まれていない場合は隠蔽処理が施されたエントリを連結する。累積時に隠蔽処理を施したものを記憶してあればそれを用いる。さらに、システムのログに対応する累積ハッシュとサービスに対応する累積ハッシュへの署名を署名部２００２に要求する。

署名部２００２は、指定された累積ハッシュに署名を施す。ログ構成部１００４は、このログと署名とを検証要求部１００５に返し、検証要求部１００５はさらに証明書を連結して署名付ログを生成し、サーバに通知する。例えば、サーバＡ３０１は、累積ハッシュＳと累積ハッシュＡにそれぞれ署名が施されたデータと、Ａｐｐ Ｂのエントリが隠蔽されたログと、証明書とから構成される署名付ログＡを受け取り、サーバＢ３０２は累積ハッシュＳと累積ハッシュＢにそれぞれ署名が施されたデータと、Ａｐｐ Ａのエントリが隠蔽されたログと、証明書とから構成される署名付ログＢを受けとる。

各サーバともログ保存手段３００３にログを記憶する。各サーバは、まず、証明書を検証し、さらに証明書に含まれる公開鍵を用いて累積ハッシュに施された署名を検証することにより、ログが改ざんされていないことを確認し、受信したエントリのログから累積ハッシュを計算し、受信した累積ハッシュと照合することで、受信した累積ハッシュとエントリのログに不整合が無いことを検証する。この時、隠蔽されたエントリについても、隠蔽されていないエントリの場合と同様にハッシュを計算して累積ハッシュを計算する。各サーバは、サービスを提供するために必要十分なエントリを知ることができ、さらに、サーバＤＢの情報を用いて情報処理端末の状態がサービスを提供して問題ない状態にあるか確認できる。

例えば、Ａｐｐ Ａのコンポーネントに不正な改ざんがなされていないことや、不正なコンポーネントが動作していないこと、あるいや逆に必要な別のコンポーネント（例えば、ｄｒｍ−ｂ．ｄｌｌなど）が動作していることを確認できる。一方、端末の利用者は、さしあたり不要なエントリを開示しなくてすみ、プライバシーが保護される。

以上が通知の流れである。続いて開示について説明する。サーバＡの利用者がサービスのサービスクライアントが正常に動作せず、サービスを受けられないことに気づき、サーバＡにその旨通知したとする。サーバＡの管理者は、その通知を受け、不具合の検証のために、隠蔽されたエントリ（Ａｐｐ Ｂについてのエントリ）の内容を知る必要があると考えた場合に、ログ開示判定部１０１０に、隠蔽されたエントリのエントリＩＤを送信して、そのエントリの開示を要求する。

ログ開示判定部１０１０は、エントリＩＤに対応するエントリを開示してよいか判定する。この例では、隠蔽されたエントリからエントリＩＤを取りだし、それらをマスターキーで暗号化したデータから暗号鍵を生成して、隠蔽を解除し、利用者にエントリの内容を提示し、利用者が開示の可否を判定する。

利用者が、Ａｐｐ Ｂに関するエントリ内容を確認し、開示が可能と判定してその旨の指示を入力すると、情報処理端末１０は隠蔽を解除したエントリをサーバＡに送信する。サーバＡは隠蔽されていた部分の平文のハッシュを計算し、隠蔽されたエントリの中に含まれる対応するハッシュ値（図８（ｂ）に示した例における三行目のハッシュ値に相当）と比較することで、正しい内容であることを確認する。

以上が開示の流れである。このように、通知時は隠蔽したエントリの内容を、後日開示する必要があった場合に、開示することが可能である。

以上説明したように、本実施の形態では、サーバへは、電子署名が施された累積ハッシュと、再構成されたエントリのログが送られる。サーバでは、電子署名の検証処理と、累積ハッシュとエントリのログとの整合性を検証する。サーバは、まず、累積ハッシュに施された電子署名を検証することで、情報処理端末に保存されていた累積ハッシュであることを検証し、次に、受信したエントリのログから累積ハッシュを計算し、受信した累積ハッシュと照合することで、受信した累積ハッシュとエントリのログに不整合が無いことを検証する。これにより、セキュリティとプライバシー情報の保護を両立することが可能である。

なお、本実施の形態において、ＩＤ付与部１００８はエントリにそのエントリを一意に特定可能なエントリＩＤを付与したが、同一内容のエントリには同一ＩＤを付与してもよい。

なお、本実施の形態において、公開有無判定部１００１は公開可能なサーバだけを判定し、サーバごとに隠蔽の有無だけを判定したが、サーバごとに異なる隠蔽処理を行うよう判定してもよい。なお、本実施の形態において、各コンポーネントの確認はサーバが行っているが、情報処理端末１０上で、例えば証明書による検証を行い、その結果をエントリに含めてもよい。

なお、本実施の形態において、システムに属するエントリは全て公開しているが、これらについても、サーバ毎に通知する内容を変えるようにしてもよい。例えば、利用者がポリシーを提供してもよく、システムのエントリについて制限してもよい。例えば、通知する必要のないデバイスドライバに関するエントリを通知しないことで使用しているデバイスを知られずにすむといった具合である。

（第２の実施形態）
本発明の第２の実施形態では、サービスクライアントが仮想実行環境上で実行されている場合について記載する。仮想実行環境は仮想化ソフトウェアによりＫｅｒｎｅｌによる実行環境と分離されるため、相互に影響を与えることがなく、異なる実行環境上で動作するコンポーネントを通知する必要がなくなる。ただし、そのためには仮想化ソフトウェアと仮想化ソフトウェアが実行されるまでのコンポーネントについては検証可能でなければならない。

図２は、本発明の第２の実施形態における構成図である。図２を用いて構成を述べる。情報処理端末１０は、第１の実施形態の情報処理端末に加え、起動したＫｅｒｎｅｌとは別のＫｅｒｎｅｌにより実現される仮想実行環境１０１２と、仮想実行環境１０１２の実行を可能にする仮想化ソフトウェア１０１３と、をさらに備えている。

次に動作について述べる。情報処理端末１０の電源が入れられ、Ｋｅｒｎｅｌが起動した後、仮想化ソフトウェア１０１３が測定され起動される。仮想化ソフトウェア１０１３により、仮想実行環境１０１２が用意され実行される。仮想実行環境１０１２と、もとの実行環境とは仮想化ソフトウェア１０１３により分離され、仮想実行環境およびその上で動作するアプリケーションはもとの実行環境に直接影響を与えられない。

サービスクライアント１０１１は仮想実行環境１０１２上で実行される。この際、サービスクライアント１０１１についても測定されるが、もとの実行環境が測定に使っている累積ハッシュとは異なるハッシュに累積する。サービスクライアント１０１１が複数実行される際には第１の実施形態と同様に複数累積をするが、これらももとの実行環境が使っている累積ハッシュとは異なるハッシュに累積する。

もとの実行環境上で動くサービスクライアントは、もとの実行環境の累積ハッシュを、仮想実行環境上で動くサービスクライアントは、仮想実行環境の累積ハッシュを用いてサービスサーバに通知することにより、よりプライバシーを向上させることができる。

リソースを多く使うが、実行環境を複数用意し、一つの実行環境に割りあてるサービスクライアントの数を減らすことで、さらにプライバシーを向上させることができる。これを押しすすめると、一つのサービスクライアントに一つの実行環境を割りあてることもできる。この場合、不具合が発生した場合、サービスクライアント自身か、その実行環境、仮想化ソフトウェア、あるいはさらに下のコンポーネントのいずれかが原因と特定できる。

図１２を用いて、具体例で説明する。情報処理端末が起動後、ＢＩＯＳ、Ｌｏａｄｅｒ、Ｋｅｒｎｅｌ、ＶＬ（Virtualization Layerの略で、仮想化ソフトウェアのことである）、Ｋｅｒｎｅｌ’（仮想実行環境のことである）、もとの実行環境で、Ａｐｐ Ａ、Ａｐｐ Ｂ、仮想実行環境でＡｐｐ Ｃ、Ａｐｐ Ｄの順で各ソフトウェアが起動される。図１３(a)にこの状態のソフトウェアスタックの図を示した。

各サービスは、いずれも自分のサーバにのみ自分のエントリの通知を許可しているものとする。ＢＩＯＳ、Ｌｏａｄｅｒ、Ｋｅｒｎｅｌ、ＶＬ、Ｋｅｒｎｅｌ’はシステムのエントリであり公開するものとする。

仮想実行環境の状態の正しさを保証するためには、もとの実行環境の正しさも保証される必要があるため、もとの実行環境についてのエントリを仮想実行環境に引き継ぐ。これは仮想化ソフトウェアを経由して、仮想実行環境に引き継がれる。引き継がれたエントリと仮想実行環境になるＫｅｒｎｅｌ’のエントリとが累積されて仮想実行環境としての累積ハッシュＳ’が形成される。

ＢＩＯＳ、Ｌｏａｄｅｒ、Ｋｅｒｎｅｌ、ＶＬ、Ａｐｐ Ａ、Ａｐｐ Ｂは第一の実施形態と同様に累積される。ＶＬ起動後に、Ｋｅｒｎｅｌ’が起動され、その上で、Ａｐｐ Ｃ、Ａｐｐ Ｄが起動される。Ｋｅｒｎｅｌ’より後の仮想実行環境上のエントリは、もとの実行環境とは独立した累積ハッシュに累積される。

図１２の矢印は、どのエントリがどの累積ハッシュに累積されるかを表している。例えば、累積ハッシュＡには、Ａｐｐ Ａのエントリをそのまま、Ａｐｐ Ｂのエントリを隠蔽して累積する。Ａｐｐ Ｃ、Ａｐｐ Ｄのエントリは累積されない。同様に、累積ハッシュＣにも、Ａｐｐ Ｃをそのまま、Ａｐｐ Ｄを隠蔽して累積する。Ａｐｐ Ａ、Ａｐｐ Ｂのエントリは累積されない。

各サーバには、サービスクライアントが動作している実行環境自身とその実行環境上で動作しているアプリケーションについてのエントリから生成されたログが通知される。例えば、サーバＡには、それぞれ署名が施された累積ハッシュＳと累積ハッシュＡとを含む署名付ログＡが通知され、サーバＣには、それぞれ署名が施された累積ハッシュＳ’と累積ハッシュＣとを含む署名付ログＣが通知される。

このように、ＶＬにより互いの実行環境が影響を与えないことが保証され、不具合や不正の原因にはならないため、異なる実行環境で動いているコンポーネントについてのエントリは通知しなくて済む。

なお、本実施の形態において、仮想化ソフトウェア１０１３は、Ｋｅｒｎｅｌの起動した後に動作したが、図１３(b)のように、最初に起動されるプログラムが仮想化ソフトウェア１０１３であり、その上で、Ｋｅｒｎｅｌとまた別のＫｅｒｎｅｌ’が起動する形でもよい。

（第３の実施形態）
本発明の第３の実施形態では、耐タンパな記憶領域と処理装置を実装する着脱可能なセキュアデバイスを装着した情報処理端末について記載する。図３は、本発明の第３の実施形態における構成図である。

図３を用いて構成を述べる。各構成ブロックの処理内容は第１の実施形態と同様である。情報処理端末１０は、公開有無判定部１００１と、ログ隠蔽部１００２と、ログ複数測定部１００３と、ログ構成部１００４と、検証要求部１００５と、ポリシー記憶手段１００６と、ログ記憶手段１００７と、サービスクライアント１０１１と、を備えている。

セキュアデバイス４０は、累積演算部４００１と、署名部４００２と、累積ハッシュ記憶手段４００３と、検証部４００４と、サーバＤＢ４００５と、サービスサーバ４００６と、を備えている。

次に図１０を用いて、イベント発生時にハッシュを累積し測定する動作について述べる。情報処理端末１０で発生したイベント情報のエントリは公開有無判定部１００１に渡される。公開有無判定部１００１は、エントリをどのサーバに対して公開可能かをポリシー記憶手段に記憶されているポリシーデータを用いて判定する（公開有無判定 ステップＳ２０１）。この時、公開有無判定部１００１は、セキュアデバイス４０上のサービスサーバ４００６に対しても判定する。

ログ隠蔽部１００２は、エントリを公開しないサーバ向けにエントリに隠蔽処理を施す（ログ隠蔽 ステップＳ２０２）。このとき、隠蔽処理を施したエントリをログ記憶手段１００７に記憶する。

ログ複数測定部１００３は、隠蔽しないエントリと隠蔽したエントリの両方を受けとり公開有無判定部１００１の判定結果に従って複数の累積ハッシュの更新を指示するコマンドをセキュアデバイス４０に送信する（ログ複数測定 ステップＳ２０３）。より具体的には、セキュアデバイス４０に送信するコマンドの中に、累積ハッシュ番号とハッシュを含めて各サーバ（セキュアデバイス４０上のサービスサーバ４００６を含む）に対応した累積ハッシュに、必要に応じて隠蔽処理の施されたエントリのハッシュの累積処理を指示する。

セキュアデバイス４０の累積演算部４００１は、ハッシュと累積ハッシュ番号を含んだコマンドを受けとり、対応する累積ハッシュを更新する。累積ハッシュは累積ハッシュ記憶手段４００３に記憶される（累積演算処理 ステップＳ２０４）。

次に図１１を用いて、サービスクライアントがサービスサーバに対して状態を通知する動作について述べる。サービスクライアント１０１１は、検証要求部１００５に検証を要求する（検証要求 ステップＳ２１１）。

検証要求部１００５は、ログ構成部１００４に署名付ログを要求する（署名付ログ要求 ステップＳ２１２）。ログ構成部１００４は、ログ記憶手段１００７から対応するエントリを取りだし、必要に応じて隠蔽処理を施して、通知サーバに応じたログを構成し、署名部４００２に署名を要求する（署名要求 ステップＳ２１３）。

署名部４００２は、指定された累積ハッシュ番号の累積ハッシュによる電子署名を演算する（署名処理 ステップＳ２１４）。この電子署名の演算は、典型的には累積ハッシュをセキュアデバイス４０の署名鍵により処理する演算であり、ＲＳＡ等のよく知られた手法で演算する。

この電子署名は、再構成されたログに対応する累積ハッシュに対する電子署名であり、署名部２００２から電子署名を受信した検証要求部１００５は署名付ログを生成し、この署名付ログが検証部４００４に送られる（署名付ログ送信 ステップＳ２１５）。

検証部４００４は、署名付ログを受信し、まず、証明書を検証し、さらに証明書に含まれる公開鍵を用いて累積ハッシュに施された署名の検証により累積ハッシュが改ざんされていないことを確認し、受信したエントリのログから累積ハッシュを計算し、受信した累積ハッシュと照合することで、受信した累積ハッシュとエントリのログに不整合が無いことを検証する。さらにサーバＤＢ４００５からログを検証するためのデータを取りだして、ログを検証する（ログ検証 ステップＳ２１６）。

サービスサーバ４００６は、サービスクライアント１０１１の動作状態が問題ないことの確認を受け、サービスを提供する（サービス提供 ステップＳ２１７）。望ましくは、この一連の通知・検証の通信の中でサービスクライアント１０１１とサービスサーバ４００６との間でセッション鍵を共有し、サービス提供時の通信に用いる。

このように、例えば、重要な個人情報をセキュアデバイスに格納しておき、検証に成功したサービスクライアントにだけ個人情報の取得や操作を許可することで、安全に個人情報を利用することが可能になる。なお、本実施の形態において、セキュアデバイス上にサーバ機能を実装したが、もちろん通常のネットワーク上のサーバであってもよい。また、以上では、検証部４００４は、署名が施された累積ハッシュを情報処理端末１０の検証要求部１００５から受信するとしたが、セキュアデバイスの内部のインターフェイスを介して累積ハッシュ記憶手段４００４に格納されている累積ハッシュを受信し、検証要求部１００５からは、再構成されたログだけを受信するようにしても良い。

（第４の実施形態）
本発明の第４の実施形態では、第３の実施形態において、サービスクライアントが仮想実行環境上で実行されている場合について記載する。図４は、本発明の第４の実施形態における構成図である。

情報処理端末１０は、第３の実施形態の情報処理端末に加え、起動したＫｅｒｎｅｌとは別のＫｅｒｎｅｌにより実現される仮想実行環境１０１２と、仮想実行環境１０１２の実行を可能にする仮想化ソフトウェア１０１３と、をさらに備えている。

セキュアデバイス４０は、第３の実施形態のセキュアデバイスに加え、仮想実行環境を提供する実行環境提供部４００７と、仮想実行環境を記憶する実行環境記憶手段４００８と、をさらに備えている。

次に動作について述べる。情報処理端末１０の電源が入れられ、Ｋｅｒｎｅｌが起動した後、仮想化ソフトウェア１０１３が測定され起動される。

仮想化ソフトウェア１０１３は、セキュアデバイス４０の実行環境提供部４００７に実行環境を要求する。実行環境提供部４００７は、実行環境記憶手段４００８から仮想実行環境のイメージを取り出し、仮想化ソフトウェア１０１３に送信する。仮想化ソフトウェア１０１３は、仮想実行環境１０１２を実行する。仮想実行環境１０１２と、もとの実行環境とは仮想化ソフトウェア１０１３により分離され、仮想実行環境およびその上で動作するアプリケーションはもとの実行環境に直接影響を与えられない。

サービスクライアント１０１１が仮想実行環境１０１２上で実行される。この際、サービスクライアント１０１１についても測定されるが、もとの実行環境が測定に使っている累積ハッシュとは異なるハッシュに累積する。サービスクライアント１０１１が複数実行される際には第３の実施形態と同様に複数累積をするが、これらももとの実行環境が使っている累積ハッシュとは異なるハッシュに累積する。

もとの実行環境上で動くサービスクライアントは、もとの実行環境の累積ハッシュを、仮想実行環境上で動くサービスクライアントは、仮想実行環境の累積ハッシュを用いてサービスサーバに通知することにより、よりプライバシーを向上させることができる。

検証部４００４が通知されたログを検証し、サーバＤＢ４００５のデータを用いて内容を確認する。サービスサーバ４００６は、その結果を受け、サービスを提供するかどうか判断する。例えば、実行環境提供部４００７が送信した仮想実行環境１０１２の上で動いているアプリケーションからの要求以外は答えないといった具合である。なお、本実施の形態において、実行環境提供部４００７は、仮想実行環境１０１２だけ提供したが、さらにその上で動作するアプリケーションを提供してもよい。また、以上では、検証部４００４は、署名が施された累積ハッシュを情報処理端末１０の検証要求部１００５から受信するとしたが、セキュアデバイスの内部のインターフェイスを介して累積ハッシュ記憶手段４００４に格納されている累積ハッシュを受信し、検証要求部１００５からは、再構成されたログだけを受信するようにしても良い。

なお、本実施の形態において、セキュアデバイス上にだけ、累積演算部と累積ハッシュ記憶手段と署名部があったが、第１の実施形態のように情報処理端末にセキュアモジュールを備えさせ、システムについてなど一部の測定は情報処理端末の機能を用いて実現してもよい。さらに、セキュアデバイスの装着時などにセキュアデバイスが保持する累積ハッシュをリセットしてもよい。

本発明の情報処理端末は、プライバシー情報を保護したまま、情報処理端末の状態を通知可能であるため、セキュリティとプライバシーを両立することが可能であり、例えば、携帯電話、携帯情報端末（ＰＤＡ）、パーソナルコンピュータ、音楽再生（及び録音）装置、カメラ、ビデオカメラ等、各種の情報処理端末に適用することができる。

本発明の第１の実施形態における構成図 本発明の第２の実施形態における構成図 本発明の第３の実施形態における構成図 本発明の第４の実施形態における構成図 本発明の第１の実施形態における累積動作の説明図 （ａ）本発明の第１の実施形態における情報処理端末における通知動作の説明図 （ｂ）本発明の第１の実施形態におけるサーバの検証動作の説明図 （ｃ）本発明の第１の実施形態における隠蔽したエントリを開示する動作の説明図 本発明の第１の実施形態における開示動作説明図 本発明の第１の実施形態の具体例の説明図 本発明の第１の実施形態のデータの具体例の説明図 本発明の第３の実施形態における累積動作の説明図 本発明の第３の実施形態における通知動作の説明図 本発明の第３の実施形態における具体例の説明図 本発明の第２の実施形態におけるソフトウェアスタックの図 従来の技術に基づく情報処理端末上で実行されているソフトウェアを検証するシステムの説明図

符号の説明

１０ 情報処理端末
１００１ 公開有無判定部
１００２ ログ隠蔽部
１００３ ログ複数測定部
１００４ ログ構成部
１００５ 検証要求部
１００６ ポリシー記憶手段
１００７ ログ記憶手段
１００８ ＩＤ付与部
１００９ 隠蔽情報記憶手段
１０１０ ログ開示判定部
１０１１ サービスクライアント
１０１２ 仮想実行環境
１０１３ 仮想化ソフトウェア
１０１４ システム測定部
２０ セキュアモジュール
２００１ 累積演算部
２００２ 署名部
２００３ 累積ハッシュ記憶手段
３０ サーバ
３００１ 検証部
３００２ ログ開示部
３００３ ログ保存手段
３００４ サーバＤＢ
３００５ サービスサーバ
４０ セキュアデバイス
４００１ 累積演算部
４００２ 署名部
４００３ 累積ハッシュ記憶手段
４００４ 検証部
４００５ サーバＤＢ
４００６ サービスサーバ
４００７ 実行環境提供部
４００８ 実行環境記憶手段

Claims (11)

1. 状態の変化を示すデータであるエントリを記録し、エントリを結合したログを通知する情報処理端末であって、
   エントリが通知可能か否かを通知相手ごとに判定する公開有無判定手段と、
   隠蔽処理を施したエントリを生成するログ隠蔽手段と、
   エントリを記憶するログ記憶手段と、
   ログの改ざん検知に用いるエントリの累積を通知相手ごとに保持する累積記憶手段と、
   前記公開有無判定手段の判定結果に基づき、
   エントリの通知が不可の通知相手に対応する前記累積記憶手段が保持するエントリの累積は隠蔽処理を施したエントリに基づいて更新し、
   エントリの通知が可能な通知相手に対応する前記累積記憶手段が保持するエントリの累積は隠蔽処理を施していないエントリに基づいて更新するよう指示する、
   ログ複数測定手段と、
   前記公開有無判定手段の判定結果に基づき、
   通知相手に対して通知が不可のエントリは隠蔽処理を施したエントリとなり、
   通知相手に対して通知が可能なエントリは隠蔽処理を施していないエントリとなるように前記ログ記憶手段が記憶しているエントリから通知相手に通知するログを生成するログ構成手段と、
   通知相手に対応する前記累積記憶手段が保持するエントリの累積に電子署名を施したデータと前記ログ構成手段が生成したログとを含むデータを前記通知相手に送信する検証要求手段と、
   を備えた情報処理端末。
2. 前記累積記憶手段が保持するエントリの累積がエントリの累積ハッシュであることを特徴とする請求項１に記載の情報処理端末。
3. 請求項１に記載の情報処理端末に装着されるセキュアデバイスであり、
   情報処理端末の状態の変化を示すデータであるエントリの累積を保持する累積記憶手段と、
   前記累積記憶手段に保持されるエントリの累積の更新を行う累積演算手段と、
   前記エントリの累積に電子署名を行う署名手段と、
   前記情報処理端末から受信したログを検証する検証手段と、
   サービスを提供するサービスサーバと、
   を備えたセキュアデバイス。
4. 実行環境を提供する実行環境提供手段と、
   実行環境を記憶する実行環境記憶手段と、
   をさらに備えた請求項３に記載のセキュアデバイス。
5. 前記ログ複数測定手段が、通知相手が異なる場合であってもエントリの累積の値が同じになる場合には、前記累積記憶手段には一つのエントリの累積として保持されるように更新を指示することを特徴とする請求項１に記載の情報処理端末。
6. 前記ログ隠蔽手段は、マスターキーを保持し、エントリＩＤを前記マスターキーにより暗号化したものから暗号鍵を生成し、エントリを前記暗号鍵で暗号化することを特徴とする請求項１に記載の情報処理端末。
7. 前記ログ隠蔽手段は、暗号鍵をランダムに生成し、エントリを前記暗号鍵で暗号化し、
   前記暗号鍵を隠蔽情報として記憶する隠蔽情報記憶手段を備えることを特徴とする請求項１に記載の情報処理端末。
8. 前記ログ隠蔽手段が、エントリの内容の一部または全部を削除することを特徴とする請求項１に記載の情報処理端末。
9. エントリごとに異なるエントリＩＤを付与するＩＤ付与手段と、
   エントリごとの隠蔽に関する隠蔽情報をエントリＩＤと対応づけて記憶する隠蔽情報記憶手段と、
   隠蔽されたエントリの開示を要求された際に、エントリＩＤに対して隠蔽を解除する情報を取得ないしは生成し、要求してきた相手に開示してよいか判断し、開示してよいと判断した場合に、前記隠蔽を解除する情報または解除したエントリを渡すログ開示判定手段と、
   をさらに備えた請求項１に記載の情報処理端末。
10. 前記ログ開示判定手段が、開示してよいか判断する際に、隠蔽を解除したエントリを利用者に提示し、利用者にエントリを開示してよいか指定させることを特徴とする請求項９に記載の情報処理端末。
11. 情報処理端末が自端末の状態変化の履歴であるログをサーバに通知する方法であって、
    通知可能でないサーバ向けにエントリを隠蔽してログを生成するステップと、
    前記ログと、前記ログに対応する累積ハッシュに電子署名を施したデータと、前記電子署名を検証するための証明書とを連結した署名付ログを生成するステップと、
    前記署名付ログを前記サーバに送信するステップと、
    を有する状態通知方法。

Images