JPH02170184A - 署名交換方式 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔産業上の利用分野〕 本発明は、コンピュータ・メツセージの通信により商取
引を行う装置に関する。

〔従来の技術〕

情報化の進展とともに、商業上の取引文書を情報ネット
ワークを通じてやりとりする電子取引の重要性が増大し
つつある。

電子取引において、公開鍵暗号を応用したディジタル署
名は、コンピュータ・メツセージの送受信において、メ
ツセージの発信元、承認者等の認証を与える技術として
有用視されている。

ところで、対等関係、あるいは、競争関係にある二者間
で、契約等のため双方のディジタル署名を交換する必要
がある場合、１者が通信ネットワークを介して遠く離れ
ているので、ディジタル署名の交換の途中、署名を一方
的に持ち逃げする等一 の不当行為を防ぐ必要があった。

このための署名交換の通信プロトコルとしては、例えば
、（１）　Ｌｕｃ　Ｌｏｎｇｐｒｅ、　Ｔｈｅ　ｕｓｅ
　ｏｆｐｕｂｌｉｃｋｅｙ　ｃｒｙｐｔｏｇｒａｐｈｙ
　ｆｏｒ　ｓｉｎｇｉｎｇｃｈｅｃｋｓ。

Ｐｒｏｃ、　Ｃｒｙｐｔｏ　８２．　Ａｕｇｕｓｔ　２
３−２５．　ＵＳＡ、　１９８２゜ｐｐ　１．９１−１
．９２と、（２）宝木他、ＩＣカード利用の電子取引認
証用方式、電気学会論文誌Ｃ，ｖｏｌ。

１０７−Ｃ，Ｎα１．１９８７年１月、ｐｐ４６−５３
において、詳細に述べられている。

先ず、Ｌｕｃ　Ｌｏｎｇｐｒｅの方法について説明する
。

いま、ＡとＢが契約Ｃに対し署名を行うとする。

このとき、次の手順がとられる。

ステップ１：Ｂは、契約Ｃに対し予備的な承諾（Ｐｒｅ
ｌｉｍｊ、ｎａｒｙ　ａｇｒｅｅｍｅｎｔ）を与えたこ
とを示すＢのディジタル署名ＥＰＫＡ　（Ｃ３ＫＡ　（
−−Ａｃｃｅｐｔ。

Ｃ−−））をＡに送る。

ステップ２：Ａは、契約Ｃに対し正式な承諾を与えたこ
とを示すＡのディジタル署名 ＥｐＫＢ（ＣｓＫ＾（−−８ｊ、ｇｎ＋Ｃ））をＢに送
る。

ステップ３：Ｂは、契約Ｃに対し正式な承諾を与えたこ
とを示すＢのディジタル署名 ＥＰＫＡ　（Ｃ８ＫＢ　（−−８ｊｇｎ＋　Ｃ））をＡ
に送る。

ここに、（−−Ａｃｃｅｐｔ、　Ｃ−）は契約Ｃを予備
的に承諾する（Ａｃｃｅｐｔ）旨を示すデータであり、
Ｄｓ（・）はデータ・を秘密鍵Ｓを用いて公開鍵暗号に
より暗号化変換して得られるデータを示しており、Ｅｐ
（・）はデータ・を公開＠ｐを用いて公開鍵名号により
復号化変換して得られるデータを示している。また、（
−−８ｊｇｎ、Ｃ−）は、契約Ｃを正式に承諾する（Ｓ
ｉｇｎ）旨を示すデータである。

上記Ｌｕｃ　Ｌｏｎｇｐｒｅの文献では、署名交換にお
いてトラブルが発生した場合、例えばステップ３で、Ｂ
がＢの正式な署名をＡに送らないとき、Ａは裁判所にお
いてＢの予備的な署名を示ｔ、Ｂに正式な署名を強要す
る旨、指唆している。

Ｌｕｃ　Ｌｏｎｇｐｒｅは、本方式の不十分な点として
、ステップ２で、ＡがＡの正式な署名をＢに送らないと
き、Ｂだけが予備的な署名をＡに送っているという不公
平な状態が生じ、それが問題であるとしている。

この問題は解決策として、Ｌｕｃ　Ｌｏｎｇｐｒｅは、
それ以降は予備的な署名が取り消されるような遅延時間
（ｄｅｌａｙ　ｔｉｍｅ）を設定することが考えられる
、としている。しかしながら、この公知例では１例えば
、ＡとＢの時計に誤差があるときの対処方法等、詳細な
検討がなされなかった。このため、Ｌｕｃ　Ｌｏｎｇｐ
ｒｅは、この署名交換方式はあまり良くない、と結論付
けた。

次に、定木の従来方法を説明する。

いま、ＡとＢが通信文ｍに対ｔ、署名を行うとする。こ
のとき、次の手順がとられる。

ステップ１：Ｂは通信文ｍに対ｔ、Ｂの予備的な署名（
公知例で電子割印と呼んでいる）ＷＢ’＝Ｅ（ｃユ、（
ｍ）、ＳＢ）を作成ｔ、Ｗ　Ｂ　’をＡに送る。

ここに、ｃ　１（ｍ　）は、ｍのハツシュトータルに時
刻、通し番号、名前等の取引状況を表すデータをつなげ
たものである。ただｔ、ｃｌ（ｍ）は取引が成立するた
めの正式な形式は満足しないものである。また、Ｅ（・
＋ｓ）はデータ・秘密鍵Ｓを用いて公開鍵暗号による暗
号化変換して得られるデータを示している。

ステップ２：Ａは通信文ｍに対ｔ、Ａの正式な署名（公
知例では電子捺印と呼んでいる）ＷＢ’・Ｅ（Ｃ２（ｍ
）、ＳＡ）をＢに送る。ここに、Ｃ２（ｍ）は、ｍのハ
ツシュトータルに時刻、通し番号、名前等の取引状況を
表すデータをつなげたものであり、かつ、取引が成立す
るための正式な形式を満足するものである。

ステップ３：Ｂは通信文ｍに対ｔ、Ｂの正式な署名Ｗ＝
Ｅ（ｃｚ（ｍ）＋　ＳＢ）をＡに送る。ここに、Ｃ２（
ｍ）は上記ステップ２におけるＣ２（ｍ）と同しである
。

上記署名交換におけるトラブル時の手順としては、次の
事項が開示されている。

（１）ステップ２において、ＡはＢの予備的な署名を受
けとった後、Ａの正式な署名を送らないか、誤った署名
を送る場合、Ｂの予備的な署名を無効化リストに記録す
ることにより無効化する。ただｔ、Ａ、Ｂいずれが不当
かの＝１１ ＝１２ 判定は行なわない。

（２）ステップ３において、ＢはＡの正式な署名を受け
とった後、Ｂの正式な署名を送らないか、誤った署名を
送る場合、Ａが提出するＢの予備的な署名が無効化リス
トにあるなら、Ａが不当であると判定ｔ、Ａが提出する
Ｂの予備的な署名が無効化リストにないなら、Ｂが不当
であると判定する。

ところで、定木の従来方式においては、ＡとＢの間のあ
る想定されたトラブルに対しては、調停機関による調停
例が示されていたが、いくつかのトラブルに対して、調
停の記述がなかった。例えば、 （ａ）ステップ１において、Ｂが事前の交渉無しにＢの
予備的な署名を勝手にＡに送り付け、かつ、Ａはその取
引については、拒否したい場合、 （ｂ）上記（２）のトラブル時において、ＡがＢの予備
的な署名を調停機関に提出しなかった場合、等において
、調停機関の動作がまったく記述されていなかった。

このように、Ｌｕｃ　Ｌｏｎｇｐｒｅおよび定木の方法
において、署名交換中のトラブルに対する調停の検討が
十分行なわれていなかった。

さらに、Ｌｕｃ　Ｌｏｎｇｐｒｅおよび定木の方法にお
いて、調停機関に対するプライバシー保護、すなわち、
調停機関に取引文書の内容を知られることなくトラブル
発生時の調停を調停機関に実施してもらえるようにする
こと、を実現する機能がなかった。例えば、 （ａ）　Ｌｕｃ　Ｌｏｎｇｐｒｅの方法において、調停
機関に提出されるディジタル署名Ｄ３ＫＡ　（Ａｃｃｅ
ｐＬ　Ｃ））等から調停機関は＝Ａ　ｃｃｅｐｔの中身
、つまり、取引文書ｍ（Ｃ）そのものを読み取ることが
できた。

（ｂ）定木の従来方法においては、調停機関は取引文書
ｍを入手しないで調停に必要な確認、すなわち、（ｉ）
電子割印Ｅ　（ｃｉｎ（ｍ）、　ｓ）と電子捺印Ｅ　（
ｃｚ（ｍ）、　ＳＡ）　、Ｅ　（Ｃ２（ｍ）、　Ｓ［Ｉ
）が対応じていること、（ｊｌ）それらのディジタル署
名がＡとＢの間の取引に関するディジタル署名であるこ
と、を確認する方法が提示されていなかった。取引文書
ｍが入手でき、かつ、ｍの文面にＩＤＡとＩＤＥの間の
取引である旨明記されているという条件では、調停機関
は上記の確認を簡単に行うことができる。

〔発明が解決しようとする問題点〕

本発明は上記従来の問題点を解決ｔ、 （１）署名交換におけるあらゆる場合を想定したうえで
、トラブルを調停できる署名交換方式を提供すること、 （２）シかも、上記の調停は、取引文書の内容そのもの
を調停機関に知られることなく実行される署名交換方式
を提供すること、 を目的とする。

〔問題点を解決するための手段〕

上記の問題点を解決するため、次の手段を用いる。

１、トラブル時の調停動作に必要な情報を含んだ予備的
な署名および正式な署名の作成とそれらの送受信を行う
。

（１）取引者Ａ、取引者Ｂおよび調停機関Ｃからなり、
取引文書Ｍに関するディジタル署名を送受信するシステ
ムを構成する。

（２）取引文書Ｍのハッシュトータルれ（Ｍ）と、Ａの
識別子ＩＤＡ、Ｂの識別子ＩＤＢ、および該ディジタル
署名はある属性に属することを示す記号ＴＥＭＰを含む
、かつ、取引文書Ｍを含まないデータＤＡＴＡ’ｌを作
成する。ＤＡＴＡｌを、Ａの秘密鍵を用いて公開鍵暗号
により暗号変換して得られるディジタル署名Ｔ　（Ａ）
　、または、Ｂの秘密鍵を用いて公開鍵暗号により暗号
変換して得られるディジタル署名Ｔ　（Ｂ）をＡとＢの
間で送受信し合う。

ここで、Ｔ　（Ａ）　、　Ｔ　（Ｂ）は、相手の正式な
署名を受は取ったら自分も正式な署名を相手に送る旨を
約束する予備的な署名、として使用される。

（３）その後、取引文書Ｍのハッシュトータルれ（Ｍ）
と、Ａの識別子ＩＤＡ、Ｈの識別子ＩＤＢ、および、該
ディジタル署名は前記の属性とは異なる属性に属するこ
とを示す記号ＳＩＧＮを含み、かつ、取引文書Ｍを含ま
ないデータＤＡＴＡ２を作成する。

ＤＡＴＡ２を、Ａの秘密鍵を用いて公開鍵暗号により暗
号変換して得られるディジタル署名Ｓ　（Ａ）　、およ
び、Ｂの秘密鍵を用いて公開鍵暗号により暗号変換して
得られるディジタル署名Ｓ　（Ｂ）をＡとＢの間で送受
信し合う。

ここで、５（Ａ）、５（Ｂ）は、該取引を正式しこ承諾
した旨を示す正式な署名、として使用される。

２、トラブル発生時に、調停機関は調停動作に必要な次
の情報を入力する。

（１）ＡあるいはＢから与えられる取引文書Ｍのハツシ
ュ１−一タルｈ（Ｍ） （２）該ハッシュトータルれ（Ｍ）に関ｔ、事前合意を
したか否かの旨を示すＡ、Ｂ本人の主張データ （３）Ａから与えられる前記Ｓ　（Ｂ）あるいはＴ　（
Ｂ）　、あるいは、Ｂから与えられるＳ　（Ａ）あるい
はＴ（Ａ、） ただｔ、該Ｓ　（Ｂ）あるいはＴ　（Ｂ）、Ｓ　（Ａ）
　、Ｔ　（Ａ）は後述する無効化リストに存在しないも
のとする。もｔ、それらが一つでも無効化リストに存在
する場合、該調停動作を中止する。

３、該入力データに対応じて、調停機関は調停動作を実
行する。

（１）もｔ、ＡおよびＢから入力される該事前合意の主
張データが、ともに、「事前合意有り」であれば、調停
機関Ｃは、ディジタル署名Ｓ　（Ａ）、Ｓ　（Ｂ）を、
調停機関Ｃを経由したうえで、ＢおよびＡに送信させる
。

（２）もｔ、ＡおよびＢから入力される該事前合意の主
張データの一方が、「事前合意無し」であれば、該入力
データを調整機関Ｃが保持する所定の判定手順に適用ｔ
、ＡあるいはＢのいずれが不当であるかという判定結果
データを出力ｔ、 その後、ｓ　（Ａ）　、　ｓ　（Ｂ）　、　Ｔ　（Ａ）
、Ｔ　（Ｂ）のうち、トラブルの争点となったものにっ
ては、調停機関Ｃが保管する無効化リストへ記録する。

なお、該判定手順は、第６図に示すような判定を行うよ
うに設定する。

〔作用〕

これにより、次の作用が生じる。

（１）トラブル無しに、Ａ、Ｂ間での署名交換が無事終
了した場合、次の作用が生じる。

（ａ）Ａは、Ｂの正式な署名Ｓ　（Ｂ）を持っている。

したがって、Ｂは後になって該取引を正式に承諾したこ
とを否定できない。

（ｂ）Ｂは、Ａの正式な署名Ｓ　（Ａ）を持っている。

したがって、Ａは後になって該取引を正式に承諾したこ
とを否定できない。

（２）トラブル時の調停動作において、調停機関は予定
的な署名Ｔ　（Ａ）　、　Ｔ　（Ｂ）あるいは正式な署
名Ｓ　（Ａ）　、Ｓ　（Ｂ）が提出された場合、次の作
用が生じる。

（、）該署名の原文、すなわち、該署名を復号化して得
られるデータに取引当事者ＡおよびＢの識別名ＩＤＡ、
ＩＤＥが含まれることにより、該取引はＡとＢの間の取
引であることを確認できる。

（ｂ）該署名の原文には、取引文書Ｍのハッシュトータ
ルれ（Ｍ）は含まれているが、取引文書Ｍそのものは含
まれていない。したがって、調停機関に取引文書Ｍの内
容そのものは知られることがなく、取引当事者のプライ
バシーを保護することができる。

（ｃ）Ｔ（Ａ）、Ｔ（Ｂ）の原文には、記号ＴＥＭＰが
含まれていることにより、調停機関は該署名は予備的な
署名であることを確認できる。

（ｄ）Ｓ（Ａ）、５（Ｂ）の原文には、記号ＳＩＧＮが
含まれていることにより、調停機関は該署名は正式な署
名であることを確認できる。

（３）トラブル時に調停機関によって無効化されたディ
ジタル署名を調停機関以外の者が別途記録しておき、後
で悪用しようとした場合、悪用に気付いた者が調停機関
に調停を依頼すれば、該取引に関するディジタル署名は
無効であることが判明するので、被害を防ぐことができ
る。

〔実施例〕

第１図は、本発明の一実施例である。第１図において、
取引者Ａ１０６が保持する計算機１０７と、取引者Ｂ１
１１が保持する計算機１１２、調停者１．０１が保持す
る計算機１０２は通信網１１０を介して互いに通信し合
えるようになっている。

計算機１０７には、Ａの秘密＠１０８と、データの組（
Ｂの識別子ＩＤＢ、Ｂの公開鍵）１０９が保持されてい
る。計算機１１２には、Ｂの秘密鍵１１２とデータの組
（Ａの識別子ＩＤＡ、Ａの公開＊）が保持されている。

計算機１０２には、データ（７）組（Ａ　（７）ｍ５３
１子Ｉ　Ｄ　Ａ　、　Ａ　ノ公開１１）　１０３とデー
タの組（Ｂの識別子ＩＤＢ、Ｂの公開鍵）、無効化リス
ト１０５が保持されている。

なお、計算機１０２および計算機１０７、計算機１１２
には、上記のデータを保持する他、通常の通信機能付き
ワークステーションに見られるような計算機能、データ
保持機能、通信機能を有しているものとする。

第２図は、第１図の実施例において、取引者Ａ１０６お
よび取引者Ｂ１１１の双方が取引文書Ｍに関して取引す
る場合の、計算機１０７および計算機１１２の動作を示
すものである。

２０１：動作開始。

２０２：取引者Ａ１０６の入力に従い、計算機１０７は
取引文書Ｍを作成する。

２０３：計算機１０７はＭを記録する。

２ｏ４：計算機１０７はＭを送信する。

２０５：計算機１１２はＭを受信する。

２０６　：　計算機１１２は、取引者Ｂ１１１の入力に
従い９Ｍの内容が取引者Ｂにより了承されたかどうかを
判定する。

２０７：計算機１１２は、上記判定結果は「ＮＯ」であ
れば、本処理フローを抜け、後述する■の処理に移る。

２０８：計算機１１２は、上記判定結果がｒＹｅｓＪで
あれば、Ｍを記録する。

２０９：計算機１１２は、予備的な署名Ｔ　（Ｂ）を次
のように計算する。

Ｔ（Ｂ）←ＥＢ（ＴＥＭＰ　Ｉｔ　ｈ　（Ｍ）　ｔｌ　
Ｉ　ＤＡ　Ｉｆ　Ｉ　ＤＢ）ここに、ＥＢ（・）はデー
タ・をＢの秘密鍵１１３を用いて、公開鍵暗号による符
号化変換して得られるデータを示す。ＴＥＭＰは、該デ
ィジタル署名は予備的な署名に属することを示す記号、
ｈ（Ｍ）はＭをハツシュ関数によって変換して得られる
ハツシュトータル、ＩＤＡはＡの識別子、ＩＤＥはＢの
識別子を示ｔ、ＴＥＭＰ　ＩＩ　ｈ（Ｍ）　ＩＩＩＤＡ
、１ｌＩＤＢはそれらのデータをつなぎ合わせたものを
示す。

なお、公開鍵暗号およびハツシュ関数の具体例は、例え
ば、池野、小山共著、「現代暗号理論」、（社）電子通
信学会、昭和６１年９月１月発効、の６章（Ｒ８Ａ公開
鍵暗号）、および、１２章（ディジタル署名）において
詳しく述べられている。

２１０：計算機１１２は、Ｔ（Ｂ）を送信する。

２１１：計算機１ｏ７は、Ｔ　（Ｂ　）　ヲ受（Ｎ　ｔ
　ル。

２１２：計算機１０７は、データ組（Ｂの識別子ＩＤＢ
、Ｂの公開＃）を用いて、公開鍵暗号による変換 ＤＢ　（Ｔ（Ｂ）） を行い、復号結果が ＴＥＭＰＩｌｈ（Ｍ）ＩＩＩＤＡＩＩ　ＩＤＢ）と等し
いかどうかを判定する。

２１３：計算機１０７は、上記判定結果がｒＮｏＪであ
れば、本処理フローを抜け、後述する■の処一２４＝ 理に移る。

２１４：計算機１０７は、上記判定結果が「Ｙｅｓ」で
あれば、Ｔ（Ｂ）を記録する。

２１５：計算機１０７は、正式な署名Ｓ　（Ａ）を次の
ように計算する。

５（Ａ）　←Ｅ＾（ＳＩＧＮｌｌｈ（ｍ）ＩｆＩＤＡＩ
ＩＤＢ）ここに、Ｅ＾（・）はデータ・をＡの秘密＠１
０８を用いて、公開鍵暗号により符号化変換して得られ
るデータを示す。

２１６：計算機１０７は、Ｓ　（Ａ）を送信する。

２１７：計算機１１２は、Ｓ　（Ａ）を受信する。

２］−８＝計算機１１２は、データ組（Ａの識別子ＩＤ
Ａ、Ａの公開１１１）を用いて、公開鍵暗号による変換 ＤＡ（Ｓ（Ａ）） を行い、復号結果が ＳＩＧＮＩｌｈ（Ｍ）ＩＩ　ＩＤＡＩＩ　ＩＤＥと等し
いかどうか判定する。

２１９：計算機１１２は、上記判定結果がｒＮｏＪであ
れば、本処理フローを抜け、後述する■の処理に移る。

２２ｏ：計算機１１２は、上記判定結果が「Ｙｅｓ」で
あれは、Ｓ　（Ａ）を記録する。

２２１：計算機１１２は、正式な署名Ｓ　（Ｂ）を次の
ように計算する。

Ｓ　（Ｂ）←ＥＢ（ＳＩＧＮｌｌｈ　（Ｍ）ＩＩＩＤＡ
ＩＩＩＤＢ）ここに、ＥＢ（・）はデータ・をＢの秘密
鍵１１３を用いて、公開鍵暗号により符号化変換して得
られるデータを示す。

２２２：計算機１１２は、Ｓ　（Ｂ）を送信する。

２２３：計算機１０７　ハ、Ｓ　（Ｂ）を受信する。

２２４：計算機１０７は、データ組（Ｂの識別子ＩＤＢ
、Ｂの公開鍵）を用いて、公開鍵暗号にょる変換 ＤＢ　　（Ｓ　　（Ｂ）） を行い、復号結果が、 ＳＩＧＮｌｌｈ　　（Ｍ）　　ＩＩＩＤＡＩＩＩＤＢと
等しいかどうかを判定する。

２２５：計算機１０７は、上記判定結果がｒＮｏｊであ
れば、本処理フローを抜け、後述する■の処理に移る。

２２６：計算機１０７は、上記判定結果ｒＹｅｓＪであ
れば、Ｓ　（Ｂ）を記録する。

２２７：動作終了。

第３図は、第１図の実施例において、取引者Ａまたは取
引者Ｂが待機中の場合の計算機１０７または計算機１１
２の動作を示すものである。

３０１：待機動作開始。

３０２：取引するつもりがないのに、ディジタル署名、
すなわち、前記形式を満足する予備的な署名あるいは正
式な署名を受信する。

３０２：動作を後述する■に移す。

第４図は、第２図の実施例において、動作が■に移った
後の動作フローを示している。

４０１：計算機１１２は「取引文書Ｍに関する取引を拒
否する」旨の拒否メツセージを作成する。

４０２：計算機１１２は拒否メソセージを送信する。

４０３：計算機１０７は拒否メツセージを受信する。

４０４：動作終了。

第５図は、第２図および第３図の実施例において、動作
が■に移った後の動作フローを示している。

５０１：　　ｒハッシュトータルれ（Ｍ）、識別子ＩＤ
Ａ、ＩＤＥに関して調停を依頼する」旨の調停メツセー
ジを作成する。

５０２地揚程依頼メツセージを調停者の計算機１０２に
送信する。

５０３：計算機１０２は、調停依頼メツセージを受信す
る。

５０４：計算機］−０２は受信したメツセージのうち、
ＩＤＡとＩＤＥから、取引の当事者としてＡとＢを特定
する。

５０５：計算機１０２は、ＡとＢに対しｈ　（Ｍ）に関
して事前合意があったか否かを問い合せる。

５０６：ＡとＢの計算機１０７，１１２は、この問い合
わせを受信する。

５０７：言１算機１０７．１］−２はＡとＢの入力に従
い、「事前合意有」もしくは「事前合意無し」の旨の返
答を行う。

５０８：計算機１．０２は、ＡとＢからの返答が、とも
に「事前合意有り」の旨となっているかどうかを判定す
る。

５０９：計算機１０２は、判定結果がｒＹｅｓＪでれば
、計算機１０２の仲介により、ＡとＢの正式な署名Ｓ　
（Ａ）　、　Ｓ　（Ｂ）を交換させ、ステップ５１４へ
進む。

５　］、　０　：　ｍｌ算機１０２は、判定結果がｒＮ
ｏＪであれば、ＡとＢに対ｔ、相手のディジタル署名で
既に受は取ったものがあれば提出するよう要求する。

５１１：ＡとＢの計算機１０７，１１２はこの要求を受
信する。

５１２：計算機１０７，１１２は、この要求に対応する
ディジタル署名を送るか、該当するディジタル署名は持
たない旨の返答を行う。

５１３：計算機１０２は、第６図の判定表に従う判定を
行う。すなわち、 次の３とおりの場合に応じて判定を行う、（１）第１の
場合、すなわち、Ｂは「事前合意有り」、Ａは「事前合
意無し」の旨のデータを入力する場合、 ＡはＳ　（Ｂ）を入力せず、ＢはＳ　（Ａ）およびＴ　
（Ａ）のいずれも入力しないとき、調停機関Ｃは「判定
できず」の旨のデータを出力ｔ、 ＢはＴ　（Ａ）を入力するとき、調停機関Ｃは「Ａは不
当である」の旨のデータを出力ｔ、ＢはＳ　（Ａ）を入
力するとき、調停機関Ｃは「Ａは不当である」の旨のデ
ータを出力ｔ、Ａは５（Ｂ）を入力ｔ、ＢはＳ　（Ａ）
およびＴ　（Ａ）のいずれも入力しないとき、「Ｂは不
当であるＪの旨のデータを出力する。

（２）第２の場合、すなわち、Ａは「事前合意有り」、
Ｂは「事前合意無し」のデータを入力する場合、 ＡはＳ　（Ｂ）およびＴ　（Ｂ）のいずれのデータも入
力せず、ＢはＳ　（Ａ）を入力しないとき、調停機関Ｃ
は１判定できず」の旨のデータを出力、 ＡはＳ　（Ｂ）およびＴ　（Ｂ）のいずれも入力せず、
ＢはＳ　（Ａ）を入力するとき、調停機関Ｃは「Ａは不
当である」の旨のデータを出力ｔ、 ＡはＴ　（Ｂ）を入力するとき、調停機関Ｃは１Ｂは不
当である」の旨のデータを出力ｔ、ＡはＳ　（Ｂ）を入
力するとき、調停機関Ｃは「Ｂは不当である」の旨のデ
ータを出力する。

（３）第３の場合、すなわち、ＡおよびＢがともに「事
前合意無し」の旨のデータを入力する場合、 ＡはＳ　（Ｂ）およびＴ　（Ｂ）のいずれも入力せず、
ＢはＳ　（Ａ）およびＴ　（Ａ）のいずれも入力しない
とき、調停機関Ｃは「判定できず」の旨のデータを出力
ｔ、 ＡはＳ　（Ｂ）およびＴ　（Ｂ）のいずれも入力せず、
ＢはＴ　（Ａ）を入力するとき、調停機関ＣはＦＡは不
当である」の旨のデータ髪出力ｔ、 ＡはＳ　（Ｂ）およびＴ　（Ｂ）のいずれも入力せず、
ＢはＳ　（Ａ）を入力するとき、調停機関Ｃは「Ａは不
当である」の旨のデータを出力ｔ、 ＡはＴ　（Ｂ）を入力ｔ、ＢはＳ　（Ａ）およびＴ　（
Ａ）のいずれも入力しないとき、調停機関Ｃは「Ｂは不
当である」の旨のデータを出力ｔ、 ＡはＳ　（Ｂ）を入力ｔ、ＢはＳ　（Ａ）およびＴ　（
Ａ）のいずれも入力しないとき、調停機関Ｃは「Ｂは不
当である」の旨のデータを出力ｔ、 ＡはＴ　（Ｂ）を入力ｔ、ＢはＳ　（Ａ）を入力すると
き、調停機関Ｃは「ＡおよびＢは不当である」の旨のデ
ータを出力ｔ、 ＡはＴ　（Ｂ）を入力ｔ、ＢはＴ　（Ａ）を入力すると
き、調停機関Ｃは［ＡおよびＢは不当である」の旨のデ
ータを出力ｔ、 ＡはＳ　（Ｂ）を入力ｔ、ＢはＳ　（Ａ）を入力すると
き、調停機関Ｃは「ＡおよびＢは不当である」の旨のデ
ータを出力ｔ、 ＡはＳ　（Ｂ）を入力ｔ、ＢはＳ　（Ａ）を入力すると
き、調停機関Ｃは「ＡおよびＢは不当である」の旨のデ
ータを出力する。

５１４：争点となったディジタル署名を無効化リストに
記録する。

５１５：動作終了。

〔実施例の変形例１〕 上記の実施例は、調停者、取引者Ａ、取引者Ｂの３人が
参加する通信ネットワークの例であったが、調停者、取
引者Ａ、取引者Ｂ、取引者Ｃ１のように多人数が参加す
るネットワークにおいて、調停者を除く任意の１者間の
署名交換を行うようにしてもよい。

〔実施例の変形例２〕 上記の実施例は、調停者、取引者Ａ、取引者Ｂの間の通
信の仕方は、通信したいデータをそのままの形で通信す
るようにしているが、通信データを暗号化するか、ある
いは、ディジタル署名付きで送受信することにより、デ
ータの盗み見を防止したり、通信の度、データの発信元
を確認できるようにしてもよい。

〔実施例の変形例３〕 上記実施例は、調停者、取引者Ａ、取引者Ｂの通信は、
同じ通信網を通じて行っているが、取り者Ａと取引者Ｂ
の間の通信のための通信網と、調停者との通信のための
通信網は別の形態でもよい。

例えば、取引者Ａと取引者Ｂの間は電気信号による通信
を行い、調停者との通信は、通信文をフロッピーディス
クの入れて、手配送で送るようにしてもよい。

〔実施例の変形例４〕 上記の実施例のステップ５１４において、ＡからＳ　（
Ｂ）およびＴ　（Ｂ）のいずれも調停機関に提出されず
、ＢからＳ　（Ａ）のいずれも調停機関に提出されない
場合、Ａから提出さるＴ　（Ａ）あるいはＢから提出さ
れるＴ　（Ｂ）を無効化リストに記録するよう動作を追
加してもよい。

〔実施例の変形例５〕 上記の実施例において、予備的な署名および正式な署名
の原文に時刻データＬを入れるようにしてもよい。すな
わち、 （１）予備的な署名の原文を、 （２）正式な署名の原文を、 としでもよい。

〔実施例の変形例６〕 上記の実施例において、調停者、取引者Ａ、取引者Ｂは
各々一つの計算機でディジタル署名の符号化、復号化処
理を行うようにしていたが、符号化処理の全部もしくは
一部をＩＣカードで行い、残りの処理は通信機能付きの
ワークステーションで行うというように、処理を分割し
てそれぞれを異なる計算機構で行うようにしてもよい。

〔実施例の変形例７〕 上記の実施例において、取引文書は、取引者Ａが作成す
るとしたが、電話、テレビ会議、あるいは、電子対話等
により、取引者Ａ、Ｂの双方が協力して作成するように
してもよい。

〔実施例の変形例８〕 上記の実施例において、取引文書Ｍはどういうものかを
特定しなかったが、取引文書として、通信相手の裏書き
を必要とするような手形伝票、何らかの契約文書、受領
証を必要とする申し込み文書、テレビ会議のビデオデー
タ、電話での打合せの録音データ等、双方の「言質」を
必要とするような特定の取引業務における通信データと
してもよい。

〔効果〕

本発明の効果は次のとおりである。

（１）署名交換の実現性 ＡとＢが所定の手続きに従う限り、本発明の手順実施後
は、ＡとＢは互いの正式な署名を持ち合うことができる
。そして、正式な署名交換後において次の状態を得る。

（ａ）Ａは、Ｂの正式な署名Ｓ　（Ｂ）を持っている。

したがって、Ｂは後になって該取弓を正式に承諾したこ
とを否定できない。

（ｂ）Ｂは、Ａの正式な署名Ｓ　（Ａ）を持っている。

したがって、Ａは後になって該取引を正式に承諾したこ
とを否定できない。

（２）署名交換の連続性 もｔ、Ａが所定の手続きを経てＡの正式な署名をＢに送
信したものとする。このとき、ＢもまたＢの正式な署名
をＡに送り返さなければならないという署名交換の連続
性が保証される。

これは、第６図により与えられる調停動作時の判定手順
から得られる。尚、この判定では、ハッシュトータルれ
（Ｍ）、識別子ＩＤＡ、ＩＤＢが調停機関に提出される
こと、および、提出される予備的な署名または正式な層
側は無効化リストに存在しないことを前提としている。

また、図において、○は提出すること、×は提出しない
こと、−は提出してもしなくてもよいことを意味してい
る。

なお、この調停動作がＡとＢの間で生じ得るすべての係
争を解決することは、 Ｋ、　Ｔａｋａｒａｇｊ、、　Ｒ，５ａｓａｋｉ、　”
Ａ　ｐｒａｃｔｉｃａｌ　ａｎｄｆａｉｒ　ｐｒｏｔｃ
ｏｌ　ｆｏｒ　ｓｉｇｎｉｎｇ　ｃｏｎｔｒａｃｔ”、
情報処理学会ＩＳＯ／５Ｃ２０国内委員会ＷＧ１・３小
委員会、機械振興会館、昭和６３年７月８日において厳
密に証明されている。

＝３８− （３）調停者に対するプライバシー保護１〜ラブｙ発生
時、調停機関に提出されるディジタル署名の原文には、
取引文書Ｍのハツシュｈ−タルｈ（Ｍ）は含まれている
が、取引文書Ｍそのものは含まれていない。したがって
、調停機関に取引福文書Ｍの内容そのものは知られるこ
とがなく、取引当事者のプライバシーを保護することが
できる。

【図面の簡単な説明】

第１図は、本発明の１実施例であり、取引者Ａが保持す
る計算機、取引者Ｂが保持する計算機、調停者が保持す
る計算機が通信網を介して通信し合う実施例を示してい
る。 第２図は、第１図の実施例において、取引者Ａおよび取
引者Ｂの双方が取引する場合の計算機の動作を示すもの
である。 第３図は、第１図の実施例において、取引者Ａまたは取
引者Ｂが待機中の場合の計算機の動作を示すものである
。 第４図は、第２図の実施例における動作の一部を示して
いる。 第５図は、第２図および第３図の実施例における動作の
一部を示している。 第６図は、第５図の実施例における調停者の判定動作を
示している。

Claims (1)

1. 【特許請求の範囲】 １、取引者Ａ、取引者Ｂおよび調停機関Ｃからなり、取
   引文書Ｍに関するディジタル署名を送受信するシステム
   であり、 少なくとも取引文書Ｍのハッシュトータル ｈ（Ｍ）と、Ａの識別子ＩＤＡ、Ｂの識別子ＩＤＢ、お
   よび、該ディジタル署名はある属性に属することを示す
   記号ＴＥＭＰを含み、かつ、取引文書Ｍを含まないデー
   タを、Ａの秘密鍵を用いて公開鍵暗号により暗号変換し
   て得られるディジタル署面Ｔ（Ａ）、または、Ｂの秘密
   鍵を用いて交開鍵暗号より暗号変換して得られるディジ
   タル署名Ｔ（Ｂ）をＡとＢの間で送受信し合った後、 少なくとも取引文書Ｍのハッシュトータル ｈ（Ｍ）と、Ａの識別子ＩＤＡ、Ｂの識別子ＩＤＢ、お
   よび、該ディジタル署名は前記の属性とは異なる属性に
   属することを示す記号ＳＩＧＮを含み、かつ、取引文書
   Ｍを含まないデータを、Ａの秘密鍵を用いて公開鍵暗号
   により暗号変換して得られるディジタル署名Ｓ（Ａ）、
   および、Ｂの秘密鍵を用いて公開鍵暗号により暗号変換
   して得られるディジタル署名Ｓ（Ｂ）をＡとＢの間で送
   受信し合うことを特徴とする署名交換方式。 ２、取引者Ａ、取引者Ｂおよび調停機関Ｃからなり、取
   引文書Ｍに関するディジタル署名を送受信するシステム
   であり、取引者Ａ、Ｂ間のトラブルを調停する要請が生
   じたとき、調停機関Ｃは、ＡあるいはＢから与えられる
   取引文書Ｍのハッシュトータルｈ（Ｍ）と、該ハッシュ
   トータルｈ（Ｍ）に関し、事前合意をしたか否かの旨を
   示すＡ、Ｂ本人の主張データ、 および、Ａから与えられる前記Ｓ（Ｂ）あるいはＴ（Ｂ
   ）、あるいは、Ｂから与えられるＳ（Ａ）あるいはＴ（
   Ａ）を入力データとして、もし、ＡおよびＢから入力さ
   れる該事前合意の主張データが、ともに、「事前合意有
   り」であれば、調停機関Ｃは、ディジタル署名Ｓ（Ａ）
   、Ｓ（Ｂ）を、調停機関Ｃを経由したうえで、Ｂおよび
   Ａに送信させ、 もし、ＡおよびＢから入力される該事前合意の主張デー
   タの一方が、「事前合意無し」であれば、該入力データ
   を調停機関Ｃが保持する所定の判定手順に適用し、Ａあ
   るいはＢのいずれが不当であるかという判定結果データ
   を出力し、その後、Ｓ（Ａ）、Ｓ（Ｂ）、Ｔ（Ａ）、 Ｔ（Ｂ）のうち、トラブルの争点となったものについて
   は、調停機関Ｃへの入力データとして用いられたものに
   ついては、調停機関Ｃが保管する無効化リストへ記録す
   ることを特徴とする署名交換方式。 ３、第２項記載の判定手順は、 もし、ディジタル署名Ｓ（Ａ）、Ｓ（Ｂ）、Ｔ（Ａ）、
   Ｔ（Ｂ）のうち、一つでも前記無効化リストに既に記録
   されている場合、判定を実施せず、 それ以外は、次の３のとおりの場合に応じて判定を行う
   、すなわち、 第１の場合、すなわち、Ｂは「事前合意有り」、Ａは「
   事前合意無し」の旨のデータを入力する場合、 ＡはＳ（Ｂ）を入力せず、ＢはＳ（Ａ）およびＴ（Ａ）
   のいずれも入力しないとき、調停機関Ｃは「判定できず
   」の旨のデータを出力し、ＢはＴ（Ａ）を入力するとき
   、調停機関Ｃは「Ａは不当である」の旨のデータを出力
   し、ＢはＳ（Ａ）を入力するとき、調停機関Ｃは「Ａは
   不当である」の旨のデータを出力し、ＡはＳ（Ｂ）を入
   力し、ＢはＳ（Ａ）およびＴ（Ａ）のいずれも入力しな
   いとき、「Ｂは不当である」の旨のデータを出力し、 第２の場合、すなわち、Ａは「事前合意有り」、Ｂは「
   事前合意無し」のデータを入力する場合、ＡはＳ（Ｂ）
   およびＴ（Ｂ）のいずれのデータも入力せず、ＢはＳ（
   Ａ）を入力しないとき、調停機関Ｃは「判定できず」の
   旨のデータを出力し、 ＡはＳ（Ｂ）およびＴ（Ｂ）のいずれも入力せず、Ｂは
   Ｓ（Ａ）を入力するとき、調停機関Ｃは「Ａは不当であ
   る」の旨のデータを出力し、ＡはＴ（Ｂ）を入力すると
   きに、調停機関Ｃは「Ｂは不当である」の旨のデータを
   出力し、ＡはＳ（Ｂ）を入力するとき、調停機関Ｃは「
   Ｂは不当である」の旨のデータを出力し、第３の場合、
   すなわち、ＡおよびＢがともに「事前合意無し」の旨の
   データを入力する場合、ＡはＳ（Ｂ）およびＴ（Ｂ）の
   いずれも入力せず、ＢはＳ（Ａ）およびＴ（Ａ）のいず
   れも入力しないとき、調停機関Ｃは「判定できず」の旨
   のデータを出力し、 ＡはＳ（Ｂ）およびＴ（Ｂ）のいずれも入力せず、Ｂは
   Ｔ（Ａ）を入力するとき、調停機関Ｃは「Ａは不当であ
   る」の旨のデータを出力し、ＡはＳ（Ｂ）およびＴ（Ｂ
   ）のいずれも入力せず、ＢはＳ（Ａ）を入力するとき、
   調停機関Ｃは「Ａは不当である」の旨のデータを出力し
   、ＡはＴ（Ｂ）を入力し、ＢはＳ（Ａ）およびＴ（Ａ）
   のいずれも入力しないとき、調停機関Ｃは「Ｂは不当で
   ある」の旨のデータを出力し、ＡはＳ（Ｂ）を入力し、
   ＢはＳ（Ａ）およびＴ（Ａ）のいずれも入力しないとき
   、調停機関Ｃは「Ｂは不当である」の旨のデータを出力
   し、ＡはＴ（Ｂ）を入力し、ＢはＳ（Ａ）を入力すると
   き、調停機関Ｃは「ＡおよびＢは不当である」の旨のデ
   ータを出力し、 ＡはＴ（Ｂ）を入力し、ＢはＴ（Ａ）を入力するとき、
   調停機関Ｃは「ＡおよびＢは不当である」の旨のデータ
   を出力し、 ＡはＳ（Ｂ）を入力し、ＢはＳ（Ａ）を入力するとき、
   調停機関Ｃは「ＡおよびＢは不当である」の旨のデータ
   を出力し、 ＡはＳ（Ｂ）を入力し、ＢはＳ（Ａ）を入力するとき、
   調停機関Ｃは「ＡおよびＢは不当である」の旨のデータ
   を出力することを特徴とする署名交換方式。 ４、取引者Ａ、取引者Ｂおよび調停機関Ｃからなり、取
   引文書Ｍに関するディジタル署名を送受信するシステム
   であり、 少なくとも取引文書Ｍのハッシュトータル ｈ（Ｍ）と、Ａの識別子ＩＤＡ、Ｂの識別子ＩＤＢ、時
   刻データｔ、および、該ディジタル署名はある属性に属
   することを示す記号ＴＥＭＰを含み、かつ、取引文書Ｍ
   を含まないデータを、Ａの秘密鍵を用いて公開鍵暗号に
   より暗号変換して得られるディジタル署名Ｔ（Ａ）、ま
   たは、Ｂの秘密鍵を用いて公開暗号により暗号変換して
   得られるディジタル署名Ｔ（Ｂ）をＡとＢの間で送受信
   し合った後、 少なくとも取引文書Ｍのハッシュトータル れ（Ｍ）と、Ａの識別子ＩＤＡ、Ｂの識別子ＩＤＢ、時
   刻データｔ、および、該ディジタル署名は前記の属性と
   は異なる属性に属することを示す記号ＳＩＧＮを含み、
   かつ、取引文書Ｍを含まないデータを、Ａの秘密鍵を用
   いて公開鍵暗号により暗号変換して得られるディジタル
   署名Ｓ（Ａ）、および、Ｂの秘密鍵を用いて公開鍵暗号
   により暗号変換して得られるディジタル署名Ｓ（Ｂ）を
   ＡとＢの間で送受信し合うことを特徴とする署名交換方
   式。