JP2002007288A - 否認防止情報管理方法、その装置及びプログラム記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 送信情報又は受信情報について、後で否認で
きないように安全な状態でそのログを蓄積する。 【解決手段】 ブラウザ１２からＧＥＴ Ｒｅｑｕｅｓ
ｔ１６を送出すると、それがセキュア状態での取得をし
たい場合は、管理装置１９でこのことをセキュアＵＲＬ
リスト１７で検出し、そこにあるクライアントの鍵情報
をＲｅｑｕｅｓｔ１６に追加してサーバ１２へ送る、サ
ーバ１２はＲｅｑｕｅｓｔに応じたコンテンツを取出
し、管理装置２１でこれに対し、署名を付け、前記鍵情
報にもとづくクライアントの公開鍵で暗号化し、この暗
号化コンテンツをログ２４に蓄積すると共にクライアン
トＭＯＳＳフォーマットでそのヘッダに暗号化データで
あることを示して送信する。管理装置１５ではその暗号
化コンテンツをログ１９に蓄積した後、復号する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明はクライアント端末
におけるＷＷＷブラウザとＷＷＷサーバとの通信や電子
メールなどにおいて、通信内容を、後で否認するおそれ
がある情報を、否認できないように管理する方法、その
装置及びプログラム記録媒体に関する。

【０００２】

【従来の技術】例えば図１３に示すようにインターネッ
トを介して、クライアント端末上のＷＷＷブラウザによ
りＨＴＭＬで記述されたテキストを解釈して表示し、希
望するファイルやサービスなどをＵＲＬ（資源指定する
手法）により指定して、ＨＴＴＰプロトコルによりＷＷ
Ｗサーバと通信して、ＷＷＷサーバより所望の例えばコ
ンテンツを取得することが行われている。この場合、誰
が何を注文したかのプライバシイの保護や送信中のコン
テンツが盗まれてもそのコンテンツを利用できないよう
にする点などから、ＳＳＬ（Ｓｅｃｕｒｅｄ Ｓｏｋｅ
ｔｓ Ｌａｙｅｒ）と云われる暗号ソフトウエアで暗号
化して通信することが行われている。

【０００３】

【発明が解決しようとする課題】例えばクライアントが
注文したコンテンツと異なるコンテンツが送られて来た
とサーバに不平を云うようなことがある。この場合、ク
ライアント端末側で注文に関するデータやサーバ側で送
信コンテンツに関するデータをログとして記録保存して
おいても、これらは容易に改ざんすることができるため
相手を納得させることができない。つまり、そのような
データを見せても、そのデータは否認されても仕方ない
ものである。

【０００４】ＳＳＬによる暗号化は、通信路上でのみ暗
号化するものであり、送信先が決れば、送信情報を順次
暗号化して、送信し受信側でも、受信信号を直ちに復号
して始めてアプリケーションプログラムで解釈すること
ができるものである。従って、従来のＳＳＬにより暗号
化された通信路上のデータをログとして保存しておいて
も、どのクライアント端末又はどのサーバよりのどの通
信データであるかを区別することができない。従って、
この通信路上の暗号化通信データを単にログとして保存
しておいても、否認防止情報として管理することができ
ず、つまり否認防止情報として用いることはできない。

【０００５】

【課題を解決するための手段】この発明によれば、アプ
リケーションデータ、つまりアプリケーションプログラ
ムが認識できる一塊りのデータごとに署名を付け、必要
に応じ暗号化して送信すると共にその署名付アプリケー
ションデータをログ蓄積部に蓄積しておく。また受信の
際に署名付アプリケーションデータをまずログ蓄積部に
蓄積し、その後、暗号化アプリケーションデータの場合
は復号した後署名検証する。つまりログ蓄積部には一塊
りのアプリケーションデータごとに署名が付けられてお
り、アプリケーションプログラムで発信者（端末又はサ
ーバ）、受信者（端末又はサーバ）の区別ができ、必要
に応じて日時を付けておけば、後に問題になった時に、
対応するアプリケーションデータを取出して署名を検証
することにより、そのデータについて否認できないよう
にすることができる。

【０００６】

【発明の実施の形態】この発明をクライアント端末上の
ＷＷＷブラウザとＷＷＷサーバとの間における通信に適
用した実施例を先ず説明する。図１はクライアント端末
１１がそのＷＷＷブラウザ１２により、ＷＷＷサーバ１
３からインターネットなどの通信網１４を介してコンテ
ンツを取得する場合である。ブラウザ１２と通信網１４
の通信路との間にこの発明による否認防止情報管理装置
１５が設けられる。

【０００７】利用者はブラウザ上の画面を見て希望する
コンテンツのＵＲＬをキーボードにより入力し、又は画
面上でマーカを指示させてクリックすると、ブラウザ１
２からアプリケーションデータとしてリクエスト（Ｒｅ
ｑｕｅｓｔ）データ１６が否認防止情報管理装置１５に
入力される。このリクエストデータ１６は例えば図２Ａ
に示すように、コンテンツ取得を示すＧＥＴ、通信プロ
トコルｈｔｔｐ、着信アドレス、プログラムのファイル
名そのプログラムに対する命令、この例ではファイル名
ｍｏｓｓ．ｃｇｉ中のコンテンツｈｔｍを安全な状態で
取得することを示しており、更に通信プロトコルとその
バージョン番号、プロキシイ（代理サーバ）の使用可
能、サーバのソフト名などが記述されている。

【０００８】否認防止情報管理装置１５では図３に示す
ように、ブラウザ１２よりのリクエストデータ１６は安
全化判定部３１に入力されて、コンテンツを安全に、つ
まり改ざんされたり、盗まれたりしない状態で取得する
ことを要求するか否かの判断が行われる。この例ではセ
キュア状態で取得する安全化ＵＲＬリスト１７を設け、
リクエストデータ１６中の取得ファイル名がそのリスト
１７中にあれば、セキュア用リクエストとする。

【０００９】安全化ＵＲＬリスト１７は例えば図２Ｂに
示すように、安全化されるべき各ＵＲＬが、ＵＲＬとク
ライアント名とＣＡ名と鍵番号とを順次「，」で区切ら
れて１行としてそれぞれ記憶されている。ＣＡ名はその
クライアント名のクライアントがそのコンテンツ取得の
ために用いる秘密鍵に対する公開鍵を登録している認証
局名であり、鍵番号（Ｋｅｙｓｅｌ）はその複数の登録
公開鍵の１つを特定するための番号である。図２Ｂ中の
ＵＲＬの２行目において「＊」印はその前の情報はどの
ようなものでもよいことを示す。

【００１０】図２Ａに示した例のリクエストデータ１６
中のファイル名は「ｍｏｓｓ．ｃｇｉ」であり、安全化
ＵＲＬリスト１７中の２番目に該当する。よって安全化
判定部３１は安全化要求をすると判定し、更に取得か否
か判断部３２ではリクエストデータ１６が「ＧＥＴ」で
あり取得と判断し、鍵情報付加部３３でリクエストデー
タ１６に、安全化ＵＲＬリスト１７の該当するＵＲＬの
格納部から得た鍵情報を付加して図２Ｃに示すようなセ
キュア用リクエストデータ１８とする。図２Ｃ中の破線
より下の部分が付加された鍵情報１８ａであり、一行目
が認証局ＣＡに登録されているクライアントのＥメール
アドレスであり、２行目が認証局ＣＡの識別情報であ
り、３番目が使用する鍵番号である。このセキュア用リ
クエストデータ１８が通信路へ送信部３４を通じて送信
される。この通信プロトコルはこの例ではＨＴＴＰであ
る。

【００１１】サーバ１３はＨＴＴＰで受信する受信部５
１（図４）で受信され、否認防止情報管理装置２１へ供
給され、その受信電文がセキュア用か否かの判定が判定
部５２で行われる。この判定はその電文のヘッダに付け
られている後のデータの種類を表わすＭＩＭＥ Ｃｏｎ
ｔｅｎｔ Ｔｙｐｅから行う。セキュア用電文であれ
ば、安全化情報分離部５３において、ＧＥＴであれば、
前記例ではセキュア用リクエストデータ１８はＧＥＴで
あるからその鍵情報１８ａが保存部５４に保存され、残
りのデータはアプリケーション手段５５に供給される。

【００１２】アプリケーション手段５５は、サーバ１３
のＷＷＷブラウザに対する主要なアプリケーションプロ
グラムを機能させるものである。つまりこの例では、受
信したリクエストデータ１８中の「ｍｏｓｓ．ｃｇｉ？
ｕｒｌ＝／ｓｅｃｕｒｅ．ｈｔｍ」にもとづきコンテン
ツデータベース２２からｈｔｍのコンテンツを取出し、
アプリケーションデータとされたコンテンツが否認防止
情報管理装置２１に供給される。

【００１３】否認防止情報管理装置２１では図４に示す
ように、そのアプリケーションデータとされたコンテン
ツは安定化されるべきであるかの判定が判定化部５６で
行われる。この例ではセキュア用リクエストデータ１８
中の「ｓｅｃｕｒｅ．ｈｔｍ」の「ｍｏｓｓ．ｃｇｉ」
により安全化することが要求されている。従ってコンテ
ンツは署名部５７で鍵記憶部５８中のサーバ署名用鍵に
より電子署名が付けられ、この署名付コンテンツは暗号
部５９で保存部５４に保存された鍵情報にもとづき暗号
化される。つまり鍵取得部６１が鍵管理アプリケーショ
ンプログラム２３を、保存部５４の鍵情報１８ａについ
て実行して、そのＣＡＩＤ情報の認証局装置２４をアク
セスして、鍵情報１８ａ中のクライアントＥメールアド
レスと鍵番号を送り、認証局装置７１からそのクライア
ントのその鍵番号の公開鍵証明書を取得する。

【００１４】その取得した公開鍵証明書中の公開鍵によ
り暗号部５９で署名付コンテンツを暗号化する。この暗
号化コンテンツ（暗号化アプリケーションデータ）をロ
グ蓄積部２４に必要に応じてその日時と共に蓄積すると
共にその暗号化コンテンツは送信部６２よりＨＴＴＰプ
ロトコルにより通信路へ送信される。このセキュア化コ
ンテンツ２５は例えば暗号化データの国際規格フォーマ
ットであるＭＯＳＳにフォーマット化されてあり、その
ヘッダに、後のデータの種類を表わすＭＩＭＥＣｏｎｔ
ｅｎｔ Ｔｙｐｅに暗号化されている記述をする。なお
クライアント端末１１で署名の検証ができるように、署
名部５７の署名に用いた署名鍵と対応する検証用公開鍵
を登録してある認証局識別情報ＣＡＩＤと、その認証局
に登録してあるサーバ１３のアドレスと、署名に用いた
鍵の番号（Ｋｅｙｓｅｌ）とよりなる鍵情報も、セキュ
ア化コンテンツ２６にそのＭＯＳＳフォーマットに従っ
た箇所に記述しておく。

【００１５】クライアント端末１１ではサーバ１３から
送信されたセキュア化コンテンツ２６は否認防止情報管
理装置１５の受信部３５（図３）で受信され、安全化情
報分離部３６でそのヘッダのＭＩＭＥ Ｃｏｎｔｅｎｔ
Ｔｙｐｅから暗号化データであると判定して受信セキ
ュア化コンテンツ２６をログ蓄積部１９に必要に応じて
日時と共に蓄積すると共に復号部３７で、先にセキュア
用リクエストデータ１８で送った鍵情報１８ａと対応す
る秘密鍵を鍵記憶部３８から取出して復号する。その復
号されたコンテンツを検証部３９で署名の検証を行う。
この検証用鍵は、受信したセキュア化コンテンツ２６中
の鍵情報を用いて、鍵取得部４１が鍵管理アプリケーシ
ョンプログラムを実行して登録認証局から登録サーバア
ドレスの鍵番号の公開鍵証明書を取得して得る。

【００１６】その検証に合格すると復号されたコンテン
ツはＨＴＭＬ記述状態でブラウザ１２へ供給され、例え
ば画面表示される。次にブラウザ１２からのリクエスト
がＰＯＳＴの場合でセキュア化リクエストデータとして
サーバ１３へ送信する例を図５を参照して説明する。こ
の場合ブラウザ１２には図６Ａに示すフォームデータ７
２がサーバ１３から与えられており、そのうちのデータ
７２ａはサーバ１３の認証局ＣＡに登録したアドレス、
登録した認証局の識別情報ＣＡＩＤ、使用する鍵番号
（Ｋｅｙｓｅｌ）よりなる鍵情報であり、これは画面に
表示されない。データ７２ｂは入力された名前を表示す
る箇所、実行ボタン、リセットボタンが画面に表示され
ている。名前、図示例では「ｈｏｇｅｈｏｇｅｌ」を入
力して実行ボタンを操作すると、例えば図６Ｂに示すリ
クエストデータ７３がブラウザ１２から否認防止情報管
理装置１５へ供給される。リクエストデータ７３は図２
Ａに示したリクエストデータ１６に対し、ＧＥＴがＰＯ
ＳＴに変更され、フォームデータとして付加され、つま
り図６Ａ中のサーバの鍵情報と、入力された名前などが
加わった点以外はほぼ同様である。

【００１７】このＰＯＳＴリクエストデータ７３も図３
の否認防止情報管理装置１５内の安全化判定部３１で安
全化条件部１７の安全化ＵＲＬリスト内のＵＲＬと一致
するか否かにより安全化処理を行うかの判定がなされ、
この例では「ｍｏｓｓ．ｃｇｉ」により安全化処理が行
われる。ＰＯＳＴリクエストデータ７３は署名部４２に
おいて、鍵記憶部３８内のクライアントの署名鍵により
電子署名が付けられ、その署名付ＰＯＳＴリクエストデ
ータは暗号部４３で、そのデータ７３内のサーバ１３の
鍵情報にもとづき暗号化される。詳しくは先に述べた場
合と同様にその鍵情報に基づき、鍵取得部４１によりサ
ーバ１３の公開鍵証明書を認証局７１から取得してその
公開鍵により暗号化する。このようにして得られた暗号
部４３よりのセキュア化リクエストデータ７４は送信部
３４により通信路へ送信される。このデータ７４の内容
は例えば図６Ｃに示すようなものである。

【００１８】このセキュア化リクエストデータ７４はサ
ーバ１３の否認防止情報管理装置２１内のＨＴＴＰ受信
プログラム処理部、つまり図４の受信部５１に受信さ
れ、そのセキュア用電文判定部５２でセキュア用電文と
判定され、更に安全化情報分離部５３で暗号化されたＰ
ＯＳＴリクエストデータと判断されて、ログ蓄積部２４
に日時データと共に蓄積される。またこのセキュア化リ
クエストデータ７４は復号部６３で鍵記憶部５８内のブ
ラウザ１２へ送ったサーバ鍵情報と対応する秘密鍵で復
号し、その復号されたＰＯＳＴリクエストデータの署名
の検証を検証部６４で行う。なおこの検証が可能なよう
に、セキュア化リクエストデータ７４内のＭＯＳＳ化フ
ォームデータ内に、クライアント端末１１内の署名部４
２の署名に用いた鍵と対応する公開鍵を得るための鍵情
報が記述されてあり、この鍵情報を用いて、認証局から
対応する公開鍵証明書を取得し、その公開鍵を用いて検
証を行う。

【００１９】この検証に合格すると、その復号されたＰ
ＯＳＴリクエストデータをアプリケーション手段５５、
つまりＷＷＷサーバのプログラムの対応する処理部分に
より処理させる。このリクエストデータが例えば単なる
名前の登録の場合は、その登録を行うと共にその受信し
たことを示すメッセージを、暗号化することなく送信部
６２を通じてクライアント端末１１へ送信する。あるい
は見積書にＰＯＳＴリクエストデータ中の名前を記入し
て、クライアント端末１１に返送する。この際に、この
内容の見積書を送ったことをクライアント端末１１のク
ライアントが否認できないようにするには、先のコンテ
ンツのクライアント端末１１への送信と同様に電子署名
を付け、更に暗号化し、その暗号化した回答書をログ蓄
積部２４に蓄積すると共にクライアント端末１１へ送信
する。

【００２０】上述において、コンテンツデータベース２
２に格納されているコンテンツに対し、署名部５７によ
りサーバ１３の電子署名を付けておき、その署名付コン
テンツをデータベース２２に格納しておいてもよい。こ
の場合は、コンテンツをクライアント端末１１へ送信す
る。更に署名部５７による署名処理が省略でき、それだ
け全体としての処理を高速化することができる。クライ
アント端末１１、サーバ１３の何れにおいても送信電文
を蓄積するログ蓄積部と、受信電文を蓄積するログ蓄積
部とを分離して設けてもよい。

【００２１】以上述べたように、コンテンツなどの一塊
りのアプリケーションデータごとに署名を付けて、暗号
化してログ蓄積部に蓄積することができる。よって、必
要に応じて所望のアプリケーションデータをログ蓄積部
から取出して署名検証により、その情報を署名者が否認
することを不可能にすることができる。またこの実施例
のように暗号化する場合は、その鍵情報からどこへ送信
したかの否認も不可能とすることができる。なお例えば
利用者からのログ蓄積部に蓄積したログを確認したい要
求があれば、そのログをＭＩＭＥ Ｃｏｎｔｅｎｔ Ｔ
ｙｐｅの次のアドレスと、ログ蓄積を行った日付から、
ログ蓄積部を検索して、そのログを表示画面に表示す
る。これによりそのアドレスと日付から、そのログ（ア
プリケーションデータ）をその利用者がそのアドレスに
送ったか否か、又はその利用者が受け取ったか否かを確
認し、更に必要に応じてそのログ（アプリケーションデ
ータ）を復号部に復号させ、その復号結果に対する署名
を検証部に行わせ、その検証結果の表示を見て、例えば
不合格ならそのログは誤りがあるものとして削除した
り、合格を確認して利用者が満足すれば、そのログの確
認処理を終了する。更に必要に応じてそのログのアプリ
ケーションデータの内容も確認したい要求があれば、先
に復号したログを呼び出して表示画面に表示する。なお
管理者は古くなり不要となったログの削除なども行う。

【００２２】クライアント端末１１は例えばパーソナル
コンピュータにより構成され、その場合、例えば図７に
示すように、安全化ＵＲＬリストメモリ１７、ログ蓄積
部１９、鍵記憶部３３、送信部３４、受信部３５、ブラ
ウザプログラムが記憶されたメモリ８１、否認防止情報
管理プログラムが記憶されたメモリ８２、鍵管理プログ
ラムが記憶されたメモリ８３、コンピュータの基本動作
を行う基本プログラムが記憶されたメモリ８４、ＣＰＵ
８５がバス８６に接続されて、全体としての機能が行わ
れる。なおメモリ８１，８２，８３に対しては対応する
プログラムが、外部から予めインストールされるが、対
応したプログラムが格納されたものを直接接続してもよ
い。更に否認防止情報管理プログラムの実行において、
署名処理、暗号化処理、復号化処理、検証処理などソフ
トウエアで行うことなく、モジュール化された復号部３
７、検証部３９、署名部４２、暗号部４３を利用するよ
うにしてもよい。これらモジュール化したものの利用は
その全てに限らず、そのうちのいくつかを行ってもよ
い。図に示さないがサーバ１３も同様にコンピュータを
用いた構成とすることができる。

【００２３】クライアント端末１１側の否認防止情報管
理装置１５の動作処理の手順は図８に示すようになる。
ブラウザ１２からリクエストを受信すると（Ｓ１）、そ
のリクエストが安全化（セキュア）条件に該当するかを
調べ（Ｓ２）、該当しない場合はそのままサーバ１３へ
送信し（Ｓ３）、該当する場合はそのリクエストがＰＯ
ＳＴかＧＥＴかの判定を行い（Ｓ４）、ＧＥＴの場合
は、そのリクエストのＨＴＴＰ通信プロトコルのヘッダ
にクライアントの鍵情報を追加し（Ｓ５）、サーバへ送
信する（Ｓ６）。

【００２４】リクエストがＰＯＳＴの場合は、ブラウザ
から受信した電文にクライアントの電子署名を付け（Ｓ
７）、サーバより得たフォームデータ内のサーバ鍵情報
を参照し（Ｓ８）、その鍵情報をもとに認証局からサー
バ公開鍵証明書を取得し（Ｓ９）、その公開鍵を用いて
前記署名付電文を暗号化し（Ｓ１０）、その暗号電文を
ログ蓄積部に保存し（Ｓ１１）、その後その暗号電文を
サーバへ送信する（Ｓ１２）。

【００２５】サーバ１３側の否認防止情報管理装置２１
の動作処理手順は図９に示すようになる。まず受信電文
がセキュリティ用か否かを調べ（Ｓ１）、セキュリティ
用であればその電文、つまりブラウザからのリクエスト
がＰＯＳＴかＧＥＴの何れであるかを調べ（Ｓ２）、Ｇ
ＥＴであれば、その電文のＨＴＴＰヘッダからクライア
ント鍵情報を取得保存し（Ｓ３）、その電文に対応した
コンテンツ又は署名付コンテンツをデータベースから取
得し（Ｓ４）、その取得したコンテンツが署名付でなけ
れば（Ｓ５）、そのコンテンツに電子署名を付ける（Ｓ
６）。また前記保存したクライアント鍵情報にもとづき
クライアントの公開鍵証明書を認証局から取得し（Ｓ
７）、その公開鍵を用いて署名付コンテンツを暗号化し
（Ｓ８）、その暗号化コンテンツをログ蓄積部に蓄積し
（Ｓ９）、その後、その暗号化コンテンツをクライアン
ト端末へ送信する（Ｓ１０）。

【００２６】受信電文がＰＯＳＴであれば、その電文を
ログ蓄積部に蓄積し（Ｓ１１）、その受信電文を復号化
し（Ｓ１２）、また電文中のクライアント鍵情報に基づ
き認証局からクライアント公開鍵証明書を取得し（Ｓ１
３）、その公開鍵を用いて復号された電文の署名を検証
し（Ｓ１４）、その電文がコンテンツの取得要求であれ
ばコンテンツデータベースをアクセスし（Ｓ１５）、ス
テップＳ４へ移る。次にこの発明を電子メールに適用し
た例を図１０を参照して説明する。メール端末９１とそ
のメール端末９１が所属するメールサーバ９２との間に
否認防止情報管理装置９３が介在され、またメール端末
９４とその端末９４が所属するメールサーバ９５との間
に否認防止情報管理装置９６が介在される。メール端末
９１と否認防止情報管理装置９３間、またメール端末９
４と否認防止情報管理装置９５間はそれぞれメール送信
プロトコルＳＭＴＰと受信プロトコルＰＯＰで通信が行
われ、またメールサーバ９２と否認防止情報管理装置９
３間、またメールサーバ９５と否認防止情報管理装置９
６間もそれぞれ送信プロトコルＳＭＴＰと受信プロトコ
ルＰＯＰで通信が行われる。メールサーバ９２と９５の
間も通信が行われる。

【００２７】例えばメール端末９１から電子メールをメ
ール端末９４へ送信する場合に、メール端末９１よりの
メールは否認防止情報管理装置９３に入力される。否認
防止情報管理装置９３は図３に示した構成とほぼ同様な
構成を備え、安全化判定部３１で安全化条件に該当する
かを調べる。例えば通常のアドレスが図１１Ａに示す場
合にそのアドレス中の「＠」を図１１Ｂに示すように
「％」に変更し、かつ最後にキーワード「＠ｓｅｃｕｒ
ｉｔｙ」を追加する。この変更はアプリケーションプロ
グラム上で行ってもよいし、メール端末９１内のアドレ
ス帳中の、安全にしたいと思われる相手のアドレスをそ
のように記述しておく。この場合は、安全化判定部３１
で着信アドレス中にキーワード「＠ｓｅｃｕｒｉｔｙ」
があれば安全化、なければ通常の通信と判定する。安全
化の場合は図３中に破線で示す指示により署名部４２で
電子署名を付け、その鍵情報（受信側で検証に必要とす
る公開鍵を得るための情報、つまりＣＡＩＤ、登録アド
レス、鍵番号など）を付加し、また受信者の公開鍵証明
書を鍵管理アプリケーションプログラムにより認証局装
置７１から取得し、その公開鍵により暗号部４３で暗号
化してＭＯＳＳのフォーマットでメールサーバ９２へ送
る。この際受信アドレスは図１１Ａに示すような通常の
アドレスに戻しておく。またメールサーバ９２へ送信す
ると共にその暗号化メールをログ蓄積部９７に蓄積す
る。

【００２８】メールサーバ９２はその暗号化メールをメ
ールサーバ９５へ送り、メールサーバ９５はその暗号化
メールを否認防止情報管理装置９６へ供給する。否認防
止情報管理装置９６も図３に示したものとほぼ同様な構
成であり、安全化情報分離部３６でそのＭＯＳＳフォー
マットのヘッダのＭＩＭＥ Ｃｏｎｔｅｎｔ Ｔｙｐｅ
から安全化されたものと判断されるとログ蓄積部９８
（図１０）に蓄積すると共に復号部３７で復号し、その
復号されたメールの署名を検証部３９で検証し、検証に
合格するとそのメールをメール端末９４へ送る。検証部
３９における送信者の検証用公開鍵の取得は先に述べた
と同様な手法による。安全化情報分離部３６で暗号化さ
れたものでないと判断されるとそのままメール端末７４
へ送信される。

【００２９】図１１Ｃに示すように、安全化アドレスの
キーワード「＠ｓｅｃｕｒｉｔｙ」の後に、楕円ＤＨ暗
号の相手が使用する秘密鍵番号に対する公開鍵番号と、
自分が使用する秘密鍵番号と、自分が署名に用いる鍵番
号とを記述しておいてもよい。この例ではこの相手の公
開鍵番号の鍵と、自分の秘密鍵とにより共通鍵を生成し
てアプリケーションデータを暗号化する例である。図１
２に示すように安全化して送信したい相手のアドレスと
その相手の秘密鍵と対応する公開鍵が登録されている認
証局アドレスと、その認証局に登録してある相手のアド
レスと、使用する暗号形式と、使用する鍵番号とを組と
するリストを作っておき、図３中の安全化条件部１７に
格納しておき、送信メール端末から受信したメールのア
ドレスが安全化条件部１７にあるか否かを安全化判定部
３１で判定し、あればその安全化条件部１７のリスト中
の該当するアドレスについて格納されている鍵情報を用
いて受信者の公開鍵を取得して、暗号部４３で暗号化す
るようにしてもよい。

【００３０】なお図１１に示した例でアドレス帳を用い
る場合は、同一受信者についても、通常アドレスと安全
化アドレスとの両者をアドレス帳に記入しておき、その
何れかを選択使用できるようにすることもできる。図１
０から容易に理解されるように１つのメールサーバ９２
に所属する複数のメール端末を１つの否認防止情報管理
装置９３により一元的に否認防止情報を管理することも
できる。また複数のプロトコルを利用する複数のアプリ
ケーションの一元的に否認防止情報を管理することがで
きる。要はこの発明によれば、後で否認されるおそれの
ある情報については、その一塊りのアプリケーションデ
ータを署名し、必要に応じて暗号化した状態で、送信情
報も、受信情報もログ蓄積部に蓄積しておけばよく、そ
のアプリケーションデータを作るアプリケーションプロ
グラムには任意のものでもよく、否認防止情報管理装置
で送信の際はそのアプリケーションデータが否認される
おそれがあるものであるか否かの判断ができるようにす
ると共に、受信の際はそれが安全化アプリケーションデ
ータとされたものであるか否かをＭＯＳＳのヘッダのＭ
ＩＭＥ Ｃｏｎｔｅｎｔ Ｔｙｐｅなどで区別できれば
よい。上述では暗号化を公開鍵暗号方式により行った
が、例えばコンテンツを共通鍵で暗号化し、その共通鍵
を公開鍵暗号方式により暗号化して同時に送り、受信側
で共通鍵を復号し、復号した共通鍵でコンテンツを復号
するようにしてもよい。

【００３１】暗号化する場合は、アプリケーションデー
タの全体を暗号化し、その暗号化データにヘッダとして
ＭＩＭＥ Ｃｏｎｔｅｎｔ Ｔｙｐｅと、相手先アドレ
スを更に付ける。上述の説明から明らかなように否認防
止のアプリケーションデータにて必ず署名を付けるが、
暗号化はしなくてもよい。

【００３２】

【発明の効果】以上述べたように、この発明によればア
プリケーションレベルで一塊りのアプリケーションデー
タに対し署名を付けてあり、これをこの単位で区別して
送信時にも、受信時にもログ蓄積部に蓄積でき、しかも
そのデータを思うように改ざんすることはできないた
め、後でそのようなデータを送ってないとか、受信して
いないとか、問題が生じた場合にそのログ蓄積部に蓄積
されている該当するものを署名検証することにより、当
初のデータの正当性を否認することができないことにな
る。また前記例のように暗号化する場合はその復号のた
めの鍵情報からどこへ送信したかも否認することができ
なくなる。

【図面の簡単な説明】

【図１】この発明をブラウザとサーバ間の通信に適用し
た実施例の機能構成を示す図。

【図２】図１で用いられるＧＥＴリクエストデータ１６
の例を示す図、Ｂは安全化ＵＲＬリストの例を示す図、
Ｃはセキュア用リクエストデータ１８の例を示す図であ
る。

【図３】図１中のこの発明による否認防止情報管理装置
１５の実施例の機能構成を示す図。

【図４】図１中のこの発明による否認防止情報管理装置
２１の実施例の機能構成を示す図。

【図５】この発明をブラウザとサーバ間の通信に適用し
た他の実施例の機能構成を示す図。

【図６】Ａはサーバより受信したフォームデータ７２の
例を示す図、Ｂはリクエストデータ７３の例を示す図、
Ｃはセキュア化リクエストデータの例を示す図である。

【図７】図１中のクライアント端末１１をコンピュータ
により機能させる場合の機能構成を示す図。

【図８】図３に示した否認防止情報管理装置１５の動作
手順の例の一部を示す流れ図。

【図９】図４に示した否認防止情報管理装置２１の動作
手順の例の一部を示す流れ図。

【図１０】この発明を電子メールに適用した実施例の機
能構成を示す図。

【図１１】Ａは通常アドレス、Ｂ及びＣは安全化アドレ
スの各例を示す図である。

【図１２】安全化アドレスリストの例を示す図。

【図１３】従来のクライアントとサーバ間の暗号化通信
を説明するための図。

フロントページの続き (72)発明者 渡辺 徹 東京都千代田区内幸町一丁目１番６号 エ ヌ・ティ・ティ・コミュニケーションズ株 式会社内 (72)発明者 荻原 利彦 東京都千代田区内幸町一丁目１番６号 エ ヌ・ティ・ティ・コミュニケーションズ株 式会社内 (72)発明者 田渕 博康 東京都千代田区内幸町一丁目１番６号 エ ヌ・ティ・ティ・コミュニケーションズ株 式会社内 Ｆターム(参考） 5B017 AA08 BA07 CA16 5B085 AC14 AE13 AE29 BG07 5J104 AA09 LA03 LA06 MA02 NA02 PA08 PA09

Claims (18)

【特許請求の範囲】
1. 【請求項１】 アプリケーションデータに対し、送信者
   の電子署名を行い、 その署名付アプリケーションデータをログ蓄積部に蓄積
   すると共に相手方へ送信することを特徴とする否認防止
   情報管理方法。
2. 【請求項２】 上記署名付アプリケーションデータをロ
   グ蓄積部に蓄積するに先立ち、暗号化して上記蓄積を行
   うと共に相手方へ送信することを特徴とする請求項１記
   載の否認防止情報管理方法。
3. 【請求項３】 受信した署名付アプリケーションデータ
   をログ蓄積部に蓄積し、 上記受信した署名付アプリケーションデータに対し、そ
   の署名の検証を行い、その検証に合格すると、上記署名
   付アプリケーションデータを真として処理することを特
   徴とする請求項１記載の否認防止情報管理方法。
4. 【請求項４】 上記受信した署名付アプリケーションデ
   ータは暗号化されたものであり、 その暗号化された署名付アプリケーションデータを上記
   ログ蓄積部に蓄積し、 上記暗号化された署名付アプリケーションデータを復号
   し、その復号した署名付アプリケーションデータに対し
   て上記署名検証を行うことを特徴とする請求項１又は２
   記載の否認防止情報管理方法。
5. 【請求項５】 上記送信アプリケーションデータはブラ
   ウザから出力されたものであり、 それがＧＥＴかＰＯＳＴか判定し、 ＰＯＳＴであれば上記暗号化の鍵を、サーバからブラウ
   ザに送られた鍵情報にもとづき取得し、 上記ブラウザからの出力がＧＥＴであれば、上記アプリ
   ケーションデータに対し署名、暗号化をすることなく、
   送信者の鍵情報を追加して送信することを特徴とする請
   求項１乃至４の何れかに記載の否認防止情報管理方法。
6. 【請求項６】 先ず安全化条件を満たすかを判断し、安
   全化条件を満すと、上記電子署名とそれ以後の処理を行
   い、安全化条件を満たさないと、上記アプリケーション
   データを上記ログ蓄積部に蓄積することなく、そのまま
   送信することを特徴とする請求項１乃至５の何れかに記
   載の否認防止情報管理方法。
7. 【請求項７】 クライアント端末からの鍵情報はアプリ
   ケーションデータを受信し、 その受信したアプリケーションデータに付加された鍵情
   報を一時保存し、 上記受信したアプリケーションに応じたコンテンツを含
   むアプリケーションに対し、電子署名を行い、 その署名付アプリケーションを上記保存した鍵情報にも
   とづき暗号化し、 その暗号化アプリケーションデータをログ蓄積部に蓄積
   すると共に上記クライアント端末へ送信することを特徴
   とする否認防止情報管理方法。
8. 【請求項８】 クライアント端末からの鍵情報付アプリ
   ケーションデータを受信し、 その受信したアプリケーションデータに付加された鍵情
   報を一時保存し、 上記受信したアプリケーションに応じた、署名付コンテ
   ンツを含むアプリケーションを上記保存した鍵情報にも
   とづき暗号化し、 その暗号化アプリケーションデータをログ蓄積部に蓄積
   すると共に上記クライアント端末へ送信することを特徴
   とする否認防止情報管理方法。
9. 【請求項９】 クライアント端末からの鍵情報付暗号化
   されたアプリケーションデータを受信し、 その暗号化されたアプリケーションデータをログ蓄積部
   に蓄積し、 かつ上記アプリケーションデータに付加された鍵情報を
   一時保存し、 上記暗号化されたアプリケーションデータを復号し、 その復号されたアプリケーションデータの署名を検証
   し、 その検証に合格すると、上記アプリケーションデータに
   もとづき、上記クライアント端末へ送信するアプリケー
   ションデータが安全化の条件を満すか否かを判断し、 その条件を満たさなければ、そのままそのアプリケーシ
   ョンデータを送信し、条件を満せば、そのアプリケーシ
   ョンデータに対し電子署名を行い、その署名付アプリケ
   ーションデータを上記一時保存した鍵情報にもとづき暗
   号化し、その暗号化されたアプリケーションデータをロ
   グ蓄積部に蓄積すると共に送信することを特徴とする否
   認防止情報管理方法。
10. 【請求項１０】 受信した署名付アプリケーションデー
    タをログ蓄積部に蓄積し、 上記署名付アプリケーションデータに対し、その署名の
    検証を行い、 その検証に合格すると、上記署名付アプリケーションデ
    ータを真として処理することを特徴とする否認防止情報
    管理方法。
11. 【請求項１１】 上記受信した署名付アプリケーション
    データは暗号化された署名付アプリケーションデータで
    あり、 上記ログ蓄積部への蓄積は上記暗号化された署名付アプ
    リケーションデータに対し行い、 上記暗号化された署名付アプリケーションデータに対し
    復号を行い、その復号された署名付アプリケーションデ
    ータに対し、上記署名の検証を行うことを特徴とする請
    求項１０記載の否認防止情報管理方法。
12. 【請求項１２】 請求項１乃至１１の何れかの方法をコ
    ンピュータに実行させるプログラムを記録した記録媒
    体。
13. 【請求項１３】 アプリケーションプログラムにより動
    作するアプリケーション手段と、通信路との間に設けら
    れる否認防止情報管理装置であって、 通信路より受信した暗号化アプリケーションデータが蓄
    積されるログ蓄積部と、 上記暗号化アプリケーションデータを復号する復号部
    と、 上記復号されたアプリケーションデータの署名を検証す
    る検証部と、 上記検証部の検証に合格したアプリケーションデータを
    上記アプリケーション手段へ送る手段と、 を具備する否認防止情報管理装置。
14. 【請求項１４】 アプリケーション手段から受け取った
    アプリケーションデータに対し電子署名を行う署名部
    と、 上記署名付アプリケーションデータを送信先の鍵情報に
    もとづき暗号化する暗号部と、 上記暗号化されたアプリケーションデータが蓄積される
    ログ蓄積部と、 上記蓄積された暗号化されたアプリケーションデータを
    通信路へ送信する手段と を備えることを特徴とする請求項１３記載の否認防止情
    報管理装置。
15. 【請求項１５】 アプリケーションプログラムにより動
    作するアプリケーション手段と通信路との間に設けられ
    る否認防止情報管理装置であって、 上記アプリケーション手段から受け取ったアプリケーシ
    ョンデータに対し電子署名を行う署名部と、 上記署名付アプリケーションデータを送信先の鍵情報に
    もとづき暗号化する暗号部と、 上記暗号化されたアプリケーションデータが蓄積される
    ログ蓄積部と、 上記蓄積された暗号化されたアプリケーションデータを
    通信路へ送信する手段とを具備する否認防止情報管理装
    置。
16. 【請求項１６】 上記アプリケーション手段からのアプ
    リケーションデータが安全化条件を満すか否か判定する
    判定手段と、その判定手段が条件を満すと判定すると上
    記アプリケーションデータを上記署名部へ送り、条件を
    満たさないと判定すると上記アプリケーションデータを
    上記送信手段へ送る手段とを備えることを特徴とする請
    求項１４又は１５記載の否認防止情報管理装置。
17. 【請求項１７】 クライアント端末からの要求に応じて
    コンテンツをクライアント端末へ送信するサーバに設け
    られる否認防止情報管理装置において、 上記クライアント端末から受信したアプリケーションデ
    ータ中の鍵情報が一時保存される保存部と、 アプリケーションデータに対し電子署名を行う署名部
    と、 上記署名付アプリケーションデータを上記保存部の鍵情
    報にもとづき暗号化する暗号部と、 上記暗号化されたアプリケーションデータが蓄積される
    ログ蓄積部と、 上記ログ蓄積部に蓄積された暗号化されたアプリケーシ
    ョンデータを上記クライアント端末へ送信する手段とを
    具備する否認防止情報管理装置。
18. 【請求項１８】 上記クライアント端末から受信したア
    プリケーションデータは暗号化されたものであり、 その受信暗号化アプリケーションデータが蓄積されるロ
    グ蓄積部と、 上記受信暗号化アプリケーションデータを復号する復号
    部と、 上記復号されたアプリケーションデータの署名を検証す
    る検証部とを具備することを特徴とする請求項１４記載
    の否認防止情報管理装置。