(57)【特許請求の範囲】
【請求項１】
ヘッダとボディとに区分される通信データであって、前記通信データの宛先ホスト名が前記ヘッダに含まれ、検証の対象となる検証対象データが前記ボディに含まれる通信データを受信する通信データ受信部と、
前記検証対象データがマルウエア及び不正なユーザの少なくともいずれかにより不正に操作されたデータでないことを検証するのに用いられる検証情報が前記通信データのボディに含まれているか否かを検証するとともに、前記通信データの送信元の装置の利用者が指定した前記検証対象データの宛先アドレスが前記通信データのボディに含まれているか否かを検証し、前記検証情報が前記通信データのボディに含まれている場合に、前記検証対象データと前記検証情報とを用いて、前記検証対象データが不正に操作されたデータでないことを検証し、前記宛先アドレスが前記通信データのボディに含まれている場合に、前記通信データのヘッダの宛先ホスト名とボディの宛先アドレスとを照合し、前記宛先ホスト名で示される宛先ホストと前記宛先アドレスで示される宛先ホストとが一致するか否かを判定するデータ検証部と、
前記データ検証部により前記検証対象データが不正に操作されたデータでないと判定され、更に、前記宛先ホスト名で示される宛先ホストと前記宛先アドレスで示される宛先ホストとが一致すると判定された場合に、前記ボディから前記検証情報及び前記宛先アドレスを除外し、前記検証情報及び前記宛先アドレスが除外された通信データを転送する通信データ転送部とを有することを特徴とするデータ検証装置。
【請求項２】
前記データ検証部は、
前記通信データに前記検証情報が含まれていない場合及び前記検証対象データが不正に操作されたデータであると判定した場合の少なくともいずれかにおいて、前記通信データ転送部に前記通信データの転送を実施させることなく、前記通信データの送信元の装置に対してエラーを通知することを特徴とする請求項１に記載のデータ検証装置。
【請求項３】
前記データ検証部は、
前記通信データのボディに前記宛先アドレスが含まれていない場合及び前記宛先ホスト名で示される宛先ホストと前記宛先アドレスで示される宛先ホストとが一致しないと判定した場合の少なくともいずれかにおいて、前記通信データ転送部に前記通信データの転送を実施させることなく、前記通信データの送信元の装置に対してエラーを通知することを特徴とする請求項１に記載のデータ検証装置。
【請求項４】
前記通信データ受信部は、
前記ボディの内容が暗号化されている通信データを受信し、
前記データ検証装置は、更に、
前記通信データのボディの内容を復号する復号部を有し、
前記データ検証部は、
前記復号部により前記通信データのボディの内容が復号された後に、前記検証情報が前記通信データのボディに含まれているか否かを検証するとともに、前記宛先アドレスが前記通信データのボディに含まれているか否かを検証することを特徴とする請求項１に記載のデータ検証装置。
【請求項５】
前記通信データ受信部は、
前記検証対象データとして、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）データ及び電子メールデータのいずれかが含まれる通信データを受信することを特徴とする請求項１に記載のデータ検証装置。
【請求項６】
ヘッダとボディとに区分される通信データであって、前記通信データの宛先ホスト名が前記ヘッダに含まれ、検証の対象となる検証対象データが前記ボディに含まれる通信データを受信する通信データ受信処理と、
前記検証対象データがマルウエア及び不正なユーザの少なくともいずれかにより不正に操作されたデータでないことを検証するのに用いられる検証情報が前記通信データのボディに含まれているか否かを検証するとともに、前記通信データの送信元の装置の利用者が指定した前記検証対象データの宛先アドレスが前記通信データのボディに含まれているか否かを検証し、前記検証情報が前記通信データのボディに含まれている場合に、前記検証対象データと前記検証情報とを用いて、前記検証対象データが不正に操作されたデータでないことを検証し、前記宛先アドレスが前記通信データのボディに含まれている場合に、前記通信データのヘッダの宛先ホスト名とボディの宛先アドレスとを照合し、前記宛先ホスト名で示される宛先ホストと前記宛先アドレスで示される宛先ホストとが一致するか否かを判定するデータ検証処理と、
前記データ検証処理により前記検証対象データが不正に操作されたデータでないと判定され、更に、前記宛先ホスト名で示される宛先ホストと前記宛先アドレスで示される宛先ホストとが一致すると判定された場合に、前記ボディから前記検証情報及び前記宛先アドレスを除外し、前記検証情報及び前記宛先アドレスが除外された通信データを転送する通信データ転送処理とをコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルウエアに対処するための技術に関する。
【背景技術】
【０００２】
近年、マルウエアが機密情報を組織外に漏洩させる事故が問題となっている。
マルウエアを用いたサイバー攻撃は高度化され、非特許文献１に示されるＡｄｖａｎｃｅｄ  Ｐｅｒｓｉｓｔｅｎｔ  Ｔｈｒｅａｔ（以下、「ＡＰＴ」という）と呼ばれる攻撃では、電子メールの添付ファイルなどで組織に侵入したマルウエアが、計算機に感染し、さらに、攻撃者が運用するインターネット上のＣｏｍｍａｎｄ  ＆  Ｃｏｎｔｒｏｌサーバ（以下、「Ｃ＆Ｃサーバ」という」と通信し、新しいマルウエアや攻撃ツールをダウンロードしたり自身をアップデートする。
そして、マルウエアは、組織内を偵察し、ファイルサーバを見つけ、機密ファイルをＣ＆Ｃサーバへ漏洩する。
マルウエアがＣ＆Ｃサーバとの通信やファイルの漏洩に用いる通信は、一般的に組織とインターネット間で許可されているプロトコルであるＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）が多く、ファイルの漏洩はＰＯＳＴが多い。
また、ＡＰＴにおいては、マルウエアはユーザの計算機の画面をキャプチャしてＣ＆Ｃサーバへ送信し、攻撃者は画面キャプチャを観察してどのような操作をユーザが実施しているか把握するケースもある。
また、Ｃ＆Ｃサーバの命令を受け、マルウエアがファイルを検索しファイルを移動する、などの操作を行う場合もある。
このように、近年の組織へのサイバー攻撃は高度化しており、決定的な対策が無い状況にある。
【０００３】
インターネットへのファイルの情報漏洩対策として、非特許文献２に記載の技術がある。
当技術では、ファイルが組織外に送信されようとしていることを検知し、そのファイルの情報が、流通許可リストに登録されているか否かをもって、送信の可否を判断する。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】「新しいタイプの攻撃」の対策に向けた設計・運用ガイド  改訂第２版，ＩＰＡ
【非特許文献２】Ｐ２Ｐファイル交換ソフトウエア環境におけるノード型情報流通防止機能の提案、松岡他、２００８−ＣＳＥＣ−４２
【発明の概要】
【発明が解決しようとする課題】
【０００５】
非特許文献２に記載の技術では、ユーザは、事前に流通許可リストへ公開可能なファイルの情報を登録する必要があり、さらに、公開可能なファイルの情報を追加／削除し常にメンテナンスする必要がある。
また、流通許可リストへのファイルの情報の登録方法についてはＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）を使うなどの具体的な方法が記述されていない。
近年の高度化したサイバー攻撃においては、前述したように、攻撃者がユーザの操作を観察し、どのような処理を行っているか把握したうえで、マルウエアを操作するので、流通許可リストの登録方法を模擬し、漏洩したいファイルの情報を流通許可リストに登録して、ファイルを漏洩する可能性がある。
【０００６】
本発明は、上述のような事情に鑑みたものであり、公開可能なファイルの情報を登録せずに、マルウエア又は不正なユーザによる情報漏洩を防止することを主な目的とする。
【課題を解決するための手段】
【０００７】
本発明に係るデータ検証装置は、
検証の対象となる検証対象データが含まれる通信データを受信する通信データ受信部と、
前記検証対象データがマルウエア及び不正なユーザの少なくともいずれかにより不正に操作されたデータでないことを検証するのに用いられる検証情報が前記通信データに含まれているか否かを検証し、前記通信データに前記検証情報が含まれている場合に、前記検証対象データと前記検証情報とを用いて、前記検証対象データが不正に操作されたデータでないことを検証するデータ検証部と、
前記データ検証部により前記検証対象データが不正に操作されたデータでないと判定された場合に、前記通信データから前記検証情報を除外し、前記検証情報が除外された通信データを転送する通信データ転送部とを有することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、通信データに検証対象データとともに検証情報が含まれ、検証情報により検証対象データが不正に操作されたデータでないと検証できた場合のみ、通信データから検証情報を除外し、通信データを転送する。
このため、公開可能なファイルの情報を登録せずに、マルウエア又は不正なユーザによる情報漏洩を防止することができる。
【図面の簡単な説明】
【０００９】
【図１】実施の形態１に係る端末装置の構成例を示す図。
【図２】実施の形態１に係る検印処理部の動作例を示すフローチャート図。
【図３】実施の形態１に係る検印データの生成手順を示すフローチャート図。
【図４】実施の形態１に係る検印データの生成手順を示すフローチャート図。
【図５】実施の形態１に係る検査サーバ装置の構成例を示す図。
【図６】実施の形態１に係る検査サーバ装置の動作例を示すフローチャート図。
【図７】実施の形態１に係る検印データの検証手順を示すフローチャート図。
【図８】実施の形態１に係る検印データの検証手順を示すフローチャート図。
【図９】実施の形態１に係る通信システムの概要を示す図。
【図１０】実施の形態１に係る検印処理用画面の例を示す図。
【図１１】実施の形態１に係る検印付きファイルの例を示す図。
【図１２】実施の形態２に係る端末装置の構成例を示す図。
【図１３】実施の形態２に係る検印処理部の動作例を示すフローチャート図。
【図１４】実施の形態３に係る端末装置の構成例を示す図。
【図１５】実施の形態３に係る検印処理部の動作例を示すフローチャート図。
【図１６】実施の形態４に係る検印処理部の動作例を示すフローチャート図。
【図１７】実施の形態４に係るシステム構成例を示す図。
【図１８】実施の形態５に係る検印処理用画面の例を示す図。
【図１９】実施の形態５に係る検印付きファイルの例を示す図。
【図２０】実施の形態５に係る端末装置の構成例を示す図。
【図２１】実施の形態６に係る検印追加部の構成例を示す図。
【図２２】実施の形態６に係る検査対象データ分解部の構成例を示す図。
【図２３】実施の形態６に係る検印追加部の構成例を示す図。
【図２４】実施の形態６に係る検査対象データ分解部の構成例を示す図。
【図２５】実施の形態６に係る検印追加部の構成例を示す図。
【図２６】実施の形態６に係る検査対象データ分解部の構成例を示す図。
【図２７】実施の形態７に係る通信システムの概要を示す図。
【図２８】実施の形態８に係る通信システムの概要を示す図。
【図２９】実施の形態１〜８に係る端末装置及び検査サーバ装置のハードウエア構成例を示す図。
【発明を実施するための形態】
【００１０】
実施の形態１〜８では、ＨＴＴＰ  ＰＯＳＴや電子メールの添付ファイルで組織外に送信するファイルに検印を付与し、プロキシサーバやメールサーバで検印を確認し、検印が正しく付与されている場合に、検印を除去したうえで組織外に送信を許可することで、マルウエアによる情報漏洩を防止する構成を説明する。
つまり、実施の形態１〜８では、ユーザがＨＴＴＰ  ＰＯＳＴでインターネット上のＷｅｂサイトへファイル送信を行っていることを確実に識別し、それ以外のＨＴＴＰ  ＰＯＳＴによるファイル送信をブロックすることで、ユーザが意図せぬファイル送信をブロックし、情報漏洩を防止する。
そして、本方式では、組織外に送信可能なリストを管理する必要が無く、マルウエアによる本方式の模擬による不正なＨＴＴＰ  ＰＯＳＴについても対策を講じてある。
【００１１】
実施の形態１．
本実施の形態に係る通信システムの構成例と動作の概要を図９に示す。
【００１２】
図９において、端末装置５０００は、ユーザ５００５が利用するコンピュータである。
端末装置５０００は、通信装置の例に相当する。
端末装置５０００は、ハードウエアとして、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、メモリ、ハードディスク装置、通信カードが配備されている。
また、端末装置５０００には、ソフトウエアとして、例えば、ブラウザ５００４と検印処理部５００２が含まれている。
ファイル５００１は、端末装置５０００が、ブラウザ５００４を用いて、Ｗｅｂサーバ装置５０１２にＨＴＴＰにより送信するファイルである。
検印処理部５００２は、ファイル５００１に検印を付与する手段である。
検印付きファイル５００３は、検印処理部５００２によりファイル５００１に検印が付与されたファイルである。
【００１３】
検査サーバ装置５００９は、プロキシサーバ装置５００８と連携し、ＨＴＴＰ  ＰＯＳＴデータ内のデータを検査し、ＨＴＴＰ  ＰＯＳＴされる内容を検査する。
検査サーバ装置５００９は、データ検証装置の例に相当する。
【００１４】
動作の概要について図９を用いて以下に記述する。
なお、以下の（１）〜（５）は、図９の（１）〜（５）に対応している。
【００１５】
（１）ユーザ５００５は、Ｗｅｂサーバ装置５０１２にＨＴＴＰでＰＯＳＴしたいファイル５００１に対して、本実施の形態に係る検印処理部５００２で検印を付与し、検印付きファイル５００３を生成する。
検印付きファイル５００３は、もとのファイル５００１と検印データとユーザ識別子に分離可能である。
検印データ及びユーザ識別子は、ファイル５００１がマルウエアにより操作されたデータでないことを検証するのに用いられる情報である。
【００１６】
（２）ユーザ５００５は、ブラウザ５００４でＷｅｂサーバ装置５０１２のＷｅｂページを表示し、ファイル送信のページにおいて、ファイル５００１の代わりに、検印付きファイル５００３を端末装置５０００から送信する。
この時、ブラウザ５００４は、ＨＴＴＰのボディ（メッセージボディ、以下、ＨＴＴＰボディと表記する）に、検印付きファイル５００３を含めるが、この処理は一般のブラウザに備わっている機能である。
なお、端末装置５０００からは、検印付きファイル５００３はＨＴＴＰ  ＰＯＳＴデータ５００６として送信される。
ＨＴＴＰ  ＰＯＳＴデータ５００６は、ＨＴＴＰヘッダとＨＴＴＰボディで構成される。
なお、厳密には、ＨＴＴＰ  ＰＯＳＴデータ５００６には、ＨＴＴＰヘッダとＨＴＴＰボディの他に、リクエストラインや空行も含まれるが、これらは、本実施の形態の説明に直接関係しないため割愛する。
【００１７】
（３）検印付きファイル５００３が含まれるＨＴＴＰ  ＰＯＳＴデータ５００６は、端末装置５０００からＬＡＮ５０１３を経由し、（ネットワーク）スイッチ５００７を通りプロキシサーバ装置５００８に送信される。
なお、プロキシサーバ装置５００８へは、ＨＴＴＰ  ＰＯＳＴデータ５００６にＩＰヘッダ、ＴＣＰヘッダ等が付加されたパケットとして送信される。
【００１８】
（４）プロキシサーバ装置５００８は、受信した、検印付きファイル５００３を含んだＨＴＴＰ  ＰＯＳＴデータ５００６をネットワーク経由などで検査サーバ装置５００９に転送する。
プロキシサーバ装置５００８が外部機能を利用するプロトコルである「ｉｎｔｅｒｎｅｔ  ｃｏｎｔｅｎｔ  ａｄａｐｔａｔｉｏｎ  ｐｒｏｔｏｃｏｌ」などを使用してもよい。
なお、ネットワーク経由だけでなく、プロキシサーバ装置５００８と検査サーバ装置５００９間において、検印付きファイル５００３を含んだＨＴＴＰ  ＰＯＳＴデータ５００６を物理媒体経由（オフライン）で受け渡しするようにしてもよい。
【００１９】
（５）検査サーバ装置５００９は、検印付きファイル５００３を含んだＨＴＴＰ  ＰＯＳＴデータ５００６を受信する。
また、検査サーバ装置５００９は、抽出したＨＴＴＰ  ＰＯＳＴデータ５００６の検印を検証する。
つまり、検査サーバ装置５００９は、ＨＴＴＰ  ＰＯＳＴデータ５００６に検印データ及びユーザ識別子が含まれているかを判定し、ＨＴＴＰ  ＰＯＳＴデータ５００６に検印データ及びユーザ識別子が含まれている場合は、ファイル５００１がマルウエアにより操作されたデータでないかどうかを検証する。
検印データ及びユーザ識別子が存在し、検印データ及びユーザ識別子が正しければ（ファイル５００１がマルウエアにより操作されたデータでなければ）、検査サーバ装置５００９は、検印付きファイル５００３から検印データ及びユーザ識別子を削除し、ファイル５００１を含んだＨＴＴＰ  ＰＯＳＴデータ５０１０を生成する。
一方、ＨＴＴＰ  ＰＯＳＴデータ５００６に検証データ及びユーザ識別子が含まれていない場合や、検印データ及びユーザ識別子が正しくない場合は、検査サーバ装置５００９は、エラーを出力する。
【００２０】
（６）検査サーバ装置５００９は、検印データ及びユーザ識別子が正しい場合は、ファイル５００１を含んだＨＴＴＰ  ＰＯＳＴデータ５０１０をプロキシサーバ装置５００８へネットワーク経由などで転送する。
検査サーバ装置５００９がエラーを出力した場合は、これをプロキシサーバ装置５００８へ転送する。
【００２１】
（７）プロキシサーバ装置５００８は、検査サーバ装置５００９から受け取った、ファイル５００１を含んだＨＴＴＰ  ＰＯＳＴデータ５０１０を、インターネット５０１１を経由してＷｅｂサーバ装置５０１２へ送信する。
プロキシサーバ装置５００８は、検査サーバ装置５００９からエラーを受け取った場合は、インターネットへ何も送信せず、ユーザ５００５の端末装置５０００へＨＴＴＰのエラーメッセージを送る。
【００２２】
次に、図９の端末装置５０００の詳細を図１及び図２を用いて説明する。
図１は、端末装置５０００の内部構成例を示し、図２は、端末装置５０００の動作例を示す。
なお、図１及び図２では、端末装置１及び検印処理部１００と表記している。
また、図１では、本実施の形態の説明に必要な要素だけを示しており、図１に示す以外の要素が端末装置１に追加されてもよい。
【００２３】
図１に示すように、検印処理部１００は、データ入力部１０１、検印生成部１０２、検印鍵保存部１０３、検印追加部１０５及び検印データ出力部１０６に大別される。
【００２４】
検印処理部１００において、データ入力部１０１は、検印対象データ１２０１を入力する。
検印対象データ１２０１は、例えば、図９におけるファイル５００１である。
データ入力部１０１は、入力された検印対象データ１２０１を被検印データ１１０１として出力する（図２のＳ１０１）。
データ入力部１０１は、例えば、ファイル５００１のファイル構造から、実際のデータ部分を取り出す処理を行い、被検印データ１１０１として出力する。
なお、被検印データ１１０１は検証対象データの例に相当する。
【００２５】
検印生成部１０２は、被検印データ１１０１を入力し、また、ユーザ５００５の識別子である、ユーザ識別子１２０７を入力する。
ユーザ識別子１２０７は、ＧＵＩから入力してもよいし、設定ファイルから読み込んでもよい。
次に、検印生成部１０２は、検印鍵保存部１０３に検印鍵読み込み命令１１０２を出力する。
検印鍵読み込み命令１１０２には、ユーザ識別子１２０７が含まれている。
【００２６】
検印鍵保存部１０３は、内部に、ユーザ識別子１２０７に対応付けて検印鍵１１０３を保存している。
検印鍵保存部１０３は、検印鍵読み込み命令１１０２に含まれるユーザ識別子１２０７に該当する検印鍵１１０３を取り出し、取り出した検印鍵１１０３を検印生成部１０２に出力し、検印生成部１０２は、検印鍵１１０３を入力する（図２のＳ１０２＿１）。
検印鍵１１０３は、図９のユーザ５００５が保持する公開鍵暗号のｐｒｉｖａｔｅ  ｋｅｙであり、ユーザ５００５しかその値を知らないものである。
【００２７】
検印生成部１０２は、被検印データ１１０１に対して、検印鍵１１０３を用いて検印データ１１０５を生成する（図２のＳ１０２＿２）。
検印データの生成手順を、図３のフローチャートを用いて説明する。
【００２８】
検印生成部１０２は、被検印データ１１０１を一方向性ハッシュ関数ｈ（）に入力する（図３のＳ２０１＿ｓｐ１）。
次に、検印生成部１０２は、一方向性ハッシュ関数ｈ（）の出力を、検印鍵１１０３（ｐｒｉｖａｔｅ  ｋｅｙ）で暗号化する。
この処理は、一般的な公開鍵暗号を用いた署名処理である。
そして、暗号化した結果を、検印データ１１０５とする（図３のＳ２０１＿ｓｐ２）。
【００２９】
検印生成部１０２は、生成した検印データ１１０５を検印追加部１０５へ出力する（図２のＳ１０２＿３）。
【００３０】
検印追加部１０５は、被検印データ１１０１と、検印データ１１０５と、ユーザ識別子１２０７を入力し、これらを連結して検印付きデータ１１０６を生成し、生成した検印付きデータ１１０６を検印データ出力部１０６へ出力する（図２のＳ１０５）。
検印データ１１０５及びユーザ識別子１２０７は検証情報の例に相当する。
【００３１】
検印データ出力部１０６は入力した検印付きデータ１１０６を検印付きデータ１２０４として出力する。
検印付きデータ１２０４は、例えば、図９における検印付きファイル５００３である（図２のＳ１０６）。
検印データ出力部１０６は、検印付きデータ１１０６をファイル構造へ変換して出力する。
【００３２】
パケット生成部１０７は、検印データ出力部１０６から検印付きデータ１２０４を入力し、検印付きデータ１２０４をＨＴＴＰボディとし、ＨＴＴＰボディにＨＴＴＰヘッダを付加してＨＴＴＰ  ＰＯＳＴデータを生成する。
このＨＴＴＰ  ＰＯＳＴデータが通信データの例に相当する。
更に、パケット生成部１０７は、ＨＴＴＰ  ＰＯＳＴデータにＩＰヘッダ、ＴＣＰヘッダ等を追加して、パケットを生成する。
パケット生成部１０７は、例えば、ブラウザ５００４に含まれる機能である。
【００３３】
パケット送信部１０８は、パケット生成部１０７により生成されたパケットをＬＡＮ５０１３に送信する。
パケット送信部１０８も、例えば、ブラウザ５００４に含まれる機能である。
【００３４】
次に、検査サーバ装置５００９の詳細を図５及び図６を用いて説明する。
図５は、検査サーバ装置５００９の内部構成例を示し、図６は、検査サーバ装置５００９の動作例を示す。
なお、図５及び図６では、検査サーバ装置３と表記している。
また、図５では、本実施の形態の説明に必要な要素だけを示しており、図５に示す以外の要素が検査サーバ装置３に追加されてもよい。
【００３５】
検査サーバ装置３において、データ入力部３０１は、送信対象データ３２０１を入力する。
送信対象データ３２０１は、端末装置１から送信されたパケットである。
送信対象データ３２０１は、ネットワークから入力されるため、図９における、検印付きファイル５００３を含んだＨＴＴＰ  ＰＯＳＴデータ５００６以外の要素を含む。
検印付きファイル５００３を含んだＨＴＴＰ  ＰＯＳＴデータ５００６は、送信対象データ３２０１のボディ部に含まれる。
ボディ部以外は、ヘッダ部であり、ＨＴＴＰ  ＰＯＳＴデータ５００６とは関係がない。
このため、データ入力部３０１は送信対象データ３２０１を解釈し、送信対象データ３２０１からボディ部を取り出すことで、検印付きファイルを含んだＨＴＴＰ  ＰＯＳＴデータ５００６を取り出す処理を行う。
この取り出したデータを、送信対象データ３１０１とする。
つまり、データ入力部３０１は、入力された送信対象データ３２０１を送信対象データ３１０１として出力する（図６のＳ３０１）。
【００３６】
送信対象データ分解部３０２は、送信対象データ３１０１を入力し、非検査対象データ３１０３と検査対象データ３１０２に分解し、各々を出力する（図６のＳ３０２）。
例えば、検印付きファイル５００３を含んだＨＴＴＰ  ＰＯＳＴデータ５００６を送信対象データ３１０１とした場合、非検査対象データ３１０３は、ＨＴＴＰヘッダが該当し、検査対象データ３１０２は、ＨＴＴＰボディが該当する。
【００３７】
以下はＨＴＴＰ  ＰＯＳＴデータのフォーマット例であるが、リクエストライン〜空行までは、前記のＨＴＴＰヘッダが該当し、メッセージボディが、前記のＨＴＴＰボディに該当する。
なお、ｘｘｘには実際には適切な値が設定される。
【００３８】
・リクエストライン
ＰＯＳＴ／ｃｇｉ−ｂｉｎ／ｓｕｂｍｉｔ．ｘｘｘ  ＨＴＴＰ／１．１
・リクエスト・ヘッダフィールド
Ａｃｃｅｐｔ：ｘｘｘ
Ａｃｃｅｐｔ−Ｌａｎｇｕａｇｅ：ｊａ
Ａｃｃｅｐｔ−Ｅｎｃｏｄｉｎｇ：ｘｘｘ
Ｒｅｆｅｒｅｒ：ｈｔｔｐ：／／○○○．ｓａｍｐｌｅ．△△△／ｓｈｉｎｓｅｉ．ｈｔｍｌ
Ｕｓｅｒ−Ａｇｅｎｔ：ｘｘｘ
Ｈｏｓｔ：○○○．ｓａｍｐｌｅ．△△△
・一般ヘッダフィールド
Ｐｒａｇｍａ：ｘｘｘ
Ｃｏｏｋｉｅ：ｘｘｘ
・エンティティヘッダフィールド
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｘｘｘ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：ｘｘ
・空行（ＣＲ（０ｘ０ｄ）＋ＬＦ（０ｘ０ａ）のみの行）
・メッセージ・ボディ（ＰＯＳＴするファイルのデータが入る）
ｘｘｘ
【００３９】
検査対象データ分解部３０３は、検査対象データ３１０２を入力し、検印データ３１０４と被検印データ３１０５とユーザ識別子３１０９に分解して各々を出力する（図６のＳ３０３）。
検印データ３１０４は、図１における検印データ１１０５であり、被検印データ３１０５は、図１における被検印データ１１０１である。
ユーザ識別子３１０９は、図１におけるユーザ識別子１２０７である。
【００４０】
検印検証部３０４は、検印データ３１０４と被検印データ３１０５とユーザ識別子１２０７を入力する。
検印検証部３０４は、検証鍵保存部３０５に、検証鍵読み込み命令３１０６を出力する。
検証鍵読み込み命令３１０６には、ユーザ識別子３１０９が含まれる。
検証鍵保存部３０５は、ユーザ識別子３１０９に該当する検証鍵３１０７を取り出し、取り出した検証鍵３１０７を検印検証部３０４へ出力し、検印検証部３０４は検証鍵３１０７を入力する（図６のＳ３０４＿１）。
【００４１】
検印検証部３０４は、検証鍵３１０７を用いて、検印データ３１０４と被検印データ３１０５から、検印データ３１０４を検証する（図６のＳ３０４＿２）。
検印データ３１０４の検証手順を図７のフローチャートを用いて説明する。
【００４２】
検印検証部３０４は、被検印データ３１０５を一方向性ハッシュ関数ｈ（）に入力し、この結果をｈ１とする（図７のＳ３０４＿ｖｐ１）。
また、検印検証部３０４は、検印データ３１０４を検証鍵３１０７（図９のユーザ５００５の公開鍵暗号のｐｕｂｌｉｃ  ｋｅｙ）で復号し、結果をｈ２とする（図７のＳ３０４＿ｖｐ２）。
次に、検印検証部３０４は、前記ｈ１と、ｈ２の結果を比較し、一致するか確認する（図７のＳ３０４＿ｖｐ３）。
一致すれば検印データ３１０４は検証成功と判断する（図７のＳ３０４＿ｖｐ４）。
つまり、被検印データ３１０５はマルウエアにより送信されたものではないと判断する。
一方、ｈ１とｈ２が一致しない場合は、検証失敗と判断する（図７のＳ３０４＿ｖｐ５）。
この処理は、一般的な公開鍵暗号による署名の検証処理である。
暗号化／復号処理においては、データをｐｕｂｌｉｃ  ｋｅｙで暗号化し、ｐｒｉｖａｔｅ  ｋｅｙで復号を行うが、署名／検証処理においては、ｐｒｉｖａｔｅ  ｋｅｙで暗号化し、ｐｕｂｌｉｃ  ｋｅｙで復号する。
また、署名対象のデータが大きい場合に、署名対象のデータそのものではなく、一方向性ハッシュ関数で縮小したデータに対して署名／検証を行う（本実施の形態で示した例が該当する）。
【００４３】
なお、検印処理部１００における検印生成部１０２が保持する一方向性ハッシュ関数と、公開鍵暗号のアルゴリズムは、各々、検査サーバ装置３における検印検証部３０４が保持する一方向性ハッシュ関数と、公開鍵暗号のアルゴリズムと一致させる。
予め、検印処理部１００と検査サーバ装置３で使用するアルゴリズムを合意し、実装してもよい。
また、複数のアルゴリズムを実装可能である場合、署名のフォーマットに何のアルゴリズムを使用したか含める方法がある。
検印処理部１００は、署名に使用した一方向性ハッシュ関数と、公開鍵暗号のアルゴリズムの識別子を署名のフォーマットに含め、検査サーバ装置３は署名のフォーマットから署名に使用した一方向性ハッシュ関数と、公開鍵暗号のアルゴリズムの識別子を取り出し、検証に使用するアルゴリズムを判断する。
この様な方法は、既存の技術を使用してもよい。
【００４４】
検印検証部３０４は、検印データ３１０４が空ではなく、かつ、検印が正しければ、被検印データ３１０５を出力する（図７のＳ３０４＿３）。
検印検証部３０４は、検印データ３１０４が空の場合（検印データ３１０４が存在しない）、或いは、検印データの検証が正しく無い場合は、エラー通知３２０３を出力する。
【００４５】
送信データ生成部３０６は、被検印データ３１０５と非検査対象データ３１０３を入力し、これらを連結し、修正送信データ３１０８を出力する（図７のＳ３０６）。
修正送信データ３１０８は、図９における、ファイル５００１を含んだＨＴＴＰ  ＰＯＳＴデータ５０１０が該当する。
すなわち、修正送信データ３１０８は、送信対象データ３１０１から検印データ３１０４及びユーザ識別子３１０９が除外されたデータである。
【００４６】
データ出力部３０７は、修正送信データ３１０８を入力し、修正送信データ３２０２を出力する（図７のＳ３０７）。
修正送信データ３２０２は、例えば、ネットワークへ出力されるため、ファイル５００１を含んだＨＴＴＰ  ＰＯＳＴデータ５０１０をボディ部に含めたネットワークデータ（パケット）である必要がある。
データ出力部３０７はネットワークデータを生成し、ボディ部にファイル５００１を含んだＨＴＴＰ  ＰＯＳＴデータ５０１０を含めることで、ネットワークデータとして修正送信データ３２０２を出力する。
【００４７】
なお、図５において、データ入力部３０１は通信データ受信部の例に相当し、検印検証部３０４はデータ検証部の例に相当し、送信データ生成部３０６及びデータ出力部３０７は通信データ転送部の例に相当する。
【００４８】
図９の検印処理部５００２（図１の検印処理部１００）がユーザ５００５に提示する画面データの例を検印処理用画面６００１として、図１０に示す。
検印処理用画面６００１において、ユーザ５００５は、送信するファイルを、送信対象ファイル６００２の欄において指定する。
図１０の例では、「Ｃ：￥ｗｏｒｋ￥ｓａｍｐｌｅ．ｃｓｖ」を指定している。
次に、ユーザ５００５は、検印したファイルを出力するファイル名を、検印付きファイルの出力パス６００３の欄に指定する。
図１０の例では、「Ｃ：￥ｗｏｒｋ￥ｓａｍｐｌｅ．ｃｓｖ．ｓｉｇ」を指定している。
次に、ユーザ５００５は、検印ボタン６００４を押す。
この時、検印処理部５００２（検印処理部１００）は、認証画面６００５を表示して、ユーザ５００５にパスワードを入力させてもよい。
この結果、「Ｃ：￥ｗｏｒｋ￥ｓａｍｐｌｅ．ｃｓｖ」（図９のファイル５００１に相当）に検印を付与したファイルである、「Ｃ：￥ｗｏｒｋ￥ｓａｍｐｌｅ．ｃｓｖ．ｓｉｇ」が出力される（図９の検印付きファイル５００３に相当）。
また、図１においては、送信対象ファイル６００２は、送信対象ファイル１２０５に該当し、検印付きファイルの出力パス６００３は、検印付きファイルの出力パス１２０６に該当する。
【００４９】
図９のファイル５００１と、検印付きファイル５００３の関係を図１１に示す。
ファイル７００１（図９のファイル５００１）に検印を付与すると、検印付きファイル７００２（図９の検印付きファイル５００３）の様に、ファイル７００１の前に検印データ（Ｂ＆Ｍ９｀＠／Ｑ！…）とユーザ識別子が連結される。
なお、図１１の形式は一例であり、検印のアルゴリズムによっては、他のフォーマットをとり得る。
【００５０】
本実施の形態における、検印鍵１１０３と検証鍵３１０７の運用は例えば以下がある。
【００５１】
ユーザ５００５が、公開鍵暗号の鍵ペア（ｐｒｉｖａｔｅ  ｋｅｙ／ｐｕｂｌｉｃ  ｋｅｙ）を生成し、ｐｒｉｖａｔｅ  ｋｅｙをユーザ識別子１２０７と共に検印処理部１００の検印鍵保存部１０３に保存する。
さらに、検査サーバ装置３の管理者に依頼して、ｐｕｂｌｉｃ  ｋｅｙをユーザ５００５のユーザ識別子１２０７と共に検査サーバ装置３の検証鍵保存部３０５に保存してもらう。
【００５２】
或いは、ユーザ５００５が、公開鍵暗号の鍵ペア（ｐｒｉｖａｔｅ  ｋｅｙ／ｐｕｂｌｉｃ  ｋｅｙ）を生成し、ｐｒｉｖａｔｅ  ｋｅｙをユーザ識別子１２０７と共に検印処理部１００の検印鍵保存部１０３に保存する。
さらに、ユーザ５００５は認証局にｐｕｂｌｉｃ  ｋｅｙ  とユーザ識別子１２０７を提示し、公開鍵証明書として発行してもらう（ユーザ識別子を含む）。
さらに、ユーザ５００５は、検査サーバ装置３の管理者に依頼して、公開鍵証明書を検査サーバ装置３の検証鍵保存部３０５に保存してもらう。
この場合、ユーザ識別子は公開鍵証明書に含まれている。
【００５３】
検証鍵保存部３０５は、図６のＳ３０４＿１において、外部の公開鍵証明書のレポジトリと通信し、ユーザ識別子１２０７に相当する公開外証明書をレポジトリから取得してもよい。
【００５４】
本実施の形態では、検印の方法として、公開鍵暗号に基づく方法を示したが、以下の様に共通鍵暗号に基づく方法を適用してもよい。
以下にて、共通鍵暗号を適用する場合の差異のみ示す。
【００５５】
まず、検印処理部１００の動作について差異のみ説明する。
図１における検印鍵保存部１０３に保存されている検印鍵１１０３は、検印処理部１００を保持するユーザと、検査サーバ装置３で共有している、共通鍵暗号の共通鍵である。
そして、検印生成部１０２の検印の処理は、図４に従う。
まず、被検印データ１１０１と検印鍵１１０３（共通鍵）を連結する（図４のＳ２０１＿ｓｋｈ１）。
次に、被検印データ１１０１と検印鍵１１０３（共通鍵）を連結した結果を、一方向性ハッシュ関数ｈ（）に入力し結果を検印データ１１０５とする（図４のＳ２０１＿ｓｋｈ２）。
【００５６】
次に、検査サーバ装置３の動作について差異のみ説明する。
図５における検証鍵保存部３０５に保存されている検証鍵３１０７は、検印処理部１００を保持するユーザと、検査サーバ装置３で共有している共通鍵暗号の共通鍵である。
検印検証部３０４の検印の検証の処理は、図８に従う。
まず、被検印データ３１０５と検証鍵３１０７（共通鍵）を連結する（図８のＳ３０４＿ｖｋｈ１）。
次に、被検印データ３１０５と検証鍵３１０７（共通鍵）を連結した結果を一方向性ハッシュ関数ｈ（）に入力する（結果をｈ１とする）（図８のＳ３０４＿ｖｋｈ２）。
次にｈ１と検印データ３１０４は一致するか確認する（図８のＳ３０４＿ｖｋｈ３）。
一致した場合、検証成功と判断する（図８のＳ３０４＿ｖｋｈ４）。
一致しない場合は、検証失敗と判断する（図８のＳ３０４＿ｖｋｈ５）。
【００５７】
また、検印において、暗号を用いた検印の例を示してきたが、例えば、検印処理部１００が固定で保持するキーワードを検印データ１１０５としてもよい。
検印処理部１００と検査サーバ装置３の動作について、差異のみ示す。
この場合は、検印処理部１００において、検印鍵保存部１０３は使用しない（図２のＳ１０２＿１を行わない）。
ここでは、例えば「ａｂｃｄｅｆｇｈｉｊｋｌｍｎ」という文字列を、検印データ１１０５とする（図２のＳ１０２＿２を当処理に置き換える）。
この文字列は、検査サーバ装置３側でも予め固定で保持する。
検査サーバ装置３においては、検印データ３１０４として、「ａｂｃｄｅｆｇｈｉｊｋｌｍｎ」が現れた場合に、検印が正しいと判断する（図６のＳ３０４＿２を当処理に置き換える）。
この場合、検査サーバ装置３において、検証鍵保存部３０５は使用しない（図６のＳ３０４＿１を行わない）。
【００５８】
この様に、本実施の形態では、ユーザは、ＨＴＴＰ  ＰＯＳＴするファイルに検印を付与し、検査サーバ装置では、ＨＴＴＰデータのボディ部に検印が付与されたファイルのデータが存在するか検査する。
マルウエアは、通常、ファイルをそのままＨＴＴＰ  ＰＯＳＴするため、検査サーバ装置で検査した場合に、ＨＴＴＰデータのボディ部に検印が存在しないため、エラー通知が発生し、検査サーバ装置からプロキシサーバ装置へ、ＰＯＳＴしようとしているＨＴＴＰデータが転送されない。
従って、マルウエアはインターネットへファイルを漏洩できない。
【００５９】
このように、本実施の形態によれば、マルウエアは、インターネットへファイルを送信できないため、マルウエアによるインターネットへのファイルの漏洩を防止する効果がある。
さらに、検印処理部や、検査サーバ装置において、送信を許可するファイルのリストを管理する必要が無いという効果がある。
【００６０】
実施の形態２．
本実施の形態では、高度な機能を持つマルウエアが、端末上のファイルを盗み、検印処理部を起動して、検印付きファイルとしてＨＴＴＰ  ＰＯＳＴする場合への対策として、検印時の処理において、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）トークンやスマートカードなどの外部デバイスを組み合わせる構成を説明する。
なお、以下では、実施の形態１との差異のみ説明する。
また、以下では、検印の方法は、公開鍵暗号と一方向性ハッシュ関数を用いる例で示す。
【００６１】
図１２は、本実施の形態に係る端末装置１の構成例を示す。
図１２では、図１の構成と比較して、検印鍵保存部１０３が省略され、代わりに、外部機器２とのインタフェースとなる外部機器連携部１０４が設けられている。
外部機器２は、例えば、ＵＳＢトークンやスマートカードである。
他の要素は、図１に示したものと同様であるため、説明を省略する。
【００６２】
次に、本実施の形態に係る検印処理を、図１３を参照して説明する。
【００６３】
本実施の形態に係る検印処理部１００では、検印生成部１０２は、検印鍵保存部１０３を使用せず、外部機器連携部１０４へ、被検印データ１１０１と検印命令１１０４を出力する（図１３のＳ１０２＿ｅｓ１）。
検印命令１１０４は、被検印データ１１０１に対して、一方向性ハッシュ関数ｈ（）と公開鍵暗号のｐｒｉｖａｔｅ  ｋｅｙによる暗号化を行え、という命令である。
例えば、図示していないが、外部機器２が、どのように検印を行うべきか（この場合は、公開鍵暗号と一方向性ハッシュ関数を用いた電子署名）の識別子や、一方向性ハッシュ関数ｈ（）や公開鍵暗号のアルゴリズムの識別子で構成される。
また、検印命令１１０４にはユーザ識別子も含まれる。
【００６４】
外部機器連携部１０４は、外部機器２とデータを受け渡し可能なフォーマットに、被検印データ１１０１と検印命令１１０４を変換し、各々、被検印データ２２０１と検印命令２２０２として外部機器２に出力する（図１３のＳ１０４＿ｅｓ１）。
【００６５】
外部機器２は、実施の形態１の検印生成部１０２における検印の処理の代わりに、被検印データ２２０１に検印を行い、検印データ２２０３を生成し、外部機器連携部１０４へ出力する（図１３のＳ２＿ｅｓ１）。
検印の際に、外部機器２内に保存されているｐｒｉｖａｔｅ  ｋｅｙを探す必要があるが、外部機器２は、ユーザ識別子と併せて管理されているｐｒｉｖａｔｅ  ｋｅｙを探す。
【００６６】
外部機器連携部１０４は、外部機器２から、検印データ２２０３を入力し、検印生成部１０２が解釈可能なフォーマットに変換して、検印データ１１０５として出力する（図１３のＳ１０４＿ｅｓ２）。
【００６７】
検印生成部１０２は、外部機器連携部１０４から検印データ１１０５を入力し、入力した検印データ１１０５を検印追加部１０５へ出力する（図２のＳ１０２＿３に相当する処理であり、図１３ではＳ１０２＿ｅｓ２として示している）。
【００６８】
外部機器２は、公開鍵暗号と一方向性ハッシュ関数を処理可能なスマートカードやＵＳＢトークンである。
外部機器連携部１０４は、外部機器２がＵＳＢトークンであれば、ＵＳＢの機能を呼び出すソフトウエア機能として実装する。
外部機器２がスマートカードであれば、外部機器連携部１０４と、外部機器２の間に（図示していないが）、リーダライタが介在する。
そして、外部機器連携部は、リーダライタの機能を呼び出すソフトウエア機能として実装する。
【００６９】
また、外部機器２において、公開鍵暗号の処理のみを実施する場合は次のように処理する。
検印生成部１０２から外部機器連携部１０４へ出力する被検印データ１１０１を、「データ入力部１０１の出力である被検印データ１１０１」に対し検印生成部１０２が一方向性ハッシュ関数を適用した値に置き換える。
この値は、被検印データ２２０１として外部機器２に出力されるので、外部機器２は、被検印データ２２０１に対して、公開鍵暗号のｐｒｉｖａｔｅ  ｋｅｙによる暗号化のみ行い、検印データ２２０３を生成する。
さらに、外部機器２は、検印データ２２０３を外部機器連携部１０４へ出力する。
この場合、検印命令１１０４は、被検印データ１１０１に対して、公開鍵暗号のｐｒｉｖａｔｅ  ｋｅｙによる暗号化を行え、という命令である。
【００７０】
上記した処理以外は、端末装置１及び検査サーバ装置３において実施の形態１と同じ処理が行われる。
検印の生成は、実施の形態１に示したように共通鍵暗号を使う方式でもよい。
【００７１】
本実施の形態では、検印の生成処理の一部を外部機器に処理させるので、外部機器を利用できないマルウエアは、ファイルに検印を付与できないので、インターネット上のＷｅｂサーバ装置にＨＴＴＰ  ＰＯＳＴしても、検査サーバ装置における検印の検査でエラーとなり、ファイルを漏洩できない効果がある。
このため、高度化されたマルウエアが、当方式を悪用しファイルを漏洩しようとしても、外部機器による検印が必要となり、悪用できない効果がある。
【００７２】
実施の形態３．
実施の形態２では、外部機器２に検印の生成処理の一部を処理させた。
本実施の形態では、外部機器２に検印の生成処理の一部を処理させるのではなく、検印の生成処理を行うために、外部機器が存在することを条件とする方式を示す。
以下では、検印時の処理について実施の形態２との差異のみ説明する。
【００７３】
本実施の形態では、検印生成部１０２と外部機器連携部１０４と外部機器２の間で入出力する追加のデータは図１４のようになる。
図１４では、作図上の理由で図示を省略しているが、図１２と同様に、被検印データ１１０１、検印命令１１０４、検印データ１１０５、被検印データ２２０１、検印命令２２０２、検印データ２２０３が入出力されるとともに、図１４に示すデータが入出力される。
【００７４】
図１５は、本実施の形態における検印生成の処理を示したものである。
検印処理部１００における他の動作は、実施の形態１に同じである。
図１４と図１５を用いて本実施の形態における検印生成部１０２の処理を示す。
【００７５】
まず、検印生成部１０２は、検印処理を行う前に、外部機器連携部１０４に対して、認証命令１１０７を出力する（図１５のＳ１０２＿ａ１）。
【００７６】
外部機器連携部１０４は、認証命令１１０７を入力すると、外部機器２との間で認証情報２２０５の交換を行い、外部機器２の認証を行う（図１５のＳ１０４＿１）。
例えば、認証方法として、外部機器２が保持している社員ＩＤを外部機器連携部１０４が読み出せるか否かをチェックする。
この場合は、外部機器連携部１０４は、外部機器２に対して、社員ＩＤ読み出しの命令を出力し、外部機器２は内部に格納している社員ＩＤを読み出し、外部機器連携部１０４へ出力する。
従って、社員ＩＤ読み出しの命令と社員ＩＤが、認証情報２２０５に該当する。
この例では、外部機器２が内部の決められた場所に社員ＩＤを保存しており、外部機器連携部１０４に対して、社員ＩＤを読み出して提供できることをもって、外部機器２を認証する、簡易な認証の例である。
【００７７】
別の例として、チャレンジアンドレスポンスの認証情報を交換する例を示す。
この場合、外部機器連携部１０４が生成した乱数Ｃを外部機器２に出力すると、外部機器２はＣに対して、予め外部機器連携部１０４と外部機器２の間で共有している鍵（ＳＫ）と関数ｆを用い演算を施す。
これを、Ｒ＝ｆ（Ｃ，ＳＫ）と表す。
関数ｆは、アルゴリズムとして、外部機器連携部１０４と外部機器２で予め実装しておく。
外部機器２は、この結果のＲを外部機器連携部１０４へ出力する。
外部機器連携部１０４は、Ｃに対して、自身の保持している鍵ＳＫを用いて、Ｒ’＝ｆ（Ｃ，ＳＫ）を演算する。
そして、外部機器２から入力されたＲとＲ’の比較を行い、Ｒ’＝Ｒであるか否かを確認する。
Ｒ’＝Ｒであれば、外部機器２は、外部機器連携部１０４と同じ鍵ＳＫを共有していると判断し、認証成功とする。
この例においては、ＣとＲが認証情報２２０５に該当する。
【００７８】
次に、外部機器連携部１０４は外部機器２を認証した結果を、認証結果１１０９として検印生成部１０２へ出力する（図１５のＳ１０４＿２）。
【００７９】
検印生成部１０２は、認証結果１１０９がＯＫ（外部機器２の認証成功）かＮＧ（外部機器２の認証失敗）を調べる（図１５のＳ１０２＿ａ２）。
ＯＫの場合、検印生成部１０２は、図２（実施の形態１）のＳ１０２＿１、Ｓ１０２＿２、Ｓ１０３＿３を処理する（図１５のＳ１０２＿１２３）。
ＮＧの場合、検印生成部１０２は、エラー通知１２０８を検印処理部の外へ出力する（図１５のＳ１０２＿ａ３）。
ＮＧの場合、検印処理部１００は、ユーザに、ＧＵＩにエラーメッセージを表示するなどで、検印処理部１００がエラーとなったことをユーザへ通知する。
この場合は、検印付きデータは検印処理部１００からは出力されない。
【００８０】
また、外部機器２を使用する場合に、外部機器２を利用するための認証データ２２０４を外部機器２に入力してもよい。
認証データ２２０４を外部機器２に入力する方法は、外部機器２に依存するが、外部機器２に端末装置５０００（図９）から入力するための、専用のＧＵＩ（アプリケーション）が別途用意される場合がある。
また、検印処理部１００において、認証データ２２０４を入力するためのＧＵＩを表示し、ユーザに認証データ２２０４を入力させ、外部機器連携部１０４を経由して、外部機器２に対して入力する方法がある（図１４の破線）。
【００８１】
本実施の形態では、検印処理に外部機器との連携を必要とするため、外部機器を利用できないマルウエアは、ファイルに検印を付与できないので、インターネット上のＷｅｂサーバ装置にＨＴＴＰ  ＰＯＳＴしても、検査サーバ装置における検印の検査でエラーとなり、ファイルを漏洩できない効果がある。
このため、高度化されたマルウエアが、当方式を悪用しファイルを漏洩しようとしても、外部機器が必要となり、悪用できない効果がある。
【００８２】
実施の形態４．
本実施の形態では、検印生成部１０２において、画像による認証を行う。
検印時の処理について実施の形態１との差異のみ説明する。
【００８３】
検印生成部１０２は、検印の処理の前に、検印処理部１００を使用するユーザに対して、ＣＡＰＴＣＨＡなどの画像による認証を要求する。
画像による認証に成功した場合に、実施の形態１に従った検印処理を行う。
本実施の形態に係る端末装置１の構成は、図１、図１２又は図１４に示す構成と同じである。
【００８４】
本実施の形態に係る検印生成部１０２の処理を、図１６を用いて説明する。
【００８５】
検印生成部１０２は、「歪んだ文字列の画像と、その画像で表示された実際の文字列の対」を検印処理部１００の起動前に予め、複数対、保存する。
そして、検印処理部１００の起動タイミングで、前記複数対のうちの一対をランダムに選択する。
そして、検印生成部１０２は、画像による認証データとして選択した「歪んだ文字列の画像」をＧＵＩでユーザに表示する（図１６のＳ１０２＿ａｇ１）。
ここで、歪んだ文字列の画像の表示は、ユーザに対する認証データの要求である。
また、このＧＵＩは、歪んだ文字列の画像の表示の他に、文字列を入力するインタフェースも備えている。
【００８６】
次に、ユーザは、歪んだ画像の文字列を、何の文字列か目視で判断して、ＧＵＩに文字列を入力する。
入力した文字列は、図１４に示す、ユーザからの認証データ１２０３に該当する（図１６のＳ１０２＿ａｇ２）。
【００８７】
検印生成部１０２は、入力された認証データと、ＧＵＩで表示した歪んだ文字列の画像と対になる文字列（内部に保存している）の一致を比較し（図１６のＳ１０２＿ａｇ３）、一致している場合（Ｙｅｓ）、図２のＳ１０２＿１，Ｓ１０２＿２，Ｓ１０２＿３を処理する（図１６のＳ１０２＿１２３）。
一致していない場合（Ｎｏ）、検印生成部１０２は、エラー通知１２０８を検印処理部１００の外へ出力する（図１６のＳ１０２＿ａｇ４）。
【００８８】
マルウエアがＧＵＩからの入力文字列を監視して悪用する可能性があるため、検印生成部１０２は歪んだ画像のパターン、及び、対となる文字列の組を、検印生成部１０２自身で生成し、あらかじめ大量に保持し、検印処理部１００を起動するたびにランダムに表示してもよい。
【００８９】
或いは、例えば図１７において、システムの管理者が、画像系認証データ配信サーバ装置４を運用し、画像による認証データ（例：歪んだ画像のパターン）と対になる文字列について、複数の対を、画像系認証データ１０２４として生成し、ネットワークを通じて、検印処理部１００に配信する。
検印処理部１００の検印生成部１０２（図１７では、それ以外の要素の記載は省いている）における通信部１０２２は、画像系認証データ１０２４を受信し、画像系認証データ更新部１０２１に入力する。
画像系認証データ更新部１０２１は、画像系認証データ保存部１０２３に、画像系認証データ１０２４を更新保存する。
そして、検印処理部１００が起動されるたびに、検印生成部１０２は、画像系認証データ保存部１０２３から、ランダムに、或いは、決まった順番で、画像による認証データと対になる文字列を選択し、画像による認証データを、図１４の認証データ要求１２０２としてＧＵＩで表示してもよい。
或いは、この例における、画像系認証データ１０２４をネットワーク経由で、検印処理部１００に取り込むのではなく、ファイルなどで、画像系認証データ更新部１０２１に入力してもよい。
【００９０】
また、画像を用いた認証の方法は、ＣＡＰＴＣＨＡでなくてもよく、複数の異なる動物の画像を表示して、ライオンは何番の画像か答えよ、という認証方法でもよい。
この場合は、認証データ要求１２０２は、複数の異なる動物の画像であり、認証データ１２０３は、“３番目の画像”である。
この認証データ１２０３が、答えとして適切かを、検印生成部１０２が確認する。
【００９１】
本実施の形態では、検印処理に画像認証を必須とするため、画像認証をパスできないマルウエアは、ファイルに検印を付与できないので、インターネット上のＷｅｂサーバ装置にＨＴＴＰ  ＰＯＳＴしても、検査サーバ装置における検印の検査でエラーとなり、ファイルを漏洩できない効果がある。
このため、高度化されたマルウエアが、当方式を悪用しファイルを漏洩しようとしても、外部機器が必要となり、悪用できない効果がある。
【００９２】
実施の形態５．
本実施の形態では、ＰＣ内部でマルウエアが検印付きファイルを横取りして、Ｃ＆ＣサーバにＨＴＴＰ  ＰＯＳＴする場合への対策を示す。
以下では、検印時の処理について実施の形態１との差異のみ説明する。
【００９３】
検印生成部１０２は、検印の処理の前に、検印処理部１００を使用するユーザに対して、送信先のＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）を入力させる。
送信先ＵＲＬは、検証対象データの宛先アドレスの例に相当する。
検印処理部１００のＧＵＩの表示画面例を図１８に示す。
図１８において、ユーザは、検印処理用画面１３０１を用いて、送信対象ファイル１３０２と検印付きファイルの出力パス１３０３を入力し、さらに、送信先ＵＲＬ１３０４を入力する。
この時、認証画面１３０６を表示して、ユーザにパスワードを入力させてもよい。
この結果、検印付きファイル（図１の検印付きデータ１２０４）が出力される。
【００９４】
本実施の形態に係る端末装置１は、例えば、図２０に示す構成となる。
検印生成部１０２は、検印データ１１０５に送信先ＵＲＬを含めて検印付きファイルを生成する。
検印生成部１０２は、送信先ＵＲＬ１２０８と被検印データ１１０１を入力し、送信先ＵＲＬ１２０８と被検印データ１１０１を結合し、ＵＲＬ付きの被検印データとし、ＵＲＬ付きの被検印データを、検印対象のデータとして扱う。
つまり、図２のＳ１０２＿２において処理した被検印データ１１０１を、「送信先ＵＲＬ１２０８と被検印データ１１０１を結合したＵＲＬ付きの被検印データ」に置き換えて処理する。
検印生成部１０２は、ＵＲＬ付きの被検印データに対して実施の形態１と同様の手順で検印データ１１０５を生成し、生成した検印データ１１０５と、送信先ＵＲＬ１２０８（不図示）を検印追加部１０５に出力する。
検印追加部１０５は、検印データ１１０５と、送信先ＵＲＬ１２０８（不図示）と、被検印データ１１０１と、ユーザ識別子１２０７を結合して、検印付きデータ１１０６とする。
【００９５】
図１９は、検印生成部１０２及び検印追加部１０５による処理の例を示す。
検印生成部１０２は、送信対象である、ファイル１４０１（被検印データ１１０１に該当）に対して、送信先ＵＲＬ１４０４を結合し、ＵＲＬ付き被検印データ１４０５とする。
ＵＲＬ付き被検印データ１４０５に対して検印を生成した結果が、検印データ１４０２である。
検印追加部１０５は、ＵＲＬ付き被検印データ１４０５（ファイル１４０１と送信先ＵＲＬ１４０４）にユーザ識別子１４０３と検印データ１４０２を結合して、検印付きデータ１４０６とする。
なお、ここでは、ＵＲＬ付き被検印データ１４０５（ファイル１４０１と送信先ＵＲＬ１４０４）に対して検印データ１４０２を生成することとしているが、実施の形態１と同様に、ファイル１４０１に対して検印データ１４０２を生成するようにしてもよい。
【００９６】
その後、図２０のパケット生成部１０７が、検印データ出力部１０６から検印付きデータ１４０６を入力し、検印付きデータ１４０６をＨＴＴＰボディとし、ＨＴＴＰボディにＨＴＴＰヘッダを付加してＨＴＴＰ  ＰＯＳＴデータを生成する。
また、パケット生成部１０７は、ＨＴＴＰのヘッダに、宛先ホスト名を含ませる（通常はブラウザが含める処理を行う）。
このＨＴＴＰ  ＰＯＳＴデータが通信データの例に相当する。
更に、パケット生成部１０７は、ＨＴＴＰ  ＰＯＳＴデータにＩＰヘッダ、ＴＣＰヘッダ等を追加して、パケットを生成する。
そして、パケット送信部１０８が、パケット生成部１０７が生成したパケットを送信する。
【００９７】
なお、本実施の形態では、検印生成部１０２が検証情報生成部及び宛先アドレス入力部の例に相当し、検印追加部１０５がデータ結合部の例に相当し、パケット生成部１０７が通信データ生成部の例に相当し、パケット送信部１０８が通信データ送信部の例に相当する。
【００９８】
次に、図５の検査サーバ装置３の検査対象データ分解部３０３は、被検印データ３１０５を得るが、その内容は、図１９における、ＵＲＬ付き被検印データ１４０５である。
つまり、以下である。
ｈｔｔｐ：／／○○○．ｓａｍｐｌｅ．△△△／ｃｇｉ−ｂｉｎ／ｓｕｂｍｉｔ．ｘｘｘ
０１２３４５６７８９ａｂｃｄｅｆｇｈｉｊ
【００９９】
次に、図５の検印検証部３０４では、実施の形態１と同じ処理を行う。
【０１００】
本実施の形態では、検査対象データ分解部３０３は、被検印データ３１０５（図１９のＵＲＬ付き被検印データ１４０５）を検印検証部３０４だけでなく、送信データ生成部３０６にも出力する。
送信データ生成部３０６は、入力した被検印データ３１０５から、その最初に示されるＵＲＬ（図１９の送信先ＵＲＬ１４０４）を取り出す。
つまり、以下を取り出す。
ｈｔｔｐ：／／○○○．ｓａｍｐｌｅ．△△△／ｃｇｉ−ｂｉｎ／ｓｕｂｍｉｔ．ｘｘｘ
【０１０１】
次に、送信データ生成部３０６は、非検査対象データ３１０３を入力するが、この中に含まれるＨＴＴＰヘッダから、宛先ホスト名を得る。
そして、送信データ生成部３０６は、このホスト名が、前記ＵＲＬのホスト名部分と一致するかを検査する。
以下に、ＨＴＴＰ  ＰＯＳＴデータのフォーマット例を示す（実際にはｘｘｘに適切な値が設定される）。
【０１０２】
・リクエストライン
ＰＯＳＴ／ｃｇｉ−ｂｉｎ／ｓｕｂｍｉｔ．ｘｘｘ  ＨＴＴＰ／１．１
・リクエスト・ヘッダフィールド
Ａｃｃｅｐｔ：ｘｘｘ
Ａｃｃｅｐｔ−Ｌａｎｇｕａｇｅ：ｊａ
Ａｃｃｅｐｔ−Ｅｎｃｏｄｉｎｇ：ｘｘｘ
Ｒｅｆｅｒｅｒ：ｈｔｔｐ：／／○○○．ｓａｍｐｌｅ．△△△／ｓｈｉｎｓｅｉ．ｈｔｍｌ
Ｕｓｅｒ−Ａｇｅｎｔ：ｘｘｘ
Ｈｏｓｔ：○○○．ｓａｍｐｌｅ．△△△  ←  宛先ホスト名
・一般ヘッダフィールド
Ｐｒａｇｍａ：ｘｘｘ
Ｃｏｏｋｉｅ：ｘｘｘ
・エンティティヘッダフィールド
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｘｘｘ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：ｘｘ
・空行（ＣＲ（０ｘ０ｄ）＋ＬＦ（０ｘ０ａ）のみの行）
・メッセージ・ボディ（ＰＯＳＴするファイルのデータが入る）
ｘｘｘ
【０１０３】
ここで、送信データ生成部３０６は、「Ｈｏｓｔ：」に指定されるホスト名を取得し、ホスト名が、「○○○．ｓａｍｐｌｅ．△△△」であれば、被検印データ３１０５（図１９のＵＲＬ付き被検印データ１４０５）から取り出したＵＲＬである「ｈｔｔｐ：／／○○○．ｓａｍｐｌｅ．△△△／ｃｇｉ−ｂｉｎ／ｓｕｂｍｉｔ．ｘｘｘ」のホスト部分と一致する。
これらが一致しなかった場合は、検印検証部３０４は、エラー通知３２０３を出力する。
なお、本実施の形態では、検印検証部３０４とともに送信データ生成部３０６もデータ検証部の例に相当する。
【０１０４】
次に、送信データ生成部３０６は、被検印データ３１０５から当ＵＲＬを除去したデータを得る。
つまり、図１９における、ＵＲＬ付き被検印データ１４０５から、当ＵＲＬを削除することになるので、以下の様になる。
・ＵＲＬ削除前
ｈｔｔｐ：／／○○○．ｓａｍｐｌｅ．△△△／ｃｇｉ−ｂｉｎ／ｓｕｂｍｉｔ．ｘｘｘ
０１２３４５６７８９ａｂｃｄｅｆｇｈｉｊ
・ＵＲＬ削除後
０１２３４５６７８９ａｂｃｄｅｆｇｈｉｊ
【０１０５】
次に、送信データ生成部３０６は、非検査対象データ３１０３と上記のＵＲＬを除去したデータから、修正送信データ３１０８を生成する。
つまり、上記のＵＲＬを除去したデータが、ＨＴＴＰリクエストのボディに入る。
これは、元々送信しようとしていた図９のファイル５００１の内容がＨＴＴＰリクエストのボディに入ることになる。
前記ＨＴＴＰ  ＰＯＳＴデータのフォーマット例を使用すると、以下の様になる。
・リクエストライン
ＰＯＳＴ／ｃｇｉ−ｂｉｎ／ｓｕｂｍｉｔ．ｘｘｘ  ＨＴＴＰ／１．１
・リクエスト・ヘッダフィールド
Ａｃｃｅｐｔ：ｘｘｘ
Ａｃｃｅｐｔ−Ｌａｎｇｕａｇｅ：ｊａ
Ａｃｃｅｐｔ−Ｅｎｃｏｄｉｎｇ：ｘｘｘ
Ｒｅｆｅｒｅｒ：ｈｔｔｐ：／／○○○．ｓａｍｐｌｅ．△△△／ｓｈｉｎｓｅｉ．ｈｔｍｌ
Ｕｓｅｒ−Ａｇｅｎｔ：ｘｘｘ
Ｈｏｓｔ：○○○．ｓａｍｐｌｅ．△△△
・一般ヘッダフィールド
Ｐｒａｇｍａ：ｘｘｘ
Ｃｏｏｋｉｅ：ｘｘｘ
・エンティティヘッダフィールド
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｘｘｘ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：ｘｘ
・空行（ＣＲ（０ｘ０ｄ）＋ＬＦ（０ｘ０ａ）のみの行）
・メッセージ・ボディ（ＰＯＳＴするファイルのデータが入る）
０１２３４５６７８９ａｂｃｄｅｆｇｈｉｊ
【０１０６】
この様に、ユーザが送信したいＷｅｂサーバ装置のＵＲＬを検印に含めることで、もしマルウエアが検印付きファイルを横取りして、Ｃ＆ＣサーバにＨＴＴＰ  ＰＯＳＴしようとしても、検査サーバ装置が、ＨＴＴＰヘッダのホスト名と、検印に含まれたＵＲＬのホスト名部分の一致を検査するため、マルウエアはＣ＆ＣサーバへファイルをＨＴＴＰ  ＰＯＳＴできない効果がある。
【０１０７】
実施の形態６．
本実施の形態では、検印付きファイルを暗号化し、検査サーバ装置で復号することで、マルウエアの盗聴から保護する方式を示す。
ネットワークの盗聴への対策として、プロキシサーバ装置への接続をＳｅｃｕｒｅ  Ｓｏｃｋｅｔｓ  Ｌａｙｅｒなどのプロトコルで暗号化する方法があるが、本実施の形態では、端末装置に存在する、検印付きのファイルを、端末装置上でマルウエアが横取りした場合を考える。
マルウエアは、横取りした検印付きファイルをプロキシサーバ装置経由でＣ＆Ｃサーバへ送信すると、検査サーバ装置が検印付きファイルを正しいものとして確認する。
その結果として、検印付きファイルはＣ＆Ｃサーバへ送信されてしまう。
そこで、端末装置上でマルウエアが検印付きファイルを横取りしても、端末装置上では何が記載されたファイルか分からないようにする方式を示す。
以下では、検印時の処理について実施の形態１との差異のみ説明する。
【０１０８】
図１の検印処理部１００の検印追加部１０５の処理において、検印データ１１０５と被検印データ１１０１とユーザ識別子１２０７から検印付きデータ１１０６を生成するが、この検印付きデータ１１０６を検査サーバ装置３の公開鍵暗号のｐｕｂｌｉｃ  ｋｅｙで暗号化したものを、検印追加部１１０６が、検印データ出力部１０６に、検印付きデータ１１０６の代わりに出力する。
図２１を用いて説明すると、検印追加部１０５の連結部１０５１は、検印データ１１０５と被検印データ１１０１とユーザ識別子１２０７を連結し、検印付きデータ１０５３を出力する。
次に、公開鍵暗号部１０５２は、検印付きデータ１０５３を入力し、検査サーバ装置３の公開鍵１０５４を用いて、検印付きデータ１０５３を暗号化し、検印付きデータ１１０６’（暗号化された、検印付きデータ）として出力する。
これは、検印付きデータ１１０６として検印データ出力部１０６（図１）に入力される。
【０１０９】
図５の検査サーバ装置３においては、検査対象データ分解部３０３において、検査対象データ３１０２（検査サーバ装置の公開鍵で暗号化されている）を検査サーバ装置３の公開鍵暗号のｐｒｉｖａｔｅ  ｋｅｙで復号したうえで、検印データ３１０４と被検印データ３１０５とユーザ識別子３１０９に分解し出力する。
図２２を用いて説明すると、検査対象データ分解部３０３における公開鍵復号部３０３１は、検査対象データ３１０２（暗号化された、検印付きデータ）を検査サーバ装置のｐｒｉｖａｔｅ  ｋｅｙ  ３０３３で復号し、検印付きデータ３０３４を出力する。
分解部３０３２は、検印付きデータ３０３４を検印データ３１０４と被検印データ３１０５とユーザ識別子３１０９に分解し出力する。
【０１１０】
上記例では、公開鍵暗号による暗号化の例を示したが、検印処理部１００と検査サーバ装置３で共通鍵暗号の鍵を予め共有してそれらの鍵で暗号化／復号してもよい。
その場合、検印処理部１００の動作を、図２３を用いて説明すると、検印追加部１０５の連結部１０５１は、検印データ１１０５と被検印データ１１０１とユーザ識別子１２０７を連結し、検印付きデータ１０５３を出力する。
次に、共通鍵暗号部１０５５は、検印付きデータ１０５３を入力し、検査サーバ装置３と共有している共通鍵１０５６を用いて、検印付きデータ１０５３を暗号化し、検印付きデータ１１０６’（暗号化された、検印付きデータ）として出力する。
これは、検印付きデータ１１０６として検印データ出力部１０６（図１）に入力される。
【０１１１】
検査サーバ装置３の動作を図２４を用いて説明すると、検査対象データ分解部３０３における共通鍵復号部３０３５は、検査対象データ３１０２（暗号化された、検印付きデータ）を検印処理部１００と共有している共通鍵３０３６（共通鍵１０５６と同じ）で復号し、検印付きデータ３０３４を出力する。
分解部３０３２は、検印付きデータ３０３４を検印データ３１０４と被検印データ３１０５に分解し出力する。
【０１１２】
また、検印処理部１００の検印追加部１０５で、テンポラリの共通鍵暗号の鍵を生成し、テンポラリの共通鍵暗号の鍵で、検印付きデータ１１０６を暗号化し、テンポラリの共通鍵暗号の鍵を検査サーバ装置３の公開鍵で暗号化し、検印付きデータ１１０６と連結して検印データ出力部１０６に出力する。
検印データ出力部１０６は、この暗号化鍵が連結された検印付きデータを、検印付きデータ１２０４として検印処理部１００の外に出力する。
【０１１３】
検印処理部１００の検印追加部１０５の動作を図２５で説明すると、検印追加部１０５のテンポラリ共通鍵生成部１０５４は、テンポラリの共通鍵１０５６を生成し、公開鍵暗号部１０５２へ出力する。
公開鍵暗号部１０５２は、テンポラリの共通鍵１０５６を検査サーバ装置３のｐｕｂｌｉｃ  ｋｅｙ１０５３で暗号化し、暗号化された共通鍵１０５７を出力する。
また、第１の連結部１０５１は、検印データ１１０５と被検印データ１１０１とユーザ識別子１２０７を連結し、検印付きデータ１０５８として共通鍵暗号部１０５５に出力する。
共通鍵暗号部１０５５は、テンポラリの共通鍵１０５６を用い、検印付きデータ１０５８を共通鍵暗号で暗号化し、暗号化検印付きデータ１０５９を第２の連結部１０５１０へ出力する。
第２の連結部１０５１０は、暗号化された共通鍵１０５７と暗号化検印付きデータ１０５９を連結し、検印付きデータ（暗号化された、検印付きデータ）と暗号化された共通鍵１１０６’を、出力する。
これは、検印付きデータ１１０６として検印データ出力部１０６（図１）に入力される。
【０１１４】
図５の検査サーバ装置３においては、検査対象データ分解部３０３において、検査対象データ３１０２’（テンポラリの共通鍵暗号の鍵で暗号化された検印付きデータに、検査サーバ装置３のｐｕｂｌｉｃ  ｋｅｙで暗号化されたテンポラリの鍵が連結されたもの）について、まず、検査サーバ装置３のｐｕｂｌｉｃ  ｋｅｙで暗号化されたテンポラリの共通鍵を、検査サーバ装置３のｐｒｉｖａｔｅ  ｋｅｙで復号し、テンポラリの共通鍵を得る。
次に、このテンポラリの共通鍵で、暗号化された検印付きデータを復号する。
そして、検印データ３１０４と被検印データ３１０５とユーザ識別子３１０９に分解し出力する。
検査サーバ装置３の検査対象データ分解部３０３の動作を図２６で説明すると、検査対象データ分解部３０３の第１の分解部３０３７は、「検査対象データ（暗号化された、検印付きデータ）と暗号化された共通鍵３１０２’」を、暗号化された検印付きデータ３０３９と、暗号化された共通鍵３０３８に分解する。
そして、公開鍵復号部３０３１は、暗号化された共通鍵３０３８を入力し、検査サーバ装置３のｐｒｉｖａｔｅ  ｋｅｙ３０３３を用いて、暗号化された共通鍵３０３８を公開鍵暗号で復号し、復号した結果であるテンポラリの共通鍵３０３１０を共通鍵復号部３０３５に出力する。
共通鍵復号部３０３５は、暗号化された検印付きデータ３０３９を入力し、テンポラリの共通鍵３０３１０を用いて、共通鍵暗号で復号し、復号した結果である検印付きデータ３０３４を第２の分解部３０３２に出力する。
第２の分解部３０３２は、検印付きデータ３０３４を、検印データ３１０４と被検印データ３１０５とユーザ識別子３１０９に分解し、出力する。
【０１１５】
また、実施の形態１では、図１０の検印処理用画面６００１において、検印付きファイルの出力パス６００３を指定させたが、出力パスにおいて、フォルダパスのみ指定させ、ファイル名は、検印処理用画面６００１がランダム、或いは検印を付与したタイムスタンプなど、自動的に付与してもよい。
ユーザに検印付きファイルの出力パス６００３を、ファイル名まで含めて指定させると、元の拡張子や、元のファイル名を含めてしまいがちで、この結果、マルウエアがファイルの内容を推測できることがある。
例えば、「極秘＿顧客リスト２０１２．ｚｚｚ」（ｚｚｚは拡張子、以下同様）というファイル名の場合、顧客の個人情報が入っているファイルと推測できる（マルウエアは、極秘、顧客、などのキーワードをファイル名に含んだファイルを探す場合が考えられる）。
もしマルウエアが、ディレクトリに置かれているファイル名をリストアップした場合、この様な名前が付与されたファイルを入手するかもしれない。
そこで、検印処理用画面６００１は、検印付きファイル５００３（図９）の名前を、例えば、「Ｐ９＄ｕｑ７１ｈｒ．ｚｚｚ．ｓｉｇ」や、「２０１２０８０１１０３６．ｚｚｚ．ｓｉｇ」などの様にファイル名から内容を推測できないファイルに変換してもよい。
また、「Ｐ９＄ｕｑ７１ｈｒ．ｓｉｇ、２０１２０８０１１０３６．ｓｉｇ」のように元の拡張子を除去してもよい。
更に、「Ｐ９＄ｕｑ７１ｈｒ」や「２０１２０８０１１０３６」の様に拡張子を完全に除去し、そもそも何のファイルなのか分からなくしてもよい。
【０１１６】
図９のＷｅｂサーバ装置５０１２は、「Ｐ９＄ｕｑ７１ｈｒ．ｚｚｚ．ｓｉｇ」のようなファイル名で受け取ると、何のファイルなのかファイルを開いてみないと分からないことがある。
また、「Ｐ９＄ｕｑ７１ｈｒ．ｓｉｇ」や「Ｐ９＄ｕｑ７１ｈｒ」のような場合は何のアプリケーションで開いてよいか分からない。
予め、Ｗｅｂサーバ装置５０１２と開くアプリケーションを取り決めておけば解決できるかもしれないが、元もとのファイル名を知りたい場合の処理について説明する。
図１の検印処理部１００において、公開鍵暗号で検印付きデータを暗号化する場合で説明する。
図２１において、検印追加部１０５の連結部１０５１は、検印データ１１０５と、被検印データ１１０１と、ユーザ識別子１２０７に加えて、検印処理部１００（図１）に入力された、検印付きファイルの出力パス１２０６（フルパスか、パスを含まないファイル名のみの何れか、例えば、「極秘＿顧客リスト２０１２．ｚｚｚ」）（図１）を、入力し、検印付きデータ１０５３と検印付きファイルの出力パス１２０６を連結して、公開鍵暗号部１０５２に出力する。
この結果、検印付きデータ１１０６’（暗号化された、検印付きデータ）には、元のファイル名（「極秘＿顧客リスト２０１２．ｚｚｚ」）が含まれる。
また、検印処理部１００が出力する検印付きファイルの名前は元のファイル名を推測できないランダムなものとし、例えば、「Ｐ９＄ｕｑ７１ｈｒ」である。
【０１１７】
図９のブラウザ５００４で検印付きファイル５００３である「Ｐ９＄ｕｑ７１ｈｒ」をＰＯＳＴすると、ＨＴＴＰのヘッダ（例えばＣｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎ）にファイル名として、「Ｐ９＄ｕｑ７１ｈｒ」が設定される。
【０１１８】
そして、検査サーバ装置３における、図２２の検査対象データ分解部３０３の分解部３３０２は、検印データ３１０４、被検印データ３１０５、ユーザ識別子３１０９に加えて、検印付きファイルの出力パス１２０６を出力する。
検査サーバ装置３の送信データ生成部３０６（図１）では、ＨＴＴＰデータのヘッダ（例えばＣｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎ）において、検印付きファイルの出力パス１２０６を設定する。
この結果、修正送信データ３１０８に含まれるファイル名の情報は、元のファイル名「極秘＿顧客リスト２０１２．ｚｚｚ」となり、図９のＷｅｂサーバ装置５０１２は、ファイル名「極秘＿顧客リスト２０１２．ｚｚｚ」として受け取ることができる。
【０１１９】
この様に、検印処理部が出力する、検印付きデータ１２０４を暗号化することで、マルウエアが、検印付きデータ１２０４を横取りしても、何のファイルなのか識別させないため、必要なファイルを漏洩することを防止する効果がある。
【０１２０】
実施の形態７．
本実施の形態では、マルウエアがファイルを添付メール（電子メールの添付ファイル）で組織外へ漏洩することを防止する実施の形態を示す。
以下では、実施の形態１との差異を示す。
【０１２１】
図２７は、本実施の形態における構成図である。
図９との差異を示す。
ユーザ５００５はメーラ５００４’を使用し（（２））、添付メールで検印付きファイル５００３を送信することで、検印付きファイル５００３が添付されたメール５００６’がＬＡＮ５０１３に送られ（（３））、スイッチ５００７を経由しメールサーバ装置５００８’において受信される。
メールサーバ装置５００８’は、検査サーバ装置５００９に検印付きファイル５００３が添付されたメール５００６’を転送する。
検査サーバ装置５００９は、検印付きファイル５００３が添付されたメール５００６’において、検印を検査し、成功した場合に、検印付きファイル５３００から検印を除去し（（５））、ファイルが添付されたメール５０１０’としてメールサーバ装置５００８’に転送する（（６））。
メールサーバ装置５００８’はインターネット５０１１にファイルが添付されたメール５０１０’を送信し（（７））、メール送信先５０１２’で受信する。
【０１２２】
検印処理部１００の動作は、実施の形態１に同じである。
図５の検査サーバ装置３の動作は、送信対象データ分解部３０２は、検査対象データ３１０２として、検印付き添付ファイルを出力する。
また、メールの本文やヘッダ部分を非検査対象データ３１０３として出力する。
また、送信データ生成部３０６において、被検印データ３１０５と非検査対象データ３１０３を連結することで、検印データが付与されていないファイルを添付ファイルとしたメールが、修正送信データ３１０８として出力される。
【０１２３】
また、マルウエアによる検印付きファイルの横取りへの対策として、実施の形態５の方式を応用できるが、その場合は、送信先ＵＲＬの代わりに、送信先のメールアドレスを指定すればよい。
【０１２４】
本実施の形態では、Ｗｅｂサーバ装置に送信するファイルへの検印処理部１００による検印の付与と、検査サーバ装置３における検印の検証と除去の方式を、添付つき電子メールにも適用したので、マルウエアがファイルを添付メールで組織外へ漏洩することを防止する効果がある。
【０１２５】
実施の形態８．
本実施の形態では、マルウエアがブログサイトの掲示板へデータ漏洩することを防止する実施の形態を示す。
以下では、実施の形態１との差異を示す。
【０１２６】
図２８を用いて実施の形態１との差異を説明する。
ユーザ５００５は、ブログサイトへ投稿したい文書（投稿データ５０１５）を、テキストエディタ５０１３で記述し、ファイル５００１に保存する。
さらに検印処理部５００２を使用して、検印付きファイル５００３を生成する（（１））。
さらにユーザ５００５は、検印付きファイル５００３をテキストエディタ５０１３で開き、検印付きファイルの内容（検印付き投稿データ５０１４）をコピーし、ブラウザ５００４を用いて、掲示板のＷｅｂサーバ装置の投稿欄にペーストして投稿する（（２））。
この結果、検印付き投稿データを含んだＨＴＴＰ  ＰＯＳＴデータ５００６’’（（３））が、プロキシサーバ装置５００８へ送信される。
この時、ＨＴＴＰボディに含まれるのは、検印付き投稿データ５０１４である。
プロキシサーバ装置５００８は、検印付き投稿データを含んだＨＴＴＰ  ＰＯＳＴデータ５００６’’を検査サーバ装置５００９に転送すると（（４））、検査サーバ装置５００９は、検印付き投稿データを含んだＨＴＴＰ  ＰＯＳＴデータ５００６’’において、検印付き投稿データの検印を検証する。
検証に成功すれば、検印付き投稿データ５０１４から検印を除去し、投稿データ５０１５を含んだＨＴＴＰ  ＰＯＳＴデータ５０１０’’をプロキシサーバ装置５００８へ転送する。
プロキシサーバ装置５００８は、投稿データを含んだＨＴＴＰ  ＰＯＳＴデータ５０１０’’をインターネット５０１１を経由して、Ｗｅｂサーバ装置５０１２へ送信する。
【０１２７】
本実施の形態では、実施の形態１をブログサイトへの投稿データにも応用したので、マルウエアによるブログサイトへのデータ漏洩も防止する効果がある。
【０１２８】
以上の実施の形態１〜８では、以下の処理が行われる情報漏洩防止システムを説明した。
端末装置は、ＷｅｂサイトへＰＯＳＴしたいファイルを、検印処理部を用いて検印し、プロキシサーバ装置へ送信する（ＨＴＴＰデータ）。
プロキシサーバ装置は、受信したＨＴＴＰデータを検査サーバ装置へフォワードし、検査サーバ装置は、検印があり、検印の検証に成功することをもって、検印部分を削除したＨＴＴＰデータを生成しなおし、プロキシサーバ装置へフォワードする。
プロキシは、検印部分を削除したＨＴＴＰデータをＷｅｂサイトへＰＯＳＴする。
検印が無い場合、及び、検証に失敗した場合は、検査サーバ装置は、エラーをプロキシに通知する。
【０１２９】
また、実施の形態１〜８では、情報漏洩防止システムは、検印の手段として以下を適用することを説明した。
固定の文字列
公開鍵暗号と一方向性ハッシュ関数を用いた電子署名
共通鍵暗号と一方向性ハッシュ関数を用いた電子署名
【０１３０】
また、実施の形態１〜８では、
以下の、マルウエアによる本方式の悪用対策を含む情報漏洩防止システムを説明した。
検印データに、送信先ＵＲＬを含み、検査サーバ装置において、ＨＴＴＰヘッダ情報に示されるホスト名がＵＲＬに含まれることで、正当なＷｅｂサイトへ送信を行うことを確認する。
検印付きファイルを、検査サーバ装置のみが復号できるように暗号化する。
検印処理部が、外部機器の認証を必要とする。
検印処理部が、外部機器の暗号処理を必要とする。
検印処理部が、画像認証を必要とする。
【０１３１】
また、実施の形態１〜８では、
マルウエアによる、ＷｅｂサイトへのファイルのＨＴＴＰ  ＰＯＳＴだけでなく、ブログサイトへのデータ送信、添付メールによるファイル送信による情報漏洩を防止する情報漏洩防止システムを説明した。
【０１３２】
以上、本発明の実施の形態について説明したが、これらの実施の形態のうち、２つ以上を組み合わせて実施しても構わない。
あるいは、これらの実施の形態のうち、１つを部分的に実施しても構わない。
あるいは、これらの実施の形態のうち、２つ以上を部分的に組み合わせて実施しても構わない。
なお、本発明は、これらの実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。
【０１３３】
また、上記の実施の形態では、端末装置をユーザが操作し、送信したいファイルに検印を付与し、Ｗｅｂサイトへ送信したり電子メールに添付して送信したが、当端末装置をサーバ化（検印サーバ）し、ユーザが、検印サーバへ、送付したいファイルと送信先を転送すると、検印が付与され、プロキシサーバ（Ｗｅｂサイトへ送信する場合）やメールサーバ（電子メールとして送信する場合）へ検印付きのファイルが転送されるように構成してもよい。
また、検印鍵保存部１０３に保存するｐｒｉｖａｔｅ  ｋｅｙや共通鍵はユーザ固有として記述したが、複数のユーザで共通のｐｒｉｖａｔｅ  ｋｅｙや共通鍵を保持して運用してもよい。
また、以上の実施の形態では、マルウエアが不正にデータを操作する例を用いて説明を行ったが、検印を付与できない不正な内部ユーザがデータを不正に操作する場合も、上記の実施の形態で説明した仕組みを適用できる。
つまり、検査サーバ装置は、検印を付与できない不正な内部ユーザにより不正に操作されたデータを検出することができる。
【０１３４】
図２９において、端末装置１及び検査サーバ装置３は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。
ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウエアデバイスを制御する。
更に、ＣＰＵ９１１は、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ  Ｄｉｓｋ  Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７と接続していてもよい。また、磁気ディスク装置９２０の代わりに、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）、光ディスク装置、メモリカード（登録商標）読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。
実施の形態１〜８で説明した「検印鍵保存部１０３」及び「検証鍵保存部３０５」は、ＲＡＭ９１４、磁気ディスク装置９２０等により実現される。
通信ボード９１５、キーボード９０２、マウス９０３、スキャナ装置９０７などは、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力装置の一例である。
【０１３５】
通信ボード９１５は、図９等に示すように、ネットワークに接続されている。
【０１３６】
磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。
プログラム群９２３のプログラムは、ＣＰＵ９１１がオペレーティングシステム９２１、ウィンドウシステム９２２を利用しながら実行する。
【０１３７】
また、ＲＡＭ９１４には、ＣＰＵ９１１に実行させるオペレーティングシステム９２１のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。
また、ＲＡＭ９１４には、ＣＰＵ９１１による処理に必要な各種データが格納される。
【０１３８】
また、ＲＯＭ９１３には、ＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ  Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）プログラムが格納され、磁気ディスク装置９２０にはブートプログラムが格納されている。
端末装置１及び検査サーバ装置３の起動時には、ＲＯＭ９１３のＢＩＯＳプログラム及び磁気ディスク装置９２０のブートプログラムが実行され、ＢＩＯＳプログラム及びブートプログラムによりオペレーティングシステム９２１が起動される。
【０１３９】
上記プログラム群９２３には、実施の形態１〜８の説明において「〜部」（「検印鍵保存部１０３」及び「検証鍵保存部３０５」以外、以下同様）として説明している機能を実行するプログラムが記憶されている。
プログラムは、ＣＰＵ９１１により読み出され実行される。
【０１４０】
ファイル群９２４には、実施の形態１〜８の説明において、「〜の判断」、「〜の判定」、「〜の計算」、「〜の演算」、「〜の比較」、「〜の検証」、「〜の生成」、「〜の評価」、「〜の更新」、「〜の設定」、「〜の登録」、「〜の選択」、「〜の連結」、「〜の暗号化」、「〜の復号」、「〜の入力」、「〜の出力」等として説明している処理の結果を示す情報やデータや信号値や変数値が、ディスクやメモリなどの記憶媒体にファイルとして記憶されている。
また、暗号鍵・復号鍵や乱数値やパラメータが、ディスクやメモリなどの記憶媒体にファイルとして記憶されてもよい。
「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記憶媒体に記憶される。
ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出される。
そして、読み出された情報やデータや信号値や変数値やパラメータは、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。
抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、実施の形態１〜８で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示す。
データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ブルーレイ（登録商標）ディスク、ＤＶＤ等の記憶媒体に記録される。
また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
【０１４１】
また、実施の形態１〜８の説明において「〜部」として説明しているものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。
また、端末装置１及び検査サーバ装置３の処理をデータ処理方法として捉えることができる。
また、「〜部」として説明しているものは、ＲＯＭ９１３に記憶されたファームウエアで実現されていても構わない。
或いは、ソフトウエアのみ、或いは、素子・デバイス・基板・配線などのハードウエアのみ、或いは、ソフトウエアとハードウエアとの組み合わせ、さらには、ファームウエアとの組み合わせで実施されても構わない。
ファームウエアとソフトウエアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ブルーレイ（登録商標）ディスク、ＤＶＤ等の記憶媒体に記憶される。
プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。
すなわち、プログラムは、実施の形態１〜８の「〜部」としてコンピュータを機能させるものである。あるいは、実施の形態１〜８の「〜部」の手順や方法をコンピュータに実行させるものである。
【０１４２】
このように、実施の形態１〜８に示す端末装置１及び検査サーバ装置３は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータである。
そして、上記したように「〜部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。
【符号の説明】
【０１４３】
１  端末装置、２  外部機器、３  検査サーバ装置、４  画像系認証データ配信サーバ装置、１００  検印処理部、１０１  データ入力部、１０２  検印生成部、１０３  検印鍵保存部、１０４  外部機器連携部、１０５  検印追加部、１０６  検印データ出力部、１０７  パケット生成部、１０８  パケット送信部、３０１  データ入力部、３０２  送信対象データ分解部、３０３  検査対象データ分解部、３０４  検印検証部、３０５  検証鍵保存部、３０６  送信データ生成部、３０７  データ出力部。
【図１】
0005518158.tif 000002
【図２】
0005518158.tif 000003
【図３】
0005518158.tif 000004
【図４】
0005518158.tif 000005
【図５】
0005518158.tif 000006
【図６】
0005518158.tif 000007
【図７】
0005518158.tif 000008
【図８】
0005518158.tif 000009
【図９】
0005518158.tif 000010
【図１０】
0005518158.tif 000011
【図１１】
0005518158.tif 000012
【図１２】
0005518158.tif 000013
【図１３】
0005518158.tif 000014
【図１４】
0005518158.tif 000015
【図１５】
0005518158.tif 000016
【図１６】
0005518158.tif 000017
【図１７】
0005518158.tif 000018
【図１８】
0005518158.tif 000019
【図１９】
0005518158.tif 000020
【図２０】
0005518158.tif 000021
【図２１】
0005518158.tif 000022
【図２２】
0005518158.tif 000023
【図２３】
0005518158.tif 000024
【図２４】
0005518158.tif 000025
【図２５】
0005518158.tif 000026
【図２６】
0005518158.tif 000027
【図２７】
0005518158.tif 000028
【図２８】
0005518158.tif 000029
【図２９】
0005518158.tif 000030