電子署名アルゴリズムにおいては、平文を署名鍵で処理することで署名を生成し、署名の検証を検証鍵で行う。しかし、データベースにおいては、各レコードにユニークな情報のみが問題となる。従って、この明細書においては、適宜、各鍵ペアにユニークな検証鍵情報を公開鍵と呼び、各鍵ペアの秘匿される署名鍵情報を秘密鍵と呼ぶこととする。例えば、RSA署名では、平文cと署名値sとの関係は以下の通りである。
c = s^e mod n
s = c^d mod n
つまり、平文cに対して、dとnを用いて署名値sを計算できる。また、署名値sに対して、eとnを用いて平文cを計算できる。ここで、署名鍵はdとnであり、検証鍵は、eとnとなっている。通常、eは予め一定の数に決めておくので、実質的な検証鍵、つまり各レコードにユニークな公開鍵はnである。また、nが公開されているので、実質的な秘匿すべき署名鍵(秘密鍵)はdである。また、ECDSAの場合は、署名は署名鍵のみで行うことができるが、署名鍵から検証鍵を算出することは容易である。
この明細書でも、RSAを用いる実施例では、eは予め一定の数に決めておく。従って、以下の記述では、dのみを秘密鍵と呼び、nのみを公開鍵と呼ぶことにする。また、以下の記述では、パディングやハッシュ処理など平文への前処理も含めて署名の処理とする。
本発明の実施例1に関わる識別名管理システムは、インターネットに接続し、識別名を管理する管理サーバーとして実装される。この管理サーバーと通信して識別名を利用する為に、ユーザーのパソコン側には専用のユーティリティソフトがインストールされる。管理サーバーでは、個々の匿名ユーザーに対して、識別名としてユニークなサイバーネームを発行し、このサイバーネームを対応する匿名ユーザーの公開鍵に関連付けて公開する。個々のサイバーネームがユニークであることは、管理サーバーが管理し保証するが、全て公開されるので誰でも重複の有無を確認できる。
パソコンのユーティリティソフトでは、公開鍵と秘密鍵のペアを生成し保存する。ただし秘密鍵は暗号化しておく。そして、その公開鍵とサイバーネームを関連付けて登録を行うように、管理サーバーに依頼する。秘密鍵は管理サーバーへは送信されず、ユーザーが自己責任において秘匿する。また、ユーザーがメッセージを投稿する際に、署名をすることでサイバーネームで認証を付けたり、他人のメッセージの認証を検証したりできる。この実施例では、署名アルゴリズムとして2048ビットのRSAを用いるものとする。
なお、管理サーバーとユーザーとは、SSLで保護された通信を行うが、このSSLはTLS(Transport Layer Security)も含むものとする。特に、必須ではないが、クライアント認証も行うことが好ましい。この場合は、サイバーネームに関連付けられた公開鍵を用いると便利である。
識別名管理システムの基本的な機能は、インターネットのユーザーが、個人情報を開示すること無く、電子署名を利用出来るようにするものである。その為に、各ユーザーの識別名と公開鍵を対応付けて、登録し一般に公開する。これによって各ユーザーは、インターネットにおける自分の活動に対して、電子署名を付けることで他人と明確に区別し、自分の識別名によって、インターネットにおけるアイデンティティを確立することが出来る。
<サイバーネームの登録> この実施例では、サイバーネームの登録は匿名で行われる。この場合、一人のユーザーが、多くのサイバーネームを登録してしまうと、サイバーネームが足りなくなってしまう。従って、むやみに発行依頼ができないような仕組みが必要となる。その目的で、例えば、機械が自動的に読み取ることが難しい不鮮明で歪んだような文字を画面に表示し、ユーザーに読み取らせるCAPTCHA(キャプチャ)システムを利用することができる。また、適宜、同じIPアドレスからの登録を制限したり、クッキーを利用するようにしてもよい。
また、サイバーネームを利用するには、暗号関連のユーティリティソフトが必要である。このユーティリティソフトに実装される機能としては、公開鍵と秘密鍵のペアを生成する機能、これらの鍵をBase64によって文字列に変換する機能、秘密鍵をパスワードで暗号化して保存する機能、秘密鍵を用いてデータに署名をする機能、署名をBase64 によって文字列に変換する機能する機能がある。
更に、この実施例では、ユーティリティソフトには、簡易ブラウザ機能も実装されている。これは、認証されたメッセージを発信したい場合に、このユーティリティソフトのブラウザから認証処理を手軽に行うためのものである。しかし、このブラウザ機能は必須ではない。適宜、ブラウザ機能を用いない方法も適宜説明する。なお、万一の情報紛失に備えて、Base64によって文字列に変換された公開鍵や秘密鍵を印刷する機能もある。
以下、図1を参照して、サイバーネーム登録の手続きを説明する。図1は、この実施例で用いるユーティリティソフトの登録画面である。識別名管理システムの管理サーバー10にサイバーネームの登録を希望するユーザーは、希望サイバーネームを入力し、送信ボタンをクリックして、管理サーバー10へ送信する(S1)。管理サーバー10では、発行可能なサイバーネームを返す(S2)。この発行可能なサイバーネームは、発行サイバーネームのボックスに表示される。また、同時に、管理サーバー10は、CAPTCHAの歪んだ文字列の画像データも送信する。この画像データは、ユーティリティソフトの画面に表示されるので、ユーザーは、この文字列を読んで、この文字列を下の入力ボックスへ入力しておく。
ここで発行可能なサイバーネームは、入力されたサイバーネームの先頭にプリフィックスが付加されている。このプリフィックスは、ユニークなサイバーネームを得るためのハッシュ値であり、見た目でもなるべく類似するサイバーネームがないように管理サーバー10側で選択される。プリフィックスの末尾はアンダーバーとなっている。例えば、図1の例ではサイバーネームとしてNuagesを希望し、aZ38_Nuagesが発行可能な例として管理サーバー10から返されている。
これにより、****_Nuagesというパターンを持つサイバーネームは、複数のユーザーが利用出来ることになる。この例のように、Base64で利用されている4文字を用いることにすれば、16,777,216通りのプリフィックスが存在することになる。また、アンダーバー"_"で明確に区切られているので、プリフィックスの文字数は固定しなくても良い。
また、ユーティリティソフトはRSA公開鍵と秘密鍵のペアを算出する。ユーザーは、この秘密鍵を暗号化する為の秘密鍵暗号化用パスワードを入力しておく。更に、ユーザーが望む場合には、オプション署名用テキストも入力しておく。このテキストの利用方法は後述する。また、ユーティリティソフトが256ビットの乱数を生成して、それを確認ハッシュ(ID Hash)として表示する。このハッシュの利用方法も後述する。
以上の入力を終え、申請ボタンをクリックすると、サイバーネームと共に、RSA公開鍵、オプションデータや確認ハッシュおよびCAPTCHA の入力文字列が管理サーバー10へ送信される(S3)。ただし、この実施例では、オプション署名用テキストを秘密鍵で署名した2048ビットの署名値が、オプションデータとして送信される。受信したCAPTCHA入力文字列が正しければ、管理サーバー10は、現在日時を仮登録日時として、それらの情報をサイバーネームに関連付けて保存し、ユーザーへ仮登録情報を返す(S4)。
ユーザーはこの仮登録情報を確認し、以後、そのサイバーネームを使用することができるようになる。そして、最初に、ユーザー署名を行ってサイバーネームを使用した日が本登録の日とする。もし、仮登録から一週間以内に本登録がなされなければ、仮登録は無効となる。その場合、ユーザーは最初からやり直さなければならない。
なお、この例では、プリフィックスを管理サーバー10が決定しているので、ステップS1、S2を最初に行う。しかし、ユーティリティソフト側で、乱数からプリフィックスを決定し、ステップS1、S2を省略しても良い。その場合は、ステップS3で、そのプリフィックスを含むサイバーネームを送信する。サイバーネームに重複があれば、ユーティリティソフトへ通知される。
<オプション署名> 管理サーバー10では、ユーザーからのオプションデータも登録し、一般に公開する。このオプションデータとして次のような用途が考えられる。すなわち、図1に示すように、当該ユーザーを特定する個人情報を、署名したい文章として入力する。そして、管理サーバー10へ送信する際には、ユーティリティソフトは、この個人情報への署名をオプションデータとして送信する。ただし、オプションデータとしては、256ビットのRSA署名のみで、個人情報のテキストは含まれていない。この場合、個人情報はハッシュ関数で処理されるので、署名データからは元の個人情報を得ることは不可能である。従って、個人情報の署名を公開しても、匿名性は保たれる。
一方で、署名そのものはサイバーネームや公開鍵と関連付けて登録されているので、サイバーネームの所有者が誰であるかは、その所有者が望めば、何時でも証明可能となる。すなわち、上記個人情報データを示して、登録されている署名に対応していることを示せば良い。なお、256ビットのRSA署名を想定して、オプションデータの最大サイズは半角44文字までとする。
このような状況は、サイバーネームに対応する秘密鍵を紛失したり、漏洩したりした場合に、本人確認の有力な証拠として利用出来る。署名された平文データも紛失した場合も考えられるので、予め推奨する定型文を決めておくことも考えられる。例えば、登録年月日が2010/02/28で、住所が東京都千代田区千代田1番1号で、名前が認証太郎で、サイバーネームがaZ38_Nuagesである場合には、図1の「オプション署名用テキスト」のブロックに示されているようなフォーマットで、それらの情報を連結して本人確認の為のテキストする。万一、ユーザー側の全てのデータが消えてしまっても、この通りに機械的にテキストを作成して、サイバーネームに対応する公開鍵を用いてオプション署名と照合すれば本人確認が可能となる。
しかしながら、定型文を使うと不都合な場合も考えられる。例えば、サイバーネームのユーザーとしての候補が幾つかあった場合、考えられる総当たり攻撃で定型文を照合し続ければ、どの候補が本人であるかを特定することができてしまう可能性がある。このような状況では、不特定の形式で本人確認テキストを作成したほうが好ましい。より確実なのは乱数や後述のオプションハッシュを上記個人情報に付加して、オプションデータとする方法である。
一方で電子データとして保存しておくことは、常に漏洩や紛失、消失の可能性がつきまとう。一般的には、秘密鍵や本人確認テキストを含む、登録情報の全てを紙に印刷しておき、適当な場所に保管しておくことが一つの安全な方法である。
<オプションハッシュ> 秘密鍵の漏洩などで、複数のユーザーが同一サイバーネームのもとで署名が可能となってしまった場合、ハッシュ値をオプションデータとして登録しておくと、抽象的な本人確認が可能となる。
すなわち、乱数等をSHA-256等のハッシュ関数で複数回(例えば、千回)再帰的に処理した値を、オプションデータとして登録しておく。そして本人確認が必要な状況にはめったにならないので、最初の乱数等は、USBメモリなどの外部ストレージに記憶したり、紙に印刷しておく。
本人確認を行うには、登録されているオプションデータの原像を提示すれば良い。また、サイバーネームの登録を更新する場合、公開鍵の変更は許可されないが、オプションデータの変更は可能としておく。従って、オプションデータを、本人確認の為に提示してしまった原像に変更しておけば、何度でも本人確認を行うことが出来る。その場合でも、最初の登録の際のユーザーに関する本人確認となる。
<登録情報の明証化> 管理データベースの記録は専用のサイトで一般に公開され、誰でもサイバーネームに対応する公開鍵を取得することができる。また、一定期間に登録された記録は、ファイルとしてダウンロードできる。例えば、一週間単位で、その期間に登録されたサイバーネームに関連付けて、公開鍵、登録日およびオプション署名が、CSVファイル等のリストファイルとしてダウンロード可能に公開される。そして、そのリストファイルのハッシュ値が、新聞などの刊行物に公表される。これを登録情報の明証化と呼ぶ(S5)。
すなわち、この明細書において、明証化とは、管理サーバー10がデジタルデータとして一般に公開したサイバーネームと公開鍵との一対一の対応関係を、改竄不可能な刊行物に印刷された情報によって、客観的に固定化する行為を指す。但し、この対応関係の固定化は、ここで用いられる暗号技術の有効性に依存するので、必要が生じた際に、データをカプセル化して再度明証化を行う。
新聞広告の具体例を図2に示す。また、リストファイルの具体例は、図3に示す。なお、図2の具体例では、2つのハッシュ値を公表している。万一何れか一方が破られても、他方の有効性が保たれる。また、リンク情報の代表値も公表されている。この代表値については後に詳しく説明する。
従って、対応する秘密鍵の所有者(サイバーネームの使用者)は、当該リストファイルを保存しておくことで、管理サーバー10とは無関係に、何時でも自分が当該サイバーネームの使用者であることを証明できる。このリストファイルと公表されたハッシュ値は、利用しているハッシュ関数の安全性が確認されている期間について、有効性が保証される。すなわち、リストファイルと刊行物の組み合わせで、そのサイバーネームに対する公開鍵証明書となっている。
<サイバーネームによる認証1> 登録が済むと、掲示板などのWebサイトにユーザーが何らかの意見や情報を書きこむ際などに、サイバーネームを用いて認証を付けることができる。上記ユーティリティソフトには、簡易ブラウザ機能が実装されており、認証を付けて情報の送信を行う場合には、ユーティリティソフトを立ち上げて、そのブラウザ機能を用いる。ここでは、「子ども手当2-3000円増額は、大歓迎です」という書き込みを掲示板サイトのエディットボックスへ行う場合を図4を参照して説明する。
先ず、ユーティリティソフトで、その掲示板サイトの投稿ページ(一般には、情報発信先のページ)を開く。そこにメッセージを書きこんで、送信するためのボタンをクリックすると、実際の送信を行う前にユーティリティソフトは、サイバーネームを管理サーバーへ送信して、認証開始要求を行う。管理サーバーでは、サイバーネームの有効期限が切れていれば、その旨通知して処理が終了する。有効期限が切れていなければ、サイバーネームの格付け(後述)と現在時刻をユーティリティソフトへ送信する(S1)。
そして、ユーティリティソフトは、パスワードボックスを備えたポップアップウインドウを表示し、署名用メッセージ23を提示する(S2)。ただし、書き込まれたメッセージに加えて、署名用メッセージ23では、管理サーバーからの情報に基づいて、サイバーネームと、格付け(ここではA)と、現在日時が追加されている。格付けは、ユーザーの信頼度の目安を与えるもので、サイバーネームの後に:を挟んで挿入される。日時はタイムサーバーからその都度取得する。
ユーザーは、内容を確認し、パスワードを入力してから、OK ボタンをクリックする。ユーティリティソフトは、パスワードから秘密鍵を複合し、格付けと現在日時とサイバーネームを含むメッセージに署名を行い、メッセージと署名を、管理サーバーへ認証要求として送信する(S3)。また、投稿先のサイト情報(URL)も、認証要求と共に送信する。このURLは、管理サーバー側で投稿先を示す情報として後述の発言リストで使用する。
認証要求を受けた管理サーバーは、受信したユーザー署名を検証する(S4)。検証に失敗すれば、その旨、ユーザーへ通知して処理を終了する。検証に成功すれば、メッセージに、シリアルナンバーを割り振り、後述のシールを挿入して認証メッセージを作成し、これをユーティリティソフトへ返し(S5)、認証メッセージの登録を行う(S6)。ユーティリティソフトは、この認証メッセージを投稿先サイトへ送信する(S7)。
ここで、図4に示したように、この認証メッセージにおいて、シリアルナンバーはURL55に埋めこまれている。このシリアルナンバーは、全てのユーザーのメッセージを時系列に並べるもので、16進数(図4では"003F4959")で表記されている。また、ユーザー署名からシールが算出され、認証日時(現在日時)の後に挿入される。このシールはユーザーの認印のような機能を持つ。
後述の通り、これらシリアルナンバーは、対応する認証メッセージのハッシュ値に関連付けられることで、このメッセージに対する認証データとなっている。すなわち、サイバーネームに対応してユーザー署名がされていることと、記載されている認証日時が正しいことが、管理サーバーにおいて確認され認証されていることを示している。
従って、認証データを管理サーバーへ提示することで、管理サーバーによる認証の確認を行うことができる。その手順は後に説明する。認証の確認が行われた場合、それは管理サーバーへの信頼性を根拠としている。より厳密には、明証化された公開鍵やリンク情報を用いて、誰でも客観的に署名や認証日時の検証を行うこともできる。その手順も後に説明する。
なお、メッセージの認証日時の証明に必要なデータは、管理サーバーに保存されているが、必要に応じて、ユーザー側でも保存しておくことが望ましい(S8)。すなわち、後述の管理サーバー内のデータベースのメッセージ管理テーブル62に保存される当該メッセージに対応するエントリの情報を保存しておく。更に、利用可能になった時点で、当該メッセージに関連するハッシュ値のセット(照合用データ)や、新聞広告の画像データを、後のほうの新聞広告が行われた際に、リンク情報として管理サーバーからダウンロードしておく。これによって、管理サーバーとは独立にメッセージの認証日時の証明を行うことが出来る。
<サイバーネームによる認証2> ユーティリティソフトと管理サーバーの動作をもう少し簡潔なものにする実装も可能である。この実装においては、掲示板サイトの投稿ページは、一般的なブラウザで開くようにする。すなわち、図5の右上に示したように、普段利用しているブラウザで投稿ページが開かれている。ここで投稿を行いたい場合には、ユーティリティソフトで署名認証の画面を開く(図5の左上)。この署名認証画面では、メッセージを書きこむエディットボックスとパスワード入力ボックスが表示されている。
ユーザーは、このエディットボックスに投稿したいメッセージを書き込んで、パスワードを入力し、署名実行のボタンを押す。すると、ユーティリティソフトは、インターネット上のタイムサーバーから現在時刻を取得して、サイバーネームと共にメッセージに付加して、署名用メッセージとする。この署名用メッセージに、署名を行って、管理サーバーに認証要求を送信する(S1)。
認証要求を受けた管理サーバーは、受信したユーザー署名を検証する(S2)。検証に失敗すれば、その旨、ユーザーへ通知して処理を終了する。検証に成功すれば、メッセージに、シリアルナンバーを割り振り、後述の格付けとシールを挿入して認証メッセージを作成し、これをユーティリティソフトへ返し(S3)、認証メッセージの登録を行う(S4)。すなわち、ユーティリティソフトと管理サーバーとのやり取りは一度だけで済む。
ユーティリティソフトは、この認証メッセージをクリップボードへ格納し、「クリップボードに認証メッセージがあります。投稿先に貼り付けて利用してください」といった表示を行う。ユーザーは、クリップボードから投稿先へ認証メッセージを貼り付けてから、投稿を行う。やはり、ユーティリティソフト側で、必要に応じて、認証メッセージや認証日時の証明に必要なデータの保存を行っておく。
この例では、ユーティリティソフトにブラウザ機能は不要となるが、ユーザーの手間は若干増える。また、一般的なブラウザから投稿先のサイト情報(URL)を正確に取得できないことも考えられるので、場合によっては、このサイト情報は参考情報といった扱いになる。更にこの例では、署名用メッセージに格付けは含まれていない。これは、管理サーバーとの通信の節約になる。
<シール> 管理サーバーは、上記ユーザー署名を受信し検証すると、このユーザー署名のハッシュ値を算出して、その最後の24ビットをBase64でエンコードすることで4文字のシール(Seal)を生成する。ここでのハッシュ関数としては、SHA−1などを用いれば良い。そして、認証日時(現在日時)の後にこのシールを付加する。
シールも近似的に24ビットの乱数と考えられるので、ユーザー署名の一つのハッシュ値と言える。ユーザー署名と同じビット長を持ち、且つ上記24ビットのハッシュ値と同じハッシュ値を生成するような、別のデータを探すことは困難ではない。しかし、そのデータをユーザー署名とみなして、検証を行った場合に、検証に成功するようなハッシュ値の原像となるような認証メッセージを算出することは困難である。
従って、シールを用いれば、各ユーザーは、或る投稿を自分のものである事も、自分のものでない事も管理サーバーとは独立に証明できる。自分のものである事は、メッセージへの署名を作成して、その署名がシールと対応していることを示せば良い。また、自分のものでない事は、メッセージへの署名を作成して、その署名がシールと対応していないことを示せば良い。サイバーネームと公開鍵との対応は、リストのファイルと新聞での公表情報により証明できる。
<メッセージの管理> 図6に示すとおり、管理サーバー内のデータベースには、サイバーネームとユーザー公開鍵を関連付けるサイバーネーム管理テーブル61と、全ての認証メッセージを時系列で管理するメッセージ管理テーブル62と、公表リンク情報のテーブル63が設けられている。
サイバーネーム管理テーブル61の各エントリーには、サイバーネーム(CyN)と、ユーザー公開鍵(Kup)と、ユーザーの信頼性の目安を示す後述のポイント数(Points)と、ランキング情報(Ranking)と、登録日(Registration)と、有効期限(Expiration)と、オプションデータ(Optional Data)と、公表日(Pub Date)、確認ハッシュ(ID Hash)を格納するフィールドが含まれている。
上記サイバーネーム管理テーブル61では、サイバーネームとユーザー公開鍵とを関連付けることが最も重要となっている。なお、ポイント数は、ユーザーの信頼性の目安を示すものであり、ランキング情報は、ポイント数に基づくユーザーのランキングを示すものであり、オプションデータは、サイバーネームの所有者が実名による本人確認を行う為などに用いるものであり、確認ハッシュはサイバーネームの匿名による本人確認を簡易的かつ繰り返し行う為に用いるものである。これらのフィールドの機能や利用方法は、後に詳細に説明する。
メッセージ管理テーブル62の各エントリーは、各認証メッセージが作成される際に、時系列に割り当てられた連続番号であるシリアルナンバー(Serial No.)と、保存されている認証メッセージへのポインタ(pMsg)と、当該認証メッセージのハッシュ値h(Msg)と、署名用メッセージへのユーザー署名SigUと、当該認証メッセージの認証日時(Date)と、サイバーネームCyNが格納されている。
ここで、署名用メッセージとは、メッセージ本文に、サイバーネームと、格付けと、認証日時を加えたものである。上記の通り、この署名用メッセージに対してユーザーが行った署名が、ユーザー署名SigUである。また、上記の通り、ここでの認証メッセージとは、署名用メッセージに対して、シールと、シリアルナンバーを含むURLを加えたものである。ただし、上記<サイバーネームによる認証2>で説明した実装においては、格付けの情報は、署名用メッセージには含まれておらず、認証メッセージを構成する際に挿入される。
なお、この例では、ユーザーから送られてきた投稿ページのURLのエントリーURL1も含まれている。更に、後述の通り、実際に認証メッセージが掲載されているページのURLのエントリーURL2と、その掲載ページの管理サーバー内キャッシュへのポインタpCacheも含まれている。これらのURL1、2は後述の発言リストで使用する。
シリアルナンバーは、全てのメッセージを時系列に並べて付けた連続番号である。これによってメッセージの認証日時の前後関係が特定できる。後述の通り、ここでは、シリアルナンバーを時系列IDとしたリンク情報の代表値が、上記リストファイルのハッシュ値と同時に、新聞などの刊行物に公表される(図2)。
公表リンク情報のテーブル63は、刊行物で公表されたシリアルナンバー、その刊行物の日付(Pub Date)、リンク情報、公表された広告イメージの画像データ(p_Image)が保存されている。誰でも管理サーバーへアクセスして、シリアルナンバーを指定してリンク情報を要求すれば、そのシリアルナンバーに関連するデータ、すなわち、そのシリアルナンバーの前後のテーブル63のエントリおよびそのシリアルナンバー間のハッシュ値をダウンロードすることができる。
公表リンク情報テーブル63の日付(Pub Date)は、サイバーネーム管理テーブル61の公表日(Pub Date)と同じものである。すなわち、サイバーネーム管理テーブル61では、公表日(Pub Date)は、そのサイバーネームを含むリストファイルのハッシュ値を公表した刊行物(新聞)の日付を示している。なので、複数のサイバーネームが、同一の公表日を共有するが、公表リンク情報テーブル63の各エントリは、異なる公表日(Pub Date)を持っている。なので、aZ38_Nuagesの公開鍵を公表情報から確認する場合には、サイバーネーム管理テーブル61から、aZ38_Nuagesの公表日(Pub Date)を得て、次に、公表リンク情報テーブル63からその公表日(Pub Date)に対応する画像データ(p_Image)を取得する。この画像データに含まれるaZ38_Nuagesの公開鍵を確認すれば良い。
例えば、シリアルナンバー"003F4959"の場合には、シリアルナンバー"003F4238"の刊行物の日付、リンク情報、公表された広告イメージの画像データと、シリアルナンバー"003F5011"の刊行物の日付、リンク情報、公表された広告イメージの画像データと、シリアルナンバー"003F4239"から"003F5011"までの認証メッセージのハッシュ値を含んだファイルHash_003F4239_003F5011.list をダウンロードすることができる。
この例では、2011/01/03の刊行物に公表されるリンク情報は、2011/01/01の最後の認証メッセージのハッシュ値から得られるリンク情報である。すなわち、2011/01/01の最後の認証メッセージのハッシュ値から得られるリンク情報の公表を刊行物の出版者へ依頼するのは2011/01/02であり、公表は次の2011/01/03の刊行物で行われる。
上記のとおり、管理サーバーは、ユーザー署名を検証し、メッセージにシリアルナンバーを割り当てる。なので、メッセージに付加されたシリアルナンバーは、認証済みであることを示す認証データとなっている。
また、誰でも管理サーバーへアクセスして、上記データベースのその他の情報を取得できる。例えば、サイバーネームを特定して、サイバーネーム管理テーブル61の該当エントリーの全ての情報を取得できる。また、シリアルナンバーを指定して、メッセージ管理テーブル62の該当エントリーの全ての情報を取得できる。
例えば、aZ38_Nuagesの公開鍵を公表情報から確認したいとする。その場合には、先ず、サイバーネーム管理テーブル61から、aZ38_Nuagesの公表日(Pub Date)を参照して、その公開鍵が含まれるべきリストファイルとの整合性を確認する。次に、その公表日の直後の公表データに掲載されているハッシュ値と、リストファイルのハッシュ値が一致しているかを確認する。これにより、aZ38_Nuagesの公開鍵が正しいものかどうかを確認できる。
<日時認証> 電子データに対して時刻認証を行う為の手段として、一般にタイムスタンプが利用されている。このタイムスタンプは、電子公証や電子署名法でも使用されており、e-文書法で電子化が許可された文書の中にも、一部省令でタイムスタンプの利用が義務付けられているものがある。タイムスタンプの実装方法としてよく利用されているのが、リンキング・プロトコルである。このリンキング・プロトコルは、電子署名の信頼性に依存せずに長期にわたって認証日時における存在証明と非改竄証明を可能とするものである。
以下、図7を参照して、本実施例による時刻認証の方法を説明する。シリアルナンバーをiとした場合、対応するリンク情報L(i)とその前後のリンク情報L(i-1)、L(i+1)は、認証メッセージMsg(i)と認証メッセージMsg(i+1)の前後関係を特定する情報である。
すなわち、リンク情報L(i)は、リンク情報L(i-1)と認証メッセージMsg(i)から算出された情報である。ここでは、リニアリンキング・プロトコルを用いる。すなわち、h()をハッシュ関数として、リンク情報L(i)は、L(i)=h(L(i-1), i, h(Msg(i)))によって算出される数値である。すなわち、リンク情報によって、認証メッセージのチェーンが形成される。
ハッシュ関数の特性から、リンク情報L(i-1)と認証メッセージMsg(i)は共に、リンク情報L(i)よりも前の情報である。同様に、リンク情報L(i)と認証メッセージMsg(i+1)は、リンク情報L(i+1)よりも前の情報である。
なので、リンク情報L(i-1)、L(i)、L(i+1)が、認証メッセージMsg(i)、Msg(i+1)と整合していれば、認証メッセージMsg(i)の認証日時Date(i)は、認証メッセージMsg(i+1)の認証日時Date(i+1)よりも前でなければならない。もし、Date(i)> Date(i+1)ならば、少なくとも一方は正しくない。
図8を参照して、更に説明する。ここで、リンク情報L(j)とリンク情報L(n)は、新聞などの刊行物に公表された代表値である。それらの間の認証メッセージが全て分かれば、j<k<nとして常にDate(j)> Date(k)> Date(n)であることが確認できる。もし、認証メッセージMsg(k)の認証日時Date(k)が正しいことが確実であれば、j<m<k<nとしてDate(j)> Date(m)> Date(k)であることが確実となる。
このリニアリンキング・プロトコルは、一般的なタイムスタンプ・サービスで用いられるタイムスタンプ・プロトコルの一つであるが、この実施例では、通常のタイムスタンプ・サービスよりもシステムとしての信頼性が高くなっている。
通常のタイムスタンプ・サービスの場合、事実上の乱数であるハッシュ値が特定の日時に存在したという証明をするだけである。情報自体はユーザーのみが所有して、一般には公開されない。また、タイムスタンプ・サービス側は途中のハッシュ値を公開するのみで、情報の内容には関知しない。
また、一週間間隔で代表値を刊行物に公開する場合、一週間という期間内の何処に本当の認証日時があるかについては、リニアリンキング・プロトコル自体は保証しない。確実なのは、タイムスタンプ間の順序関係のみである。認証日時そのものは、タイムスタンプ・サービス提供サイトの信頼性に依存する。
上記の通り、本実施例でも、シリアルナンバーを時系列IDとしたリンク情報の代表値が、上記リストファイルのハッシュ値と同時に、新聞などの刊行物に公表される(図2)。しかしながら、ここでは認証メッセージMsg(i)は、管理サーバーに保存管理され、また不特定多数のサイトに掲載され公開される。
認証メッセージMsg(i)が公開されるということは、そのハッシュ値も事実上公開されるということになる。このハッシュ値は、公開リンク情報を繋ぐ照合用データとなっている。
本実施例の場合には、管理サーバーの付与した認証日時に加えて、不特定多数のサイトにも投稿日時と共に認証メッセージが掲載され、そのハッシュ値(照合用データ)と共に公開される。この多数の第三者の公開データ(特に投稿日時)の分だけ、認証日の正しさに対する蓋然性が高くなる。仮に、隣接する代表値の公表日の間に、一つの信頼できるサイトで公開された認証メッセージがあり、そのハッシュ値および投稿日時がリンクチェーンに矛盾なく収まる値であれば、そのリンクチェーンの認証日時の信頼性は、その信頼できるサイトでの投稿日時によって補強されることになる。
従って、管理サーバー側からは、隣接する代表値の公表日の間の認証メッセージのハッシュ値と掲載サイトのURLのリストがダウンロード可能に公開される。また、図2のような公表情報の画像データと、刊行物の書誌事項も公開される。希望するユーザーは、このハッシュ値のリストと公表情報のデータを保存しておけば、認証メッセージの投稿日に関する客観的な証拠データとすることができる。
なお、図4のS8に示されているように、ユーザーは、自分の各々の発言に関して、必要な2つの代表値Link-p、Link-nと、対応するシリアルナンバーSN-p、SN-nと、発行日Pub-p、Pub-nを保存しておく。また、必要な2つの代表値Link-p、Link-nの間のハッシュ値のセット(照合用データ)や、公表情報の画像データも保存しておく。これにより、管理サーバーとは独立にメッセージの認証日時の証明を行うことが出来る。
<リンク情報の効果> 認証日時の信頼性に関して、リンク情報がどのような関連を持っているかについて更に詳しく説明する。図9に、サイバーネーム、ユーザー署名、リンク情報、日時情報(管理サーバー付与)および日時情報(各サイト付与)が時系列に並んでいる様子を示す。これらは全て投稿先のサイトで公開される情報である。又、管理サーバーにおいても公開されているので、リンクを辿ることは容易にできる。リンク情報は、投稿先のサイトでは直接は公開されないが、認証メッセージのハッシュ値を用いて、公表されている代表値から算出できる。
図10に、日時情報(メッセージ内)の信頼性が、他の情報とどのように関連しているかを示す。ただし、ハッシュ関数の性質から、リンク情報によって各認証メッセージの前後関係は保証されている。ここでは、或るサイトに掲載されたメッセージ内の日時情報Date(i)のメッセージを考える。
当該サイトでは、この日時情報Date(i)とは無関係に付与された日時情報DateS(i)と共に、メッセージの掲載を行う。なので、Date(i)の信頼性とDateS(i)の信頼性は相互に補完する関係にある。すなわち、Date(i)とDateS(i)は一対一に対応している。
リンク情報によって各認証メッセージの前後関係は保証されているので、もしi<jであってDate(i)> Date(j)となっていれば、Date(i)とDate(j)の何れかが誤っていることになる。この場合、日時情報Date()やDateS()のチェーンの中で、不自然な方が誤りである可能性が極めて高い。
例えば、或るメッセージの日時情報を一週間前の日時情報とする不正を行う場合を考える。まず、管理サーバーにアクセス可能な協力者を得るか、侵入して改竄を行う必要がある。ただ単に、そのメッセージの日時情報を一週間前の日時情報とすると、日時情報Date()の一週間のチェーンの中で、それだけ単調増加の規則から外れていることになる。
なので、チェーン自体を再構成する必要がある。一週間のチェーンを全て削除して、それよりも前の日時情報と連結する新たなチェーンを作成する。この場合、削除したチェーンのメッセージが投稿されている各サイトにも侵入して痕跡を消す必要がある。更に、新たなチェーンのメッセージも、各ユーザーが投稿したような痕跡を各サイトに書きこむ必要がある。更には、各ユーザーのパソコンへも侵入して整合性を取る必要性も考えなければならない。このような事は現実的には極めて困難と思われる。
すなわち、管理サーバーと、メッセージを発信した各ユーザーと、メッセージが掲載された各サイトの夫々の信頼性とは、夫々に、各日時情報の信頼性と独立に対応している。そして、日時情報に疑念がある場合、ハッシュ関数の一方向性に基づいて、何れの日時情報が正しくないかは容易に推測できる。また、その責任が何処にあるかも明瞭となっている。従って、意図的でない誤りを別とすれば、不正が行われる可能性は非常に低くなっている。
<リンク情報の埋込み> メッセージにリンク情報を埋込むこともできる。ただし、リンク情報の全てを一つのメッセージに埋込むとメッセージへの負荷が大きくなる。そこで、上記シールをこの目的に利用する。
上記の通り、L(i)=h(L(i-1), i, h(Msg(i)))で、リンク情報L(i)が算出される。このリンク情報を256ビットとし、11の倍数であるiについて、L(i)を下位のビットから24ビット毎に分解し、L(i, j)とする。j=0〜10であり、最後の16ビット目以降は0で埋める。このL(i, j)をbase64でエンコードし、後続のメッセージMsg(i+j)にシールとして埋め込む。このようにすることで、リンク情報も随時公開されるようになる。
<認証の確認> 一般ユーザーのメッセージを掲載している掲示板の例を図11に示す。ブラウザは一般のもので構わない。上記の通り、認証メッセージには、シリアルナンバーを含んだURLが含まれている。このURLのドメイン名は、管理サーバーのものである。管理サーバーが、このURLを受け取ると、シリアルナンバーに対応する管理サーバー内の登録メッセージを含むhtmlファイルを返す。
例えば、図11で、4番目のメッセージ、すなわちサイバーネームaZ38_Nuagesのメッセージに含まれるURLを表示すると、管理サーバーは"003F4959"というシリアルナンバーを受け取ることになる。すると、管理サーバーは、シリアルナンバー"003F4959"のメッセージと、その前後のaZ38_Nuagesのメッセージを含む発言リストを応答として返す。
メッセージの文字列にURLが含まれる場合、サイト側で自動的にそのURLへのリンクに変換する場合が多い。従って、多くの場合は、メッセージの掲載ページでURLをクリックするだけで、発言リストを表示できる。リンクとなっていない場合には、URLを直接ブラウザで開けば良い。
図12に発言リストの具体例を示す。この発言リストでは、その発言者(ここではaZ38_Nuages)の過去の認証メッセージの一覧を参照することが出来る。相当数の発言がある場合なら、ここで絞込み検索などを利用することにより、aZ38_Nuagesというユーザーの人物像をある程度まで知ることができる。各項目の左下には、そのメッセージが掲載されているサイトへのリンク情報が示されている。
このリンク情報は、上記のとおり、認証時にブラウザから取得されたURL1である。なので、認証メッセージの掲載ページへのリンクとなっているとは限らない。しかし、実際の掲載ページを知る上での情報としての利用が可能である。実際の掲載ページのURL2が利用可能であれば、それも表示される。
従って、先ず、掲示板の当該メッセージが、発言リストに表示されているシリアルナンバー"003F4959"のメッセージと同一ならば、管理サーバーにおいて認証を受けているということが確認される。管理サーバーの信頼性に依存しないで、シリアルナンバー"003F4959"のメッセージが、確かにサイバーネームaZ38_Nuagesのユーザーによる投稿であることを確認したい場合には、署名確認ボタンをクリックする。すると、図13のような画面が表示される。この画面には、シリアルナンバー"003F4959"のメッセージに対して行われたユーザー署名と、当該ユーザーの公開鍵と、この公開鍵を掲載したリストファイルをダウンロードする為のボタンと、このリストファイルのハッシュ値を掲載した新聞広告のコピーが表示されている。
従って、先ず新聞広告に含まれるハッシュ値によってリストファイルを検証し、このリストファイルから当該サイバーネームの公開鍵を確認し、この公開鍵によって署名を検証し、更に、格付けとシリアルナンバーを除くメッセージで署名を検証する。これらの手続きによって、該サイバーネームの秘密鍵を所有するユーザーが、このメッセージを作成したということが客観的に確認される。
また、管理サーバーは、認証メッセージの掲載ページの検索を行うようにする。これは、認証メッセージに含まれるサイバーネームや、シリアルナンバーや、単語をサーチタームとして、Webを検索により行う。但し、一般的なサーチエンジンは、インデックスの更新に数日ないし一週間以上かかることがあるので、認証後、しばらくしてから検索を行うようにする。これにより掲載ページのURL2を得るようにする。このURL2は、図12のリストの二番目の発言に示されているように、認証時にブラウザから取得されたURL1の上に表示しておく。従って、2つのURLがある場合には、上のURLをクリックすることで、掲載ページを直接表示することが出来る。
掲載ページを表示する別の方法は、ユーザーの力を借りることである。図12に発言リストにおいて、サーチエンジンで上記サーチタームを検索するURLへのリンクをおく。ユーザーはこのURLをクリックすることで、サーチエンジンによる検索結果を表示するページを表示することが出来る。サーチエンジンへの登録が行われた後なら、このページには当該認証メッセージが含まれている。
例えば、「子ども手当2-3000円増額は、大歓迎です」という認証メッセージなら、サイバーネームであるaZ38_Nuagesも含めて、http://www.websearch.co.jp/web?q=子ども+手当+2−3000円+増額+大歓迎+aZ38_Nuagesへのリンクを表示する。
更に、図13の画面で、認証日時確認ボタンをクリックすれば図14のような画面が表示される。この画面には、シリアルナンバー"003F4959"に近いシリアルナンバーのリンク情報の代表値を公表している新聞広告のコピーが表示されている。一つはシリアルナンバー"003F4959"よりも小さくて最も近いシリアルナンバー"003F4239"に対応するもので、もう一つはシリアルナンバー"003F4959"よりも大きくて最も近いシリアルナンバー"003F5011"に対応するものである。更に、これらの間の照合データ(ハッシュ値)を含むリストファイルをダウンロードする為のボタンも示されている。
このリストファイル(Hash_003F4239_003F5011.list)には、図15に示したような表データが含まれている。この表データでは、シリアルナンバーと、対応する認証メッセージのハッシュ値と、投稿サイトのURLが関連付けられている。従って、シリアルナンバー"003F4239"に対応するリンク情報から、シリアルナンバー"003F5011"に対応するリンク情報まで、途中のリンク情報を算出し、リストファイルの正当性を確認する。次に、リストファイルに記載されているシリアルナンバー"003F4959"のハッシュ値が、当該メッセージのハッシュ値と一致することを確認する。このようにして、認証日時の検証を行うことが可能である。
上記署名の検証や、ハッシュ値の算出や照合は、一般的な処理であり、当業者であれば容易に実装できる。ユーティリティソフトにそのような機能を実装しておけば良い。
なお、過去の認証メッセージから得られる人物像は、そのサイバーネームを所有する生身の人物の人物像そのものという訳ではない。その生身の人物が、インターネットというサイバー空間で例えば、aZ38_Nuagesという別の人物像を自由に形成できる。すなわち、発言の質と量が、そのサイバーネームの価値を決定する。従って、一つのサイバーネームを大事に育てることが重要で、むやみに多重登録を行っても余り利益は無い。この点をより強調する意味で、客観的なランキングを用いる。
図12の例では、ランキングとして144/48237と表示されている。これは、48237個のサイバーネームの中で、第114位であることを示している。サイバーネーム管理テーブル61のランキング・フィールド(Ranking)に格納される情報は、この順位114である。このランキングは、後に説明するポイント数(Points)に基づいて順位付けられる。すなわち、ここでは114番目にポイント数が多いユーザーであることを示している。
また、このランキングに基づいて、ユーザーの格付けが行われる。例えば、サイバーネーム全体の中の上位5%に含まれていれば「AAA」とし、それ以下で上位15%に含まれていれば「AA」とし、更にそれ以下で上位30%に含まれていれば「A」とし、更にそれ以下の場合は「B」とする。この格付けは、認証メッセージに含めて投稿されるので、書き込みを読む際にそのユーザーの格付けが分かって好都合である。
ただし、掲示板などに表示されている認証メッセージの格付けの値は、そのメッセージの書き込みの際の格付けの値である。従って、認証確認の時点での格付けの値とは、一般的に一致しないことになる。
なお、発言リストの各項目の右下には、当該メッセージの内容と類似したメッセージを表示するためのボタンが示されている。このボタンを押すと、図16のような画面が表示される。ここでは、最上段に当該メッセージが表示され、その下に、内容がより近いものから、古いものを優先的に表示される。これにより、類似のテーマに関する他のユーザーの意見を参考することができる。また、当該メッセージの日付より前のものと後のものを色分けして表示する。このようにすることで、オリジナリティ豊かな内容が含まれていた場合、どのユーザーが最初かを知ることができる。
上記のように発言リストと同じウインドウで、類似メッセージを表示するのではなく、既存の検索エンジンを利用しても良い。この場合、当該メッセージから形態素解析などによりサーチタームを切り分け、検索結果が5〜10程度になるようにサーチタームの個数を調節して、既存の検索エンジンによる検索を行うようにする。検索結果は、別のウインドウに検索エンジンのページが表示される。
<ハッシュ値による認証の確認> プラグインの実装などにより、ブラウザ自身に認証確認の機能を持たせることもできる。その場合は、ブラウザ側で、表示されているテキストをスキャンし、認証メッセージの候補を検出する。そして、その認証メッセージの候補のシリアルナンバーを指定し、管理サーバーから該当するハッシュ値を取得する。取得されたハッシュ値と、認証メッセージの候補のハッシュ値を比較することで、認証を確認できる。認証が確認できれば、そのメッセージに認証確認の表示を行うようにする。
このような方法を採用すれば、メッセージのページを開きさえすれば、自動的に認証確認の表示により、ユーザーは何もしなくても認証メッセージであることが分かる。また、発言リストを表示したければ、そのシリアルナンバーを含む上記URLのリンクをクリックすればよい。この場合、もしリンクになっていなければ、ブラウザ側でリンクの為のhtmlタグを挿入する。
また、この場合、認証メッセージでのシリアルナンバーは、URLとしての記述である必要はない。シリアルナンバーのみを記載しておき、ブラウザ側でそのシリアルナンバーにリンクを張るようにすればよい。セキュリティ上の理由などから、メッセージにURLを記載することが出来ないような場合もある。このような場合には、シリアルナンバーのみを記載したような認証メッセージがより好都合である。
<ポイント数> ポイント数(Points)は、サイバーネームを所有するユーザーの信頼性を示す数値である。この実施例では、信頼性はユーザー同士が評価し合う。すなわち、夫々のユーザーが、他のユーザーの情報発信に対して評価を行う。ただし、評価を効果的に行うためのルールを適応しておく必要がある。そのようなルールとしては、次のようなものがある。
他のサイバーネームに対する評価ポイントには、マイナスのポイントも含まれる。例えば、剽窃を繰り返すような場合には、そのサイバーネームのポイントを減少させることが出来る。ユーザーの評価ポイントには、そのユーザーのポイント数に応じた評価回数への制限がある。例えば、ランキングがAAAならば、週に100ポイントまで、AAなら10ポイントまで、Aなら5ポイントまでの評価が可能で、Bの場合は評価を許可しないものとする。
システムを最初に開始した状態では、評価を行えるユーザーは存在しない。従って、情報発信の内容を吟味して、システム側が、評価ポイントを割り振るようにすると、上記システムが機能するようになる。
ユーザー評価のインターフェースとしては、例えば、図16の類似発言の一覧などに、「aZ38_Nuagesさんを評価」というボタンを表示する。このボタンが押されると、図17のようなダイアログが表示される。このダイアログには、本人確認の為のトークンを入力するボックスが含まれている。
ここで、上記ユーティリティソフトを起動させると、図18のようなトークン生成画面が表示される。この実施例で用いるところのトークンとは、サイバーネームと、確認ハッシュの原像と、次の確認ハッシュとが、改行コードなどのセパレータで区切られた文字列である。確認ハッシュとは、図6のサイバーネーム管理テーブル61に格納されている数値であるが、ここではBase64で文字列にエンコードされている。
図18のトークン生成画面においてパスワードを入力して生成ボタンを押すと、ユーティリティソフトは、保存してある暗号化された確認ハッシュの原像を、パスワードを用いて確認ハッシュを復号する。また、次の確認ハッシュの原像として256ビットの乱数を生成する。この乱数をSHA-2で処理して次の確認ハッシュを算出する。次の確認ハッシュの原像はパスワードで暗号化し、現在保存してある暗号化された確認ハッシュの原像を置き換える。但し、現在保存してある暗号化された確認ハッシュの原像も一時的に保持しておく。ここで用いるパスワードは秘密鍵を暗号化したものと同じで良い。
以上のようにして求めた確認ハッシュの原像と次の確認ハッシュを、セパレータで区切って文字列としてサイバーネームの後に連結することで、トークンが得られる。このトークンはクリップボードに置かれるので、図17のトークン生成画面に貼り付けることが出来る。このトークンは、評価フィードバック要求の添付データとして管理サーバーへ送信される。
トークンを受信した管理サーバーは、サイバーネームが評価する権利があることを確認し、サイバーネーム管理テーブル61の確認ハッシュの値が、トークンの確認ハッシュのハッシュと一致を確認する。確認が取れれば、評価をポイントとしてデータベースに反映させる。また、評価を行ったサイバーネームの確認ハッシュを、トークンに含まれる次の確認ハッシュで上書きする。この場合、管理サーバーはハッシュ関数を一度計算するだけで済む。しかし、トークンを使わないで、aZ38_Nuagesを評価する趣旨の定まったフォーマットの日付を含むテキストに、直接署名した署名文を用いても良い。
また、後述のアフィリエイト・プログラムの成果を、信頼性評価に利用することも出来る。つまり、そのユーザーのページにアクセスして何かを購入するユーザーが多いほど信頼性を高くするようする。このように購入と評価を結びつけることで、不正に評価を操作することを防止することが出来る。
<著作権> 一般ユーザーが発信する場合には、コピペの問題が生じることがある。ユニークで見識の高いメッセージの投稿を見て、それをそのままコピーして自分の認証を付けて、あたかも自分独自のメッセージとして別の掲示板へ投稿するというようなことである。このような場合でも、最初のユーザーが自分の署名を付けていれば、いずれが先かが明瞭となる。
コピペを行ったユーザーのサイバーネームの信頼性は低下するであろう。これをポイント数に反映させるには、悪質と判断したユーザーが、上記のような方法で、対象のサイバーネームのポイントを下げることで達成される。
通常のメッセージではなく、自作曲、イラスト、詩作といった創作コンテンツをネットで発表する場合には、認証の日付があれば他人の盗作に対して一定の歯止めがかかる。例えば、映像や音楽の場合には、ハッシュ値をメッセージに付加してから認証を行うようにする。
図19では、「忘却の彼方へ」という自作曲に映像を付けて、MPEG-4のファイルとして発表した例を示している。ここでは、「島取への小旅行の記念に曲を作りました。」というメッセージに、「Oblivescence.mpg: SHA-2 a1yOOj…1jO=」を加えて、サイバーネームと共に認証を行っている。Oblivescence.mpgはビデオのファイル名であり、ハッシュ関数としてSHA-2を用い、Base64でエンコードし「a1yOOj…1jO=」というハッシュ値が得られたことを示している。
例えば、他のユーザーが音楽だけを取り出して、少し変えて自作曲として発表したとする。この場合、先のMPEG-4ファイルを発表した認証日時は、盗作であるか否かについての有力な証拠となり得る。
<Webサイト認証> Webサイトのページは複数のファイルから構成されている。このようなデータに対して認証を行うには、認証を確認する為のページを別途設けることが便利である。例えば、図20に示したようなWebサイトのトップページの場合、認証ページのURL(リンク)を記載しておく。ここでは、個別ファイル認証というボタンに認証ページへのリンクが設定されている。この認証ページは、例えば、図21に示したような内容を含んでいる。
すなわち、この認証ページには、認証を行うデータ(通常はファイル)のURLが列挙されている。そして、これらのURLで指定されるデータのハッシュ値に対して上記のとおり認証を行っている。
例えば、"myhome.ne.jp/member1/content1.htm"というファイルのハッシュ値を計算し、Base64でエンコードしてテキストデータとする。このテキストデータを、通常のメッセージと同様にユーザー署名を付加して、所定のフォーマットにメッセージを組み立てて、サーバーへ認証を依頼する。図21では、このファイルが20061223 19:23に作成され、シリアルナンバー00383093で認証されていることを示している。
この場合、認証メッセージは、次のように組み立てられる。すなわち、図22に示したように、ファイル名、ハッシュ関数、ファイルのハッシュ値、サイバーネーム、格付け(Rating)、認証日時、シール、シリアルナンバーを含むURLを所定のフォーマットに従って組み合わせれば良い。上記の通り、この認証メッセージのハッシュ値によって認証の確認を行うことができる。Webサイトの作成者が認証を得るには、図22からURLを除いたような所定のフォーマットに従って組み立てたメッセージについて、認証を求めれば良い。
Webページは度々更新されることがある。この場合、同じURLに関して、認証日時の異なる複数の認証を得るようにしても良い。図21では、"myhome.ne.jp/member1/content2.htm"に別々の認証日時を持つ2つのエントリが示されている。
<その他の機能> 発言リストなどを介して信頼を得ているユーザーに対して直接メールを送りたい場合もある。それには管理サーバーにメール機能を実装すれば良い。このメール機能は、発言リストのウインドウを介して提供される。例えば、図23に示したように、発言リストのウインドウに設けられたメールタブをクリックすることで利用可能とする。
また、管理サーバーにブログ機能を実装して、これも発言リストのウインドウに設けられたブログタブをクリックすることで利用可能とする。このブログは、サイバーネームで特定されるユーザーの行ったインターネット上のすべての活動とリンクしているという点で、通常のブログとは異なる。
メールの表示を行うには、そのサイバーネームによるログオンが必要となっている。ログオンでの本人確認は確認ハッシュで行ってもよい。メールを送信するには、署名を添付することで、差出人の本人確認を行えるようにすることが望ましい。
<サイバーネームの無効> 各ユーザーは、自分のサイバーネームを無効に出来る。それには、無効の申請を管理サーバーへ署名付きで行えば良い。無効となったサイバーネームと公開鍵の情報も、図2のような新聞広告でハッシュ値が公表されるリストに載せておく。無効にする理由としては、秘密鍵が漏洩してしまった場合などが考えられる。図3では、登録されたサイバーネームのリストの下に無効となったサイバーネームのリストが示されている。その場合、サイバーネーム管理テーブル61の有効期限(Expiration)フィールドを、無効となった日時で上書きする。サイバーネームが無効となった場合、有効であった過去の発言に関しては発言リストで閲覧できるが、その場面で当該サイバーネームが無効であることと、無効の理由と日時が表示される。
また、サイバーネームには有効期限が設定される。格付けがA以上のユーザーの場合には、自動的に有効期限は更新される。有効期限の更新も新規の登録と同様に、新聞による公表が行われる。しかし、格付けがA以下のユーザーでは、一定期間以上サイバーネームの有効利用がない場合、有効期限の更新は行われない。有効期限が更新されると、サイバーネーム管理テーブル61の有効期限(Expiration)フィールドが書き換えられる。
<引用> 他人の文章を、そのまま黙って自分の投稿に利用するというのは、余り行儀の良いものではない。しかし、有用な書き込みの再利用はインターネットの利便性を向上させる。この場合、引用先を明記することで、オリジナルの書き手に配慮することができる。それにはシリアルナンバーの表記で足りる。更にサイバーネームを加えておけば、より敬意を払うことになる。
図24に具体例を示す。ここでは「sn:」の後のシリアルナンバーと「Cbn:」の後のサイバーネームが引用先を示している。プラグインは、認証が成功したメッセージに、引用が含まれていれば、シリアルナンバーの表示に引用先のリンクを設定する。また、引用先サイバーネームの表示にそのユーザーの発言リストへのリンクを設定する。閲覧ユーザーが、引用先や発言リストを参照したい場合には、これらのリンクをクリックすれば良い。上記のとおり、このように引用されて発言リストが表示されれば、ポイントを加算するようにする。
<収益モデル> 図12のような発言リストには「お気に入り」タブが含まれている。このお気に入りを選択すると図25のようなウインドウが表示される。このような発言リストを、ネットワークメディアとして利用することで、収益モデルの設計が可能となる。すなわち、ウインドウでお気に入りのタブを選択すれば、そのサイバーネームを所有するユーザーのお薦めの商品やサービスを知ることができる。このお気に入りの内容は、そのユーザーの信頼性が高ければ有効な広告媒体となり得る。また、アフィリエイト・プログラムを利用することも可能である。その収益をユーザーとシステム提供者が分け合うことで、システム運営に必要な収益が可能となる。
<その他> 刊行物での明証化では、一つのハッシュ値を公表すれば足りる。すなわち、図2のような新聞広告は、図26に示したような88文字にBase64でエンコードされた512ビットのハッシュ値に、提供元の表示のみで十分な機能を果たす。この場合、必要な情報の詳細は、ハッシュ値の原像であるリストファイルに記載しておく。その具体例を図27に示す。ここでは、図2の新聞広告との関係と、リンク情報の代表値が記載されている。
ここでは、複数のリンク情報代表値が記載されている。これにより、リンク情報を複数のチェーンに分割することで、サイバーネームのメッセージの信頼性によって組み込むチェーンを区別することができる。例えば、信頼性の高いメッセージのチェーンは、日付認証の精度が高くなる。一方で、登録直後やランキングの最下位のサイバーネームに関しては、一つのチェーンに纏める。また、全体のメッセージの数が大きくなった場合に、リンク情報を複数のチェーンに分割することで、照合データの量を小さくする効果もある。
上記実施例では、公開鍵や署名を管理するためのサーバーが不可欠であるが、メッセージに直接署名を付加するようにしても良い。この場合、ローカルの署名検証プログラムだけで実装することが可能となる。この例では、以下の機能が署名検証プログラムとして実装される。
ユーザーがメッセージに署名を付加するには、秘密鍵が必要である。従って、鍵生成機能が実装される。鍵生成機能では、秘密鍵と公開鍵がペアで生成される。また、秘密鍵を用いて署名を生成する署名生成機能が実装される。更に、メッセージに付加されている署名を検証する為の署名検証機能も不可欠である。更に、秘密鍵や公開鍵をローカルで管理する機能も実装される。更に、公開鍵をネットワーク等から取得する機能も実装される。
<操作手順> 以下、ユーザーが行う操作を順に説明することで、署名検証プログラムの利用法やインターフェイスの概要を記述する。各処理の詳細については後述する。ここでは楕円曲線暗号の1つであるECDSAを利用する。また、サイバーネームは、ユーザーが任意に選択できるコアネームと、先頭に付けられたドルマーク「$」と、「*」をbase64の文字として「_***」の形式のサフィックスとからなる。
署名検証プログラムが起動すると、最初に暗号化された秘密鍵を含む個人鍵ファイル(後述)がハードディスクに存在するか否かを確認する。簡単な方法としては、署名検証プログラムと同じフォルダの特定のファイル名へのアクセスを行えば良い。例えば、初めての使用などでは個人鍵ファイルは存在しない。存在しない場合には、図29に示したようなダイアログを表示する。勿論、ファイル自体があっても、秘密鍵を含まないようなら、存在しないとみなす。
このダイアログによる鍵生成では、ECDSAのアルゴリズムとして、SECG標準の1つであるsecp160r1をパラメータに固定している。secp160r1の鍵長は160ビットであるが、より長い鍵長は別の詳細設定ダイアログ(図30参照)によって生成できる。なお、ECDSAでは、同じ長さの鍵長でも、複数の異なる暗号方式が利用できる。これらは楕円曲線に名称を付して区別したりするが、ここでは番号nIDで指定する。
また、図29に示したダイアログは、コアネーム入力用のボックスと、パスワード入力用のボックスが含まれている。ユーザーは、好きな名前(文字列)を決めてコアネーム入力用ボックスに入力する。また、パスワードも決めてパスワード入力用ボックス入力する。
その後、ユーザーはOKボタンをクリックする。すると、署名検証プログラムは、秘密鍵と公開鍵を生成して、サフィックス「_qv2」を追加する。また、先頭に文字「$」を追加して、公開鍵に対応する識別名であるサイバーネーム($Suzuki_qv2)を構成する。この「qv2」は、生成された公開鍵をbase64でエンコードし、得られた文字列の3番目の文字から5番目の文字までの3文字である。文字「$」とこのサフィックス導入の意味は後述する。
そして、署名検証プログラムは、インターネット上で同一のサイバーネームが利用されているか否かを検索する。実際には、検索エンジンを用いて、サイバーネームの文字列を検索してヒットしなければ利用されていないと判断する。その具体的な方法は後述する。
もし、文字列がヒットすれば、同一のサイバーネームが利用されている可能性があるので、秘密鍵と公開鍵を再度生成して、サフィックスを変更する。サフィックスの変更は、この文字列検索がヒットしなくなるまで繰り返す。実際には、サフィックスは3文字の乱数なので「$(ユーザー選択コアネーム)_***」という文字列としては、ヒットする可能性は非常に低い。サフィックスを変更した場合には、ユーザーにその旨を通知しておく。
サイバーネームのフォーマットとしては、ユーザーが任意に選択するコアネームに、ランダムな文字列を特殊文字を挟んで連結することで、インターネット上でユニークであるようにできる可能性が高くなる。ここで特殊文字とは、アルファベット、仮名や漢字といった表音文字や表意文字に入らない記号類のことである。
その後、署名検証プログラムは、公開鍵をインターネット上に公開する為のメッセージをクリップボードにコピーして、図31に示したようなダイアログを表示する。メッセージは、公開鍵情報であることを示すキーワード「$Pblkey」に、丸括弧で括った楕円曲線暗号のパラメータの種類を示す番号nIDと、base64でエンコードされた公開鍵と、鍵括弧で括ったサイバーネームとが並んだ文字列を含んでいる。
図31で、「$Pblkey」から鍵括弧で括ったサイバーネームまでが公開鍵情報となっている。ユーザーはこの公開鍵情報を、インターネット上の任意のサイトに公開する(図32参照)。公開するサイトは、SNS, BBS, blogなどで良いが、永続性がない場合には適宜再度公開を行う。また、生成された秘密鍵と公開鍵は、番号nIDおよびサイバーネームと関連付けて、ローカルに保存しておく。ただし、秘密鍵はパスワードで暗号化してからハードディスクの署名検証プログラムと同じフォルダに特定のファイル名で保存する。これが既に述べた個人鍵ファイルである。
ユーザーが署名する手続きは次の通りである。署名には、秘密鍵が必要であるが、ハードディスクに保存されている個人鍵ファイル内では暗号化されているので、そのままでは署名できない。そこで、上記鍵生成の処理の直後は、署名検証プログラムが終了するまでの間、メモリ上の変数として平文の秘密鍵を保持しておく。
また、署名検証プログラムを再度実行した際に、暗号化された秘密鍵のファイルがハードディスクに存在していれば、図33のようなダイアログを表示して、パスワードの入力を促す。ここで入力されたパスワードを用いて秘密鍵を複合し、署名検証プログラムの実行中はメモリ上に保持することで署名をできるようにする。このダイアログでパスワードを入力せずにキャンセルすると、署名の度にパスワードの入力が求められる。
ユーザーは、先ず署名を行いたいメッセージを作成する。例えば、WEBページの入力ボックス、あるいはワープロやエディタなどで「子ども手当2-3000円増額は、大歓迎です。」と打ち込む。その全体をクリップボードにコピーしてから、画面に表示してあるアイコンをクリックする。この実施例では、アイコンはタスクトレイに表示されている署名検証プログラムのペンマークのアイコンである(図34)。
クリックによるイベントを受けると署名検証プログラムは、クリップボード内のデータを確認して、署名が付加されていないメッセージならば、その署名を作成する。そして、サイバーネームと共にクリップボードにコピーする(図35)。ユーザーがクリップボードの内容をメッセージの末尾に貼り付けると署名付きメッセージとなる。この署名付きメッセージを図36のような入力ボックスに貼り付けて、利用できる。
ここで、サイバーネームと署名本体はコロンで区切られている。もしも、画面に表示してあるアイコンをクリックした際に、クリップボードのテキストが署名付きのメッセージであれば新たに署名を生成するのではなく、付けられている署名の検証を行い、その結果を表示する。具体的には、テキストの末尾に、サイバーネーム+コロン+(base64の所定長の文字列)があれば、署名検証プログラムは署名付きのメッセージと解釈する。
従って、ユーザーが、ウェブページを閲覧していて、署名付きのメッセージの書き手を確認(署名検証)したいと思えば、署名生成の時と同様に、クリップボードにコピーしてから、画面に表示してあるアイコンをクリックする。すると、署名の検証結果が表示される。もし、検証に成功したら、検索ボタンで同じ署名(人物)の情報を検索できる(図37)。なお、検証に必要な公開鍵の取得方法は後述する。
<鍵生成> ECDSAでは秘密鍵は一定ビットの乱数で表される。上記の例では鍵長160ビットなので、20バイトの数値となる。一方、公開鍵は楕円曲線上の点であり、40バイトの数値となる。この実施例では圧縮表現を用いているので21バイトの数値となる。これをBASE64で変換すると、秘密鍵は27文字、公開鍵は28文字の文字列となる。BASE64では、バイト表現との整合性から文字数を4の倍数とすることになっているので、秘密鍵では'='でパディングを行い28文字の文字列となる。なお、署名は鍵長の数値のペアで表現され、40バイトの数値となる。従って、BASE64では54文字に'=='でパディングを行い56文字となる。しかし、ここではできるだけ署名長を短くする為に、冗長なパディングは省略するものとする。なので、鍵長160ビットでは、署名長は54文字となる。
署名検証プログラムではBASE64の文字列を直接メッセージへの署名として、発信情報にそのまま加える。鍵はBASE64の文字列として生成され、そのまま公開されたり、保存されたりする。全てただの文字列情報であり、視覚的に分かりやすくなっている。但し、秘密鍵は、パスワードで暗号化した文字列として保存するようにする。
<署名> 署名のアルゴリズムは次の通りである。先ず、署名すべきメッセージを取得する。署名検証プログラムでは、クリップボード経由でメッセージの文字列を取得する。次に、サイバーネームの末尾にコロンを付けて、メッセージの文字列に連結する。次に、連結したこのメッセージ文字列から、空白文字(全角、半角、改行、タブを含む)を除去する。次に、メッセージ文字列の文字コードを、Unicodeに変換する。利用する文字符号化スキームはUTF-8である。そして得られた文字列データのハッシュ値(SHA256)を計算する。
このハッシュ値から得た鍵長のダイジェストのECDSA署名値を算出する。その際に秘密鍵(番号nIDを含む)が用いられる。なお、ECDSAではセキュリティ上の理由から毎回異なる乱数を用いる。この為、同一ダイジェストであっても、常に異なる署名値が生成される。最後に、署名値をBASE64でエンコードして、署名文字列を得る。この署名文字列をサイバーネームの後のコロンに連結し、全体として署名付きメッセージとなる。
空白文字の除去は、内容としては同一のメッセージに付加された署名の検証を失敗しないようにする為のものである。英文の場合は、単語を連結してから処理することになる。但し、空白文字の除去は、ハッシュ値算出の直前に行うものであり、サイバーネームとメッセージ本文との区切りに改行等を利用することは可能である。また、Unicode(UTF-8)への変換は、文字コードによって署名文字列が変化しないようにする為のものである。もしも、メッセージの文字コードがUnicode(UTF-8)なら、変換は不要となる。
<検証> 検証のアルゴリズムは、署名のアルゴリズムを逆にしたものである。先ず、検証すべきメッセージを取得する。次に、メッセージの末尾からBASE64の文字列を取得する。つまり、末尾からBASE64以外の文字を検索して署名文字列の先頭を特定する。但し整形のために入れられた空白文字(全角、半角、改行、タブを含む)は無視する。整形のために入れられた空白文字であるか否かは、改行の数や空白が連続しているか等で判断する。ここではコロンの前までが署名文字列となる。もし文字列の長さがサポート外なら署名付きメッセージではないと判断する。
次に、署名文字列を除いたメッセージの末尾から、サイバーネームを取得する。最初に末尾から上記空白文字やコロン以外を検索して、サイバーネームを構成する文字列の末尾を特定する。続いて、この末尾からサイバーネームとメッセージ本体との区切り文字を検索してサイバーネーム文字列の先頭を特定する。上記形式のサイバーネームでは、ドルマーク「$」が区切り文字となる。更に、アンダーバー(_)の前後の文字列が適切かどうかも確認される。サイバーネームが確認されなければ、署名付きメッセージではないと判断する。このようにすることで、署名を精度よく特定することが可能となる。
次に、サイバーネームから公開鍵(番号nIDを含む)を取得する。この手順は後述する。公開鍵の取得に失敗すれば、その旨の表示を行い処理を終了する。ユーザーは、自ら検索したり、所有者から直接受け取るなどの、何らかの方法によって公開鍵を入手することもできる。
ここまで問題なく署名の分離や、サイバーネームの特定、公開鍵(番号nIDを含む)の取得が行われたら、それらを用いて検証の処理を行う。先ず、メッセージ本体とサイバーネームとコロンを含めた文字列、すなわち、検証すべきメッセージの先頭から、サイバーネームの後のコロン迄の文字列から、空白文字(全角、半角、改行、タブを含む)を除去する。次に、メッセージ文字列の文字コードを、Unicodeに変換する。利用する文字符号化スキームはUTF-8である。そして得られた文字列データのハッシュ値(SHA256)を計算する。このハッシュ値から得た鍵長のダイジェストを得る。
最後に、このダイジェストが、署名の際に算出されたものと同一であることを、ECDSAのよく知られたアルゴリズムによって確認する。その際に公開鍵(番号nIDを含む)が用いられる。確認出来れば、検証に成功したことになる。確認出来なければ、署名は正しくないことになる。
<公開鍵取得> 上記の通り、署名検証プログラムの出力する公開鍵情報は、キーワード「$Pblkey」に、丸括弧で括った楕円曲線暗号のパラメータの種類を示す番号nIDと、base64でエンコードされた公開鍵と、鍵括弧で括ったサイバーネームとが並んだ文字列である。多くの検索エンジンでは、「"」(ストレートコーテーションマーク)で括ることで、字句通りの文字列にのみヒットするようにできる。例えば、"$Pblkey"とすることで、「Pblkey」にはヒットせず「$Pblkey」にのみヒットするようになる。現時点でこの技術関連以外で、キーワード「$Pblkey」でヒットするページは存在せず、このキーワードを検索タームに加えることで、公開鍵情報を効果的に検索することが可能である。
次に、サイバーネームが重要である。やはりサイバーネーム全体を「"」で括って検索タームとすることで、他の文字列との衝突を回避する。先ず、「$(ユーザー選択コアネーム)_***」の「***」は、base64でエンコードされた公開鍵の特定の位置の文字をそのまま利用する。例えば、公開鍵が「AmohjFfOA7RwSPFoQR/bOsjDMNcD」であり、3番目の文字から5番目の文字までの3文字を取ると決めてある場合、サフィックスは「_ohj」となる。どの位置の文字でも利用できるが、ECDSAでは、圧縮された公開鍵の最初の文字には偏りがあるので避けたほうが良い。
3文字を乱数と考えれば、その組み合わせは262,144通りある。実際には、完全な乱数ではないが、後続の任意の文字列との組み合わせで考えると偶然に一致する可能性は極めて低くなる。また、サイバーネームの決定にあたっては、インターネット上でユニークであるか否かを確認するので、CyberNameは常にユニークと考えられる。ここでも先頭のドルマーク($)に3文字の擬似的な乱数にアンダーバー(_)を付けたサフィックスをサイバーネームを連結し、全体を「"」で括って検索タームとするが、そのことがユニークという点で有効に機能する。
にもかかわらず、誰かが自分と同一のサフィックス付きCyberNameを使っている場合、それは偶然又は過誤とは考えにくく、なりすましと判断される。ただ単に、同一のCyberNameを使った場合、公開鍵との整合性が取れないので、なりすましの公開鍵がどちらであるかは容易に判別される。署名検証プログラムでは、検証を行う際に、公開鍵とサフィックスとの整合性をチェックする。もしも、整合性が無ければ、その公開鍵が不正な目的で生成された可能性が高いことを警告する。
若干の技術的な知識があれば、それなりの手間がかかるものの、サフィックスも含めて完全に同一のCyberNameに対して整合性のとれた異なる公開鍵を生成することも可能ではある。しかし、なりすましの署名では、本家の公開鍵で検証できないので、なりすましを行う意味は非常に小さい。
署名検証プログラムでは、署名付きメッセージの検証を行う場合、サイバーネームを「"」で括って第1の検索タームとし、更に"$Pblkey"を第2の検索タームとして、AND検索を行う。これにより、公開鍵情報が実際に公開されていれば、ほぼユニークにヒットする。
<ファイルへの署名> ファイルへの署名は次のような手順で行うことができる。先ず、ファイルの説明文を作成する。例えば、「電子署名ソフトを開発しました。ハッシュ値は以下の通りです。皆さん使ってみてください」といった文章を作成する。そして、当該ファイルのハッシュ値をBase64でエンコードした文字列を説明文の中に入れて、上記の通りの方法で、説明文に署名を付ける。ここではハッシュ値はSHA256とする。
ハッシュ値の文字列の算出は、例えば、次のような手順で行うことができる。先ず、そのファイルへのリンクをコピーする。Windows(登録商標)であれば、ファイルエクスプローラーで当該ファイルを選択してコピーすれば良い。次に、画面に表示してあるアイコンをクリックする。これでハッシュ値の文字列がクリップボードに格納されるので(図38)、説明文の中に貼り付ければよい。ここでクリップボードに格納されるハッシュ値の文字列は、キーワード「SHA256:」の後に連結される。例えば、説明文は、図39のようなものになる。
このようなメッセージの検証は、次のように行われる。既に述べた手順に従って、署名を含めたメッセージ全体をクリップボードにコピーする。そして、画面に表示してあるアイコンをクリックすると、それに応答して署名検証プログラムは署名の検証を行い結果を表示する。ここで、検証に成功したメッセージ本文にキーワード「SHA256:」とそのハッシュ値の文字列が検出されていれば、画面の表示は図40に示したようなものになる。
この画面表示は、ユーザーからのファイル選択を受け付けるようなものである。この例では、ユーザーがドラッグ・アンド・ドロップ操作でファイル選択を行うと、署名検証プログラムはドロップされたとファイルのハッシュ値を算出しメッセージ本文に含まれているハッシュ値と比較する。一致していれば図41に示したような画面を表示し、一致していなければ図42に示したような画面を表示して、ドロップされたファイルが署名されたものかどうかを通知する。
従って、署名検証プログラムでは、アイコンがクリックされるとクリップボードの中身を調べる。ファイルへのリンクであれば、ファイルのハッシュ値の文字列を算出してクリップボードに格納し、その旨の表示を行う。もし、署名が付加されているテキストであれば検証を行い結果を表示する。その際、メッセージにハッシュ値の文字列が含まれていれば、上記の通りローカルのファイルの検証を可能とする。もし、署名が付加されていないテキストであれば、既に述べた手順に従って署名を生成してクリップボードに格納し、その旨の表示を行う。
<署名の効果> ここで付加される署名には対応する公開鍵に対して電子証明書が存在しない為、このままでは何かが保証されるというものではない。同じ公開鍵で同値関係が確立された署名は、対応するメッセージ内容によって互いに保証しあう。例えば、優良な情報や魅力的な内容の発信を繰り返す署名は、内容的に信頼出来ると判断される。新たな情報に、このような署名が付加されていれば、それは信頼出来る一つの目安となり得る。逆に、情報発信力という意味で、その署名の価値は高いと言える。
署名検証プログラムでは、署名の信頼性を評価する為に、署名の検証結果を表示ダイアログ(図37)に検索ボタンを設けている。このボタンを押せば、同一サイバーネームの検索が行われる。上記の通り、サイバーネームはユニークと考えられるので、検索結果には同じ署名の発信情報が列挙されることになる。これは、署名付きメッセージの信頼性を評価する上で一つの有効な材料となり得る。
しかし、なりすまし署名が付加された発信情報も含まれている可能性もあるので、署名検証プログラムでは、検索結果から個々の署名を検証して検証に失敗する情報があれば表示を変えるようにしている(実際には表示フォントを赤にしている)。検索結果のリストから検証に失敗する情報をすべて削除することもできるが、当初の署名自体がなりすましということもあるので、表示を変えるようにした。
ここでの署名と公開鍵との関係は、従前とは逆転しているとも言える。すなわち、これまではメッセージに署名を付けて、メッセージの出自を署名が証明し、この署名の出自を公開鍵が証明し、公開鍵の出自を電子証明書が証明し、この電子証明書の出自を認証局が証明するという手順となっている。従って、認証局から電子証明書を発行してもらうには、面倒な手続きと一定の費用が必要となる。
これに対して、この発明では何も要求されず、ただ署名を行うだけである。メッセージの価値が、署名の価値を証明し、公開鍵の価値を署名が証明するといったようなものである。この関係を図43に示す。もし、メッセージの質が低いということであれば、公開鍵の価値を貶めることになる。従って、良質のメッセージが増加するというメリットも期待できる。