JPWO2013008778A1 - 署名検証プログラム - Google Patents

Abstract

個々のユーザーにユニークな識別名を与え、その識別名によってインターネット上で発信された情報に対して、その出自を明確にして信頼性の評価基準を与えるため、識別名を検索タームとして、インターネット上に公開された情報から対応する公開鍵を取得し、上記公開鍵によって、上記識別名を含むテキスト情報に付加された署名を検証し、上記テキスト情報の出自が、上記公開鍵および上記識別名に帰着されるか否かを確認することによって、上記公開鍵および上記識別名によって、上記テキスト情報の同値関係を確立する。

Description

本発明は、インターネットにおいて、ユーザーにユニークな識別名を割り当て、登録管理する方法およびシステムに関するものである。

現在、世界のインターネット・ユーザー数は２０億人を超え、爆発的な勢いで増加している。その利用者の大部分が何らかの形でツイッターやブログ、ＳＮＳ、掲示板といったコミュニティサービスを利用している。コミュニティサービスでは、自由に情報を発信したり、意見を述べ合うことが可能となっている（特許文献１）。また、リアルタイム検索の実現により、現在進行中の出来事についての有用な情報が得られるようになり、日常生活に大きな変化が起こりつつある。

一方で、インターネットでは、個人情報の漏洩は深刻な被害に結びつく可能性があるため、大半の利用は匿名で行われている。サービス提供側へは個人情報を開示しても、ユーザー同士は、互いに実名などは明かさないことが多い。一方で、匿名によるコミュニケーションには信用問題があるので、実名を前提としたサービスも一定の範囲では有効に機能している。

特開２０１０−１４６４５２号公報

プライバシーの観点から匿名の利用は必要と言えるが、一方で、ネットワーク上での発言は、「こういう意見もある」といった、その場限りの点の集まりとなってしまう。「誰」が言っているのかという情報は、その意見の有用性の評価にとって重要であるし、「こういう意見を言っている人は、他にどんなことを言っているのか」といった情報もまた信頼性を評価する参考として、非常に有用である。また、バラバラの匿名個人が発信する情報には責任が伴わず、信頼性の欠ける情報が気軽に発信されてしまうこともある。

ツイッターなどでは、ユーザー名によって、ある程度までは匿名個人を識別できる。また、著名人では、本人確認済みのアカウントとすることで、なりすましや紛らわしいユーザー名による混乱を避けることが出来る。しかしながら、ツイッター以外にも、他のコミュニティサービスや、ネットオークションや、通販サイトのユーザーレビュー、新聞サイトの投稿欄や、Q&Aへの書き込み、ＳＮＳやブログなど、一般個人からの情報発信の場所は数多くある。これらを含めたインターネット上で、匿名個人を統一的に識別し確実に検証する手段は存在しない。

一般に或る情報が有用なものかどうかは、その情報の提供ソースが重要な手がかりとなる。もし、有力な新聞サイトの社説であれば、読んでみる価値があると考える。また、信頼できる書き手であれば、時間を使って読もうと考える。特に、地震や噴火などの災害において、しばしば流言飛語や風評被害などが問題となる。緊急性を要する事態においては、情報の信憑性についての一定の手掛かりがあると被害が抑制されることがある。

大手サイト、例えば新聞社のサイトならば、一定レベルの信頼性は期待できる。しかし、次の３つの点では一般ユーザーによる情報発信の方が優位にある。一つは、情報の細かさである。電気製品に関して言えば、或る特定機種の或る特定操作に関わる不具合といったものや、或る特定地域の或る特定分野に関わる情報といったものは、個人レベルの情報に頼らざるを得ないことが多い。もう一つは、情報の速さである。現在進行形の事象については、その場に居合わせた一般ユーザーの情報が最も早い。更に、情報の量という点でも、圧倒的な数の一般ユーザーが優位にある。

また、情報は獲得するだけでなく、その内容を正しく解釈し信憑性を判断する必要がある。ところが、日々発信される情報は、個人の許容量をはるかに超えている。各自の得意分野における個人レベルの分業といった作業が不可欠と思われる。ところが誤った情報または有害な情報が多く混じっていると、良質の正しい情報を選別することは困難である。以下に、不必要な情報を選別するかが、集合知のメリットを最大限に活かすには、如何にして不必要な情報を選別するかがポイントとなる。

一方で、或る人物が新聞サイトの投稿欄へ投稿する場合、その人物は、一定の労力と時間を費やす。そして、その情報が他の人々にとって有用なものならば、その情報には一定の価値が存在する。しかし、その人物が無名の人物であれば、その投稿は単発の情報であり、そのサイトを閲覧した人だけが参照するその時だけの情報となっている。

投稿した人物が無名であれば、その人物が得るものは、投稿したという自己満足だけにとどまってしまう。すなわち、その投稿はその場限りのものであり、一般にはその人物の信頼性を向上させることはない。なので、労力と時間を費すメリットは小さく、時間をかけて良質な情報を提供しようとする意欲は出てこない。

これに対して実名により投稿を行うという方法もある。実際、実名投稿を義務付けているＳＮＳも存在する。しかしながら、実名の公表にはプライバシーの侵害など大きなリスクが伴う。なので、実名ＳＮＳの環境はかなり閉鎖的なものとならざるを得ない。

又、その実名自体の信頼性についても疑念が残る。実名確認のために電子証明書に求められるような煩雑な手続きを行うことも考えられるが、費用がかかる上に面倒なので一般ユーザーの理解は得られない。更に、実名投稿は特定のＳＮＳに限定されており、インターネットの様々なメディアにおける横の関係は切り離されている。更に、同一実名や類似実名も非常に多いので、勘違いやなりすましの問題もある。

もう一つの課題として、非常にユニークで価値ある投稿を行っても、他人に剽窃されてしまう可能性があるという点がある。特に、エッセイ、映像や音楽といった創作物については、創作証明が出来ないことは、発表や流布を妨げる大きな要因となっている。

また、ＰＫＩは主体の特定に利用できるが、その原理的な有効性にもかかわらず、少なくとも個人レベルでは、主にその一方向についてのみ普及している。すなわち、サービスの提供側といった法人が、公開鍵証明書を持ち、サービスに関する情報に電子署名を行い、それを一般の個人が確認してサービスを利用するといった利用が大部分である。

本来は、個人も電子証明書を持ち、電子署名を行うことで、インターネットの可能性は大きく拡がるはずであるが、そのようは利用は例外的と言って良い。実際、個人が電子証明書を利用する場面というのは、非常に限られている。

この理由は、やはりＰＫＩの導入には煩雑さがある為と思われる。現在では、どうしても必要な場合には、認証局に申し込みを行い、必要な手続きに従って個人の電子証明書を取得する。これには手間と時間だけでなく費用もかかる。また有効期間にも気を配る必要がある。

そして、その電子証明書はそのユーザー個人を特定するものなので、印章と同様にその管理を慎重に行う必要がある。ある意味では、印章よりももっと直接にユーザー個人を特定する機能を有するので、もしも漏洩すれば、悪用される危険性がより高いと言える。更に、個人ユーザーが、実名によってインターネット上で活動する場合、プライバシーに関するリスクが伴う。

従って、本発明の目的は、個人レベルで、自己証明に電子署名を気軽に利用出来る環境を提供することである。

本発明の他の目的は、匿名であっても電子署名を利用出来る環境を提供することである。

本発明の更に他の目的は、個々のユーザーにユニークな識別名を与え、その識別名によってインターネット上に発信された情報に対して、その出自を明確にして信頼性の評価基準を与えることである。

上記課題を解決するために、本発明の識別名管理方法は、識別名を検索タームとして、インターネット上に公開された情報から対応する公開鍵を取得し、上記公開鍵によって、上記識別名を含むテキスト情報に付加された署名を検証し、上記テキスト情報の出自が、上記公開鍵および上記識別名に帰着されるか否かを確認することによって、上記公開鍵および上記識別名によって、上記テキスト情報の同値関係を確立することを特徴とする。

本発明の識別名管理方法によれば、インターネットで情報の発信を行うユーザーは、その識別名において信用を累積させることができる。また、識別名の利用を匿名で行うことで、現実生活とは切り離すことができるので、プライバシーに関するリスクを回避できる。

更に、本発明の識別名管理方法によれば、インターネットに有用な情報を発信することが、直接にユーザーの利益となる為、各ユーザーは積極的に有用な情報の発信を行うようになり、インターネット上の情報が豊かとなり、公共の利益につながる。

更に、本発明の識別名管理方法によれば、インターネットを利用する一般のユーザーは、情報の有用性や信頼性を、その情報の発信者によって評価することができ、より安心してその情報を利用することが可能となる。

図１は、本発明の実施例１の識別名管理システムにおいて、サイバーネーム登録の手続きを説明する図である。 図２は、サイバーネームと公開鍵と対応を記載したリストファイルのハッシュ値を公表する為の新聞広告の具体例を示す図である。 図３は、サイバーネームと公開鍵と対応を記載したリストファイルの具体例を示す図である。 図４は、サイバーネームで認証を行う手続きを説明する図である。 図５は、で認証を行う別の手続きを説明する図である。 図６は、実施例１の管理サーバーに設けられているデータベースの構造を説明する図である。 図７は、実施例１のリンキング・プロトコルの実装方法を示す図である。 図８は、実施例１のリンキング・プロトコルの効果を説明する図である。 図９は、実施例１のリンク情報において、日時情報（メッセージ内）の信頼性が、他の情報とどのように関連しているかを説明する図である。 図１０は、実施例１ののリンク情報において、日時情報（メッセージ内）の信頼性が、他の情報とどのように関連しているかを説明する図である。 図１１は、一般ユーザーのメッセージを掲載している掲示板の一例を示す。 図１２は、図１１に含まれるＵＲＬ（認証データ）をクリックして表示される発言リストの具体例を示す。 図１３は、実施例１の識別名管理システムで提供される署名確認情報を示す図である。 図１４は、実施例１の識別名管理システムで提供される認証日時確認情報を示す図である。 図１５は、リンク情報の検証に必要な照合データのリストファイルの例を示す図である。 図１６は、特定のメッセージと類似したメッセージが抽出され、ブラウザによって表示されている画面を示す図である。 図１７は、ユーザー評価を行うためのダイアログを示す図である。 図１８は、トークンを生成する為の画面をを示す図である。 図１９は、映像や音楽コンテンツに対して認証が行われる例を示す図である。 図２０は、認証が行われたWebサイトの例を示す図である。 図２１は、Webサイトの各ファイルに対する認証データを表示している例を示す図である。 図２２は、図２１の認証データから構成された、ファイルの認証を示す認証メッセージの例を示す図である。 図２３は、実施例１の識別名管理システムにおいて生成された発言リストからメールの送受信を行う場合を説明する図である。 図２４は、実施例１の識別名管理システムにおいて認証されたメッセージを引用する場合を説明する図である。 図２５は、実施例１の識別名管理システムにおいて生成された発言リストから、そのユーザーのお気に入りを表示する場合を説明する図である。 図２６は、サイバーネームと公開鍵と対応を記載したリストファイルのハッシュ値を公表する為の新聞広告の別の具体例を示す図である。 図２７は、サイバーネームと公開鍵と対応を記載したリストファイルの別の具体例を示す図である。 図２８は、実施例２に係る識別名管理システムとして実装された管理サーバーに設けられているサイバーネーム管理テーブルを説明する図である。 図２９は、実施例３による署名検証プログラムを最初に実行した際に表示されるダイアログの画面を示す図である。 図３０は、詳細設定ダイアログの画面を示す図である。 図３１は、公開鍵情報を生成した際に表示されるダイアログの画面を示す図である。 図３２は、公開鍵情報を公表する手順を説明する図である。 図３３は、署名検証プログラムを実行し、個人鍵ファイルが存在している場合に表示されるダイアログの画面を示す図である。 図３４は、ユーザーが他のアプリケーションを実行中に、実施例３による署名検証プログラムを呼び出す手順を説明する図である。 図３５は、メッセージに署名を付加する手順を説明する図である。 図３６は、署名が付加されたメッセージを投稿する手順を説明する図である。 図３７は、メッセージに付加された署名を検証する手順を説明する図である。 図３８は、ファイルのハッシュ値を取得する手順を説明する図である。 図３９は、ファイルのハッシュ値と署名が付加されたメッセージの具体例を示す図である。 図４０は、検証に成功したメッセージ本文に、キーワード「SHA256:」とそのハッシュ値の文字列が検出されている場合に表示されるダイアログの画面を示す図である。 図４１は、ハッシュ値の検証に成功した場合に表示されるダイアログの画面を示す図である。 図４２は、ハッシュ値の検証に失敗した場合に表示されるダイアログの画面を示す図である。 図４３は、本発明における署名利用シナリオと従来の署名利用シナリオとの関係を説明する図である。 図４４は、実施例４による署名検証プログラムでメッセージに署名を付加する手順を説明する図である。 図４５は、実施例８により携帯端末側の公開鍵の登録を行う説明する図である。 図４６は、実施例８による認証方法で認証を行う手順を説明する図である。 図４７は、実施例９により本人確認を行う手順を説明する図である。

電子署名アルゴリズムにおいては、平文を署名鍵で処理することで署名を生成し、署名の検証を検証鍵で行う。しかし、データベースにおいては、各レコードにユニークな情報のみが問題となる。従って、この明細書においては、適宜、各鍵ペアにユニークな検証鍵情報を公開鍵と呼び、各鍵ペアの秘匿される署名鍵情報を秘密鍵と呼ぶこととする。例えば、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のみを公開鍵と呼ぶことにする。また、以下の記述では、パディングやハッシュ処理など平文への前処理も含めて署名の処理とする。

本発明の実施例１に関わる識別名管理システムは、インターネットに接続し、識別名を管理する管理サーバーとして実装される。この管理サーバーと通信して識別名を利用する為に、ユーザーのパソコン側には専用のユーティリティソフトがインストールされる。管理サーバーでは、個々の匿名ユーザーに対して、識別名としてユニークなサイバーネームを発行し、このサイバーネームを対応する匿名ユーザーの公開鍵に関連付けて公開する。個々のサイバーネームがユニークであることは、管理サーバーが管理し保証するが、全て公開されるので誰でも重複の有無を確認できる。

パソコンのユーティリティソフトでは、公開鍵と秘密鍵のペアを生成し保存する。ただし秘密鍵は暗号化しておく。そして、その公開鍵とサイバーネームを関連付けて登録を行うように、管理サーバーに依頼する。秘密鍵は管理サーバーへは送信されず、ユーザーが自己責任において秘匿する。また、ユーザーがメッセージを投稿する際に、署名をすることでサイバーネームで認証を付けたり、他人のメッセージの認証を検証したりできる。この実施例では、署名アルゴリズムとして2048ビットのRSAを用いるものとする。

なお、管理サーバーとユーザーとは、ＳＳＬで保護された通信を行うが、このＳＳＬはＴＬＳ(Transport Layer Security)も含むものとする。特に、必須ではないが、クライアント認証も行うことが好ましい。この場合は、サイバーネームに関連付けられた公開鍵を用いると便利である。

識別名管理システムの基本的な機能は、インターネットのユーザーが、個人情報を開示すること無く、電子署名を利用出来るようにするものである。その為に、各ユーザーの識別名と公開鍵を対応付けて、登録し一般に公開する。これによって各ユーザーは、インターネットにおける自分の活動に対して、電子署名を付けることで他人と明確に区別し、自分の識別名によって、インターネットにおけるアイデンティティを確立することが出来る。

＜サイバーネームの登録＞ この実施例では、サイバーネームの登録は匿名で行われる。この場合、一人のユーザーが、多くのサイバーネームを登録してしまうと、サイバーネームが足りなくなってしまう。従って、むやみに発行依頼ができないような仕組みが必要となる。その目的で、例えば、機械が自動的に読み取ることが難しい不鮮明で歪んだような文字を画面に表示し、ユーザーに読み取らせるCAPTCHA（キャプチャ）システムを利用することができる。また、適宜、同じIPアドレスからの登録を制限したり、クッキーを利用するようにしてもよい。

また、サイバーネームを利用するには、暗号関連のユーティリティソフトが必要である。このユーティリティソフトに実装される機能としては、公開鍵と秘密鍵のペアを生成する機能、これらの鍵をBase64によって文字列に変換する機能、秘密鍵をパスワードで暗号化して保存する機能、秘密鍵を用いてデータに署名をする機能、署名をBase64 によって文字列に変換する機能する機能がある。

更に、この実施例では、ユーティリティソフトには、簡易ブラウザ機能も実装されている。これは、認証されたメッセージを発信したい場合に、このユーティリティソフトのブラウザから認証処理を手軽に行うためのものである。しかし、このブラウザ機能は必須ではない。適宜、ブラウザ機能を用いない方法も適宜説明する。なお、万一の情報紛失に備えて、Base64によって文字列に変換された公開鍵や秘密鍵を印刷する機能もある。

以下、図１を参照して、サイバーネーム登録の手続きを説明する。図１は、この実施例で用いるユーティリティソフトの登録画面である。識別名管理システムの管理サーバー１０にサイバーネームの登録を希望するユーザーは、希望サイバーネームを入力し、送信ボタンをクリックして、管理サーバー１０へ送信する（Ｓ１）。管理サーバー１０では、発行可能なサイバーネームを返す（Ｓ２）。この発行可能なサイバーネームは、発行サイバーネームのボックスに表示される。また、同時に、管理サーバー１０は、CAPTCHAの歪んだ文字列の画像データも送信する。この画像データは、ユーティリティソフトの画面に表示されるので、ユーザーは、この文字列を読んで、この文字列を下の入力ボックスへ入力しておく。

ここで発行可能なサイバーネームは、入力されたサイバーネームの先頭にプリフィックスが付加されている。このプリフィックスは、ユニークなサイバーネームを得るためのハッシュ値であり、見た目でもなるべく類似するサイバーネームがないように管理サーバー１０側で選択される。プリフィックスの末尾はアンダーバーとなっている。例えば、図１の例ではサイバーネームとしてNuagesを希望し、aZ38_Nuagesが発行可能な例として管理サーバー１０から返されている。

これにより、****_Nuagesというパターンを持つサイバーネームは、複数のユーザーが利用出来ることになる。この例のように、Base64で利用されている４文字を用いることにすれば、16,777,216通りのプリフィックスが存在することになる。また、アンダーバー"_"で明確に区切られているので、プリフィックスの文字数は固定しなくても良い。

また、ユーティリティソフトはRSA公開鍵と秘密鍵のペアを算出する。ユーザーは、この秘密鍵を暗号化する為の秘密鍵暗号化用パスワードを入力しておく。更に、ユーザーが望む場合には、オプション署名用テキストも入力しておく。このテキストの利用方法は後述する。また、ユーティリティソフトが２５６ビットの乱数を生成して、それを確認ハッシュ（ID Hash）として表示する。このハッシュの利用方法も後述する。

以上の入力を終え、申請ボタンをクリックすると、サイバーネームと共に、RSA公開鍵、オプションデータや確認ハッシュおよびCAPTCHA の入力文字列が管理サーバー１０へ送信される（Ｓ３）。ただし、この実施例では、オプション署名用テキストを秘密鍵で署名した2048ビットの署名値が、オプションデータとして送信される。受信したCAPTCHA入力文字列が正しければ、管理サーバー１０は、現在日時を仮登録日時として、それらの情報をサイバーネームに関連付けて保存し、ユーザーへ仮登録情報を返す（Ｓ４）。

ユーザーはこの仮登録情報を確認し、以後、そのサイバーネームを使用することができるようになる。そして、最初に、ユーザー署名を行ってサイバーネームを使用した日が本登録の日とする。もし、仮登録から一週間以内に本登録がなされなければ、仮登録は無効となる。その場合、ユーザーは最初からやり直さなければならない。

なお、この例では、プリフィックスを管理サーバー１０が決定しているので、ステップＳ１、Ｓ２を最初に行う。しかし、ユーティリティソフト側で、乱数からプリフィックスを決定し、ステップＳ１、Ｓ２を省略しても良い。その場合は、ステップＳ３で、そのプリフィックスを含むサイバーネームを送信する。サイバーネームに重複があれば、ユーティリティソフトへ通知される。

＜オプション署名＞ 管理サーバー１０では、ユーザーからのオプションデータも登録し、一般に公開する。このオプションデータとして次のような用途が考えられる。すなわち、図１に示すように、当該ユーザーを特定する個人情報を、署名したい文章として入力する。そして、管理サーバー１０へ送信する際には、ユーティリティソフトは、この個人情報への署名をオプションデータとして送信する。ただし、オプションデータとしては、２５６ビットのRSA署名のみで、個人情報のテキストは含まれていない。この場合、個人情報はハッシュ関数で処理されるので、署名データからは元の個人情報を得ることは不可能である。従って、個人情報の署名を公開しても、匿名性は保たれる。

一方で、署名そのものはサイバーネームや公開鍵と関連付けて登録されているので、サイバーネームの所有者が誰であるかは、その所有者が望めば、何時でも証明可能となる。すなわち、上記個人情報データを示して、登録されている署名に対応していることを示せば良い。なお、２５６ビットのRSA署名を想定して、オプションデータの最大サイズは半角４４文字までとする。

このような状況は、サイバーネームに対応する秘密鍵を紛失したり、漏洩したりした場合に、本人確認の有力な証拠として利用出来る。署名された平文データも紛失した場合も考えられるので、予め推奨する定型文を決めておくことも考えられる。例えば、登録年月日が2010/02/28で、住所が東京都千代田区千代田1番1号で、名前が認証太郎で、サイバーネームがaZ38_Nuagesである場合には、図１の「オプション署名用テキスト」のブロックに示されているようなフォーマットで、それらの情報を連結して本人確認の為のテキストする。万一、ユーザー側の全てのデータが消えてしまっても、この通りに機械的にテキストを作成して、サイバーネームに対応する公開鍵を用いてオプション署名と照合すれば本人確認が可能となる。

しかしながら、定型文を使うと不都合な場合も考えられる。例えば、サイバーネームのユーザーとしての候補が幾つかあった場合、考えられる総当たり攻撃で定型文を照合し続ければ、どの候補が本人であるかを特定することができてしまう可能性がある。このような状況では、不特定の形式で本人確認テキストを作成したほうが好ましい。より確実なのは乱数や後述のオプションハッシュを上記個人情報に付加して、オプションデータとする方法である。

一方で電子データとして保存しておくことは、常に漏洩や紛失、消失の可能性がつきまとう。一般的には、秘密鍵や本人確認テキストを含む、登録情報の全てを紙に印刷しておき、適当な場所に保管しておくことが一つの安全な方法である。

＜オプションハッシュ＞ 秘密鍵の漏洩などで、複数のユーザーが同一サイバーネームのもとで署名が可能となってしまった場合、ハッシュ値をオプションデータとして登録しておくと、抽象的な本人確認が可能となる。

すなわち、乱数等をSHA-256等のハッシュ関数で複数回（例えば、千回）再帰的に処理した値を、オプションデータとして登録しておく。そして本人確認が必要な状況にはめったにならないので、最初の乱数等は、USBメモリなどの外部ストレージに記憶したり、紙に印刷しておく。

本人確認を行うには、登録されているオプションデータの原像を提示すれば良い。また、サイバーネームの登録を更新する場合、公開鍵の変更は許可されないが、オプションデータの変更は可能としておく。従って、オプションデータを、本人確認の為に提示してしまった原像に変更しておけば、何度でも本人確認を行うことが出来る。その場合でも、最初の登録の際のユーザーに関する本人確認となる。

＜登録情報の明証化＞ 管理データベースの記録は専用のサイトで一般に公開され、誰でもサイバーネームに対応する公開鍵を取得することができる。また、一定期間に登録された記録は、ファイルとしてダウンロードできる。例えば、一週間単位で、その期間に登録されたサイバーネームに関連付けて、公開鍵、登録日およびオプション署名が、ＣＳＶファイル等のリストファイルとしてダウンロード可能に公開される。そして、そのリストファイルのハッシュ値が、新聞などの刊行物に公表される。これを登録情報の明証化と呼ぶ（Ｓ５）。

すなわち、この明細書において、明証化とは、管理サーバー１０がデジタルデータとして一般に公開したサイバーネームと公開鍵との一対一の対応関係を、改竄不可能な刊行物に印刷された情報によって、客観的に固定化する行為を指す。但し、この対応関係の固定化は、ここで用いられる暗号技術の有効性に依存するので、必要が生じた際に、データをカプセル化して再度明証化を行う。

新聞広告の具体例を図２に示す。また、リストファイルの具体例は、図３に示す。なお、図２の具体例では、２つのハッシュ値を公表している。万一何れか一方が破られても、他方の有効性が保たれる。また、リンク情報の代表値も公表されている。この代表値については後に詳しく説明する。

従って、対応する秘密鍵の所有者（サイバーネームの使用者）は、当該リストファイルを保存しておくことで、管理サーバー１０とは無関係に、何時でも自分が当該サイバーネームの使用者であることを証明できる。このリストファイルと公表されたハッシュ値は、利用しているハッシュ関数の安全性が確認されている期間について、有効性が保証される。すなわち、リストファイルと刊行物の組み合わせで、そのサイバーネームに対する公開鍵証明書となっている。

＜サイバーネームによる認証１＞ 登録が済むと、掲示板などのWebサイトにユーザーが何らかの意見や情報を書きこむ際などに、サイバーネームを用いて認証を付けることができる。上記ユーティリティソフトには、簡易ブラウザ機能が実装されており、認証を付けて情報の送信を行う場合には、ユーティリティソフトを立ち上げて、そのブラウザ機能を用いる。ここでは、「子ども手当2-3000円増額は、大歓迎です」という書き込みを掲示板サイトのエディットボックスへ行う場合を図４を参照して説明する。

先ず、ユーティリティソフトで、その掲示板サイトの投稿ページ（一般には、情報発信先のページ）を開く。そこにメッセージを書きこんで、送信するためのボタンをクリックすると、実際の送信を行う前にユーティリティソフトは、サイバーネームを管理サーバーへ送信して、認証開始要求を行う。管理サーバーでは、サイバーネームの有効期限が切れていれば、その旨通知して処理が終了する。有効期限が切れていなければ、サイバーネームの格付け（後述）と現在時刻をユーティリティソフトへ送信する（Ｓ１）。

そして、ユーティリティソフトは、パスワードボックスを備えたポップアップウインドウを表示し、署名用メッセージ２３を提示する（Ｓ２）。ただし、書き込まれたメッセージに加えて、署名用メッセージ２３では、管理サーバーからの情報に基づいて、サイバーネームと、格付け（ここではＡ）と、現在日時が追加されている。格付けは、ユーザーの信頼度の目安を与えるもので、サイバーネームの後に：を挟んで挿入される。日時はタイムサーバーからその都度取得する。

ユーザーは、内容を確認し、パスワードを入力してから、OK ボタンをクリックする。ユーティリティソフトは、パスワードから秘密鍵を複合し、格付けと現在日時とサイバーネームを含むメッセージに署名を行い、メッセージと署名を、管理サーバーへ認証要求として送信する（Ｓ３）。また、投稿先のサイト情報（ＵＲＬ）も、認証要求と共に送信する。このＵＲＬは、管理サーバー側で投稿先を示す情報として後述の発言リストで使用する。

認証要求を受けた管理サーバーは、受信したユーザー署名を検証する（Ｓ４）。検証に失敗すれば、その旨、ユーザーへ通知して処理を終了する。検証に成功すれば、メッセージに、シリアルナンバーを割り振り、後述のシールを挿入して認証メッセージを作成し、これをユーティリティソフトへ返し（Ｓ５）、認証メッセージの登録を行う（Ｓ６）。ユーティリティソフトは、この認証メッセージを投稿先サイトへ送信する（Ｓ７）。

ここで、図４に示したように、この認証メッセージにおいて、シリアルナンバーはＵＲＬ５５に埋めこまれている。このシリアルナンバーは、全てのユーザーのメッセージを時系列に並べるもので、１６進数（図４では"003F4959"）で表記されている。また、ユーザー署名からシールが算出され、認証日時（現在日時）の後に挿入される。このシールはユーザーの認印のような機能を持つ。

後述の通り、これらシリアルナンバーは、対応する認証メッセージのハッシュ値に関連付けられることで、このメッセージに対する認証データとなっている。すなわち、サイバーネームに対応してユーザー署名がされていることと、記載されている認証日時が正しいことが、管理サーバーにおいて確認され認証されていることを示している。

従って、認証データを管理サーバーへ提示することで、管理サーバーによる認証の確認を行うことができる。その手順は後に説明する。認証の確認が行われた場合、それは管理サーバーへの信頼性を根拠としている。より厳密には、明証化された公開鍵やリンク情報を用いて、誰でも客観的に署名や認証日時の検証を行うこともできる。その手順も後に説明する。

なお、メッセージの認証日時の証明に必要なデータは、管理サーバーに保存されているが、必要に応じて、ユーザー側でも保存しておくことが望ましい（Ｓ８）。すなわち、後述の管理サーバー内のデータベースのメッセージ管理テーブル６２に保存される当該メッセージに対応するエントリの情報を保存しておく。更に、利用可能になった時点で、当該メッセージに関連するハッシュ値のセット（照合用データ）や、新聞広告の画像データを、後のほうの新聞広告が行われた際に、リンク情報として管理サーバーからダウンロードしておく。これによって、管理サーバーとは独立にメッセージの認証日時の証明を行うことが出来る。

＜サイバーネームによる認証２＞ ユーティリティソフトと管理サーバーの動作をもう少し簡潔なものにする実装も可能である。この実装においては、掲示板サイトの投稿ページは、一般的なブラウザで開くようにする。すなわち、図５の右上に示したように、普段利用しているブラウザで投稿ページが開かれている。ここで投稿を行いたい場合には、ユーティリティソフトで署名認証の画面を開く（図５の左上）。この署名認証画面では、メッセージを書きこむエディットボックスとパスワード入力ボックスが表示されている。

ユーザーは、このエディットボックスに投稿したいメッセージを書き込んで、パスワードを入力し、署名実行のボタンを押す。すると、ユーティリティソフトは、インターネット上のタイムサーバーから現在時刻を取得して、サイバーネームと共にメッセージに付加して、署名用メッセージとする。この署名用メッセージに、署名を行って、管理サーバーに認証要求を送信する（Ｓ１）。

認証要求を受けた管理サーバーは、受信したユーザー署名を検証する（Ｓ２）。検証に失敗すれば、その旨、ユーザーへ通知して処理を終了する。検証に成功すれば、メッセージに、シリアルナンバーを割り振り、後述の格付けとシールを挿入して認証メッセージを作成し、これをユーティリティソフトへ返し（Ｓ３）、認証メッセージの登録を行う（Ｓ４）。すなわち、ユーティリティソフトと管理サーバーとのやり取りは一度だけで済む。

ユーティリティソフトは、この認証メッセージをクリップボードへ格納し、「クリップボードに認証メッセージがあります。投稿先に貼り付けて利用してください」といった表示を行う。ユーザーは、クリップボードから投稿先へ認証メッセージを貼り付けてから、投稿を行う。やはり、ユーティリティソフト側で、必要に応じて、認証メッセージや認証日時の証明に必要なデータの保存を行っておく。

この例では、ユーティリティソフトにブラウザ機能は不要となるが、ユーザーの手間は若干増える。また、一般的なブラウザから投稿先のサイト情報（ＵＲＬ）を正確に取得できないことも考えられるので、場合によっては、このサイト情報は参考情報といった扱いになる。更にこの例では、署名用メッセージに格付けは含まれていない。これは、管理サーバーとの通信の節約になる。

＜シール＞ 管理サーバーは、上記ユーザー署名を受信し検証すると、このユーザー署名のハッシュ値を算出して、その最後の２４ビットをBase64でエンコードすることで４文字のシール（Seal）を生成する。ここでのハッシュ関数としては、ＳＨＡ−１などを用いれば良い。そして、認証日時（現在日時）の後にこのシールを付加する。

シールも近似的に２４ビットの乱数と考えられるので、ユーザー署名の一つのハッシュ値と言える。ユーザー署名と同じビット長を持ち、且つ上記２４ビットのハッシュ値と同じハッシュ値を生成するような、別のデータを探すことは困難ではない。しかし、そのデータをユーザー署名とみなして、検証を行った場合に、検証に成功するようなハッシュ値の原像となるような認証メッセージを算出することは困難である。

従って、シールを用いれば、各ユーザーは、或る投稿を自分のものである事も、自分のものでない事も管理サーバーとは独立に証明できる。自分のものである事は、メッセージへの署名を作成して、その署名がシールと対応していることを示せば良い。また、自分のものでない事は、メッセージへの署名を作成して、その署名がシールと対応していないことを示せば良い。サイバーネームと公開鍵との対応は、リストのファイルと新聞での公表情報により証明できる。

＜メッセージの管理＞ 図６に示すとおり、管理サーバー内のデータベースには、サイバーネームとユーザー公開鍵を関連付けるサイバーネーム管理テーブル６１と、全ての認証メッセージを時系列で管理するメッセージ管理テーブル６２と、公表リンク情報のテーブル６３が設けられている。

サイバーネーム管理テーブル６１の各エントリーには、サイバーネーム（CyN）と、ユーザー公開鍵（Kup）と、ユーザーの信頼性の目安を示す後述のポイント数（Points）と、ランキング情報（Ranking）と、登録日（Registration）と、有効期限（Expiration）と、オプションデータ（Optional Data）と、公表日（Pub Date）、確認ハッシュ（ID Hash）を格納するフィールドが含まれている。

上記サイバーネーム管理テーブル６１では、サイバーネームとユーザー公開鍵とを関連付けることが最も重要となっている。なお、ポイント数は、ユーザーの信頼性の目安を示すものであり、ランキング情報は、ポイント数に基づくユーザーのランキングを示すものであり、オプションデータは、サイバーネームの所有者が実名による本人確認を行う為などに用いるものであり、確認ハッシュはサイバーネームの匿名による本人確認を簡易的かつ繰り返し行う為に用いるものである。これらのフィールドの機能や利用方法は、後に詳細に説明する。

メッセージ管理テーブル６２の各エントリーは、各認証メッセージが作成される際に、時系列に割り当てられた連続番号であるシリアルナンバー（Serial No.）と、保存されている認証メッセージへのポインタ（pMsg）と、当該認証メッセージのハッシュ値h(Msg)と、署名用メッセージへのユーザー署名SigUと、当該認証メッセージの認証日時（Date）と、サイバーネームCyNが格納されている。

ここで、署名用メッセージとは、メッセージ本文に、サイバーネームと、格付けと、認証日時を加えたものである。上記の通り、この署名用メッセージに対してユーザーが行った署名が、ユーザー署名SigUである。また、上記の通り、ここでの認証メッセージとは、署名用メッセージに対して、シールと、シリアルナンバーを含むＵＲＬを加えたものである。ただし、上記＜サイバーネームによる認証２＞で説明した実装においては、格付けの情報は、署名用メッセージには含まれておらず、認証メッセージを構成する際に挿入される。

なお、この例では、ユーザーから送られてきた投稿ページのＵＲＬのエントリーＵＲＬ１も含まれている。更に、後述の通り、実際に認証メッセージが掲載されているページのＵＲＬのエントリーＵＲＬ２と、その掲載ページの管理サーバー内キャッシュへのポインタｐＣａｃｈｅも含まれている。これらのＵＲＬ１、２は後述の発言リストで使用する。

シリアルナンバーは、全てのメッセージを時系列に並べて付けた連続番号である。これによってメッセージの認証日時の前後関係が特定できる。後述の通り、ここでは、シリアルナンバーを時系列ＩＤとしたリンク情報の代表値が、上記リストファイルのハッシュ値と同時に、新聞などの刊行物に公表される（図２）。

公表リンク情報のテーブル６３は、刊行物で公表されたシリアルナンバー、その刊行物の日付（Pub Date）、リンク情報、公表された広告イメージの画像データ（p_Image）が保存されている。誰でも管理サーバーへアクセスして、シリアルナンバーを指定してリンク情報を要求すれば、そのシリアルナンバーに関連するデータ、すなわち、そのシリアルナンバーの前後のテーブル６３のエントリおよびそのシリアルナンバー間のハッシュ値をダウンロードすることができる。

公表リンク情報テーブル６３の日付（Pub Date）は、サイバーネーム管理テーブル６１の公表日（Pub Date）と同じものである。すなわち、サイバーネーム管理テーブル６１では、公表日（Pub Date）は、そのサイバーネームを含むリストファイルのハッシュ値を公表した刊行物（新聞）の日付を示している。なので、複数のサイバーネームが、同一の公表日を共有するが、公表リンク情報テーブル６３の各エントリは、異なる公表日（Pub Date）を持っている。なので、aZ38_Nuagesの公開鍵を公表情報から確認する場合には、サイバーネーム管理テーブル６１から、aZ38_Nuagesの公表日（Pub Date）を得て、次に、公表リンク情報テーブル６３からその公表日（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の刊行物で行われる。

上記のとおり、管理サーバーは、ユーザー署名を検証し、メッセージにシリアルナンバーを割り当てる。なので、メッセージに付加されたシリアルナンバーは、認証済みであることを示す認証データとなっている。

また、誰でも管理サーバーへアクセスして、上記データベースのその他の情報を取得できる。例えば、サイバーネームを特定して、サイバーネーム管理テーブル６１の該当エントリーの全ての情報を取得できる。また、シリアルナンバーを指定して、メッセージ管理テーブル６２の該当エントリーの全ての情報を取得できる。

例えば、aZ38_Nuagesの公開鍵を公表情報から確認したいとする。その場合には、先ず、サイバーネーム管理テーブル６１から、aZ38_Nuagesの公表日（Pub Date）を参照して、その公開鍵が含まれるべきリストファイルとの整合性を確認する。次に、その公表日の直後の公表データに掲載されているハッシュ値と、リストファイルのハッシュ値が一致しているかを確認する。これにより、aZ38_Nuagesの公開鍵が正しいものかどうかを確認できる。

＜日時認証＞ 電子データに対して時刻認証を行う為の手段として、一般にタイムスタンプが利用されている。このタイムスタンプは、電子公証や電子署名法でも使用されており、e-文書法で電子化が許可された文書の中にも、一部省令でタイムスタンプの利用が義務付けられているものがある。タイムスタンプの実装方法としてよく利用されているのが、リンキング・プロトコルである。このリンキング・プロトコルは、電子署名の信頼性に依存せずに長期にわたって認証日時における存在証明と非改竄証明を可能とするものである。

以下、図７を参照して、本実施例による時刻認証の方法を説明する。シリアルナンバーをｉとした場合、対応するリンク情報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)ならば、少なくとも一方は正しくない。

図８を参照して、更に説明する。ここで、リンク情報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)であることが確実となる。

このリニアリンキング・プロトコルは、一般的なタイムスタンプ・サービスで用いられるタイムスタンプ・プロトコルの一つであるが、この実施例では、通常のタイムスタンプ・サービスよりもシステムとしての信頼性が高くなっている。

通常のタイムスタンプ・サービスの場合、事実上の乱数であるハッシュ値が特定の日時に存在したという証明をするだけである。情報自体はユーザーのみが所有して、一般には公開されない。また、タイムスタンプ・サービス側は途中のハッシュ値を公開するのみで、情報の内容には関知しない。

また、一週間間隔で代表値を刊行物に公開する場合、一週間という期間内の何処に本当の認証日時があるかについては、リニアリンキング・プロトコル自体は保証しない。確実なのは、タイムスタンプ間の順序関係のみである。認証日時そのものは、タイムスタンプ・サービス提供サイトの信頼性に依存する。

上記の通り、本実施例でも、シリアルナンバーを時系列ＩＤとしたリンク情報の代表値が、上記リストファイルのハッシュ値と同時に、新聞などの刊行物に公表される（図２）。しかしながら、ここでは認証メッセージMsg(i)は、管理サーバーに保存管理され、また不特定多数のサイトに掲載され公開される。

認証メッセージMsg(i)が公開されるということは、そのハッシュ値も事実上公開されるということになる。このハッシュ値は、公開リンク情報を繋ぐ照合用データとなっている。

本実施例の場合には、管理サーバーの付与した認証日時に加えて、不特定多数のサイトにも投稿日時と共に認証メッセージが掲載され、そのハッシュ値（照合用データ）と共に公開される。この多数の第三者の公開データ（特に投稿日時）の分だけ、認証日の正しさに対する蓋然性が高くなる。仮に、隣接する代表値の公表日の間に、一つの信頼できるサイトで公開された認証メッセージがあり、そのハッシュ値および投稿日時がリンクチェーンに矛盾なく収まる値であれば、そのリンクチェーンの認証日時の信頼性は、その信頼できるサイトでの投稿日時によって補強されることになる。

従って、管理サーバー側からは、隣接する代表値の公表日の間の認証メッセージのハッシュ値と掲載サイトのＵＲＬのリストがダウンロード可能に公開される。また、図２のような公表情報の画像データと、刊行物の書誌事項も公開される。希望するユーザーは、このハッシュ値のリストと公表情報のデータを保存しておけば、認証メッセージの投稿日に関する客観的な証拠データとすることができる。

なお、図４のＳ８に示されているように、ユーザーは、自分の各々の発言に関して、必要な２つの代表値Link-p、Link-nと、対応するシリアルナンバーSN-p、SN-nと、発行日Pub-p、Pub-nを保存しておく。また、必要な２つの代表値Link-p、Link-nの間のハッシュ値のセット（照合用データ）や、公表情報の画像データも保存しておく。これにより、管理サーバーとは独立にメッセージの認証日時の証明を行うことが出来る。

＜リンク情報の効果＞ 認証日時の信頼性に関して、リンク情報がどのような関連を持っているかについて更に詳しく説明する。図９に、サイバーネーム、ユーザー署名、リンク情報、日時情報（管理サーバー付与）および日時情報（各サイト付与）が時系列に並んでいる様子を示す。これらは全て投稿先のサイトで公開される情報である。又、管理サーバーにおいても公開されているので、リンクを辿ることは容易にできる。リンク情報は、投稿先のサイトでは直接は公開されないが、認証メッセージのハッシュ値を用いて、公表されている代表値から算出できる。

図１０に、日時情報（メッセージ内）の信頼性が、他の情報とどのように関連しているかを示す。ただし、ハッシュ関数の性質から、リンク情報によって各認証メッセージの前後関係は保証されている。ここでは、或るサイトに掲載されたメッセージ内の日時情報Date(i)のメッセージを考える。

当該サイトでは、この日時情報Date(i)とは無関係に付与された日時情報DateS(i)と共に、メッセージの掲載を行う。なので、Date(i)の信頼性とDateS(i)の信頼性は相互に補完する関係にある。すなわち、Date(i)とDateS(i)は一対一に対応している。

リンク情報によって各認証メッセージの前後関係は保証されているので、もしｉ＜ｊであってDate(i)＞ Date(j)となっていれば、Date(i)とDate(j)の何れかが誤っていることになる。この場合、日時情報Date()やDateS()のチェーンの中で、不自然な方が誤りである可能性が極めて高い。

例えば、或るメッセージの日時情報を一週間前の日時情報とする不正を行う場合を考える。まず、管理サーバーにアクセス可能な協力者を得るか、侵入して改竄を行う必要がある。ただ単に、そのメッセージの日時情報を一週間前の日時情報とすると、日時情報Date()の一週間のチェーンの中で、それだけ単調増加の規則から外れていることになる。

なので、チェーン自体を再構成する必要がある。一週間のチェーンを全て削除して、それよりも前の日時情報と連結する新たなチェーンを作成する。この場合、削除したチェーンのメッセージが投稿されている各サイトにも侵入して痕跡を消す必要がある。更に、新たなチェーンのメッセージも、各ユーザーが投稿したような痕跡を各サイトに書きこむ必要がある。更には、各ユーザーのパソコンへも侵入して整合性を取る必要性も考えなければならない。このような事は現実的には極めて困難と思われる。

すなわち、管理サーバーと、メッセージを発信した各ユーザーと、メッセージが掲載された各サイトの夫々の信頼性とは、夫々に、各日時情報の信頼性と独立に対応している。そして、日時情報に疑念がある場合、ハッシュ関数の一方向性に基づいて、何れの日時情報が正しくないかは容易に推測できる。また、その責任が何処にあるかも明瞭となっている。従って、意図的でない誤りを別とすれば、不正が行われる可能性は非常に低くなっている。

＜リンク情報の埋込み＞ メッセージにリンク情報を埋込むこともできる。ただし、リンク情報の全てを一つのメッセージに埋込むとメッセージへの負荷が大きくなる。そこで、上記シールをこの目的に利用する。

上記の通り、L(i)=h(L(i-1), i, h(Msg(i)))で、リンク情報L(i)が算出される。このリンク情報を２５６ビットとし、１１の倍数であるｉについて、L(i)を下位のビットから２４ビット毎に分解し、L(i, j)とする。ｊ＝０〜１０であり、最後の１６ビット目以降は０で埋める。このL(i, j)をbase64でエンコードし、後続のメッセージMsg(i+j)にシールとして埋め込む。このようにすることで、リンク情報も随時公開されるようになる。

＜認証の確認＞ 一般ユーザーのメッセージを掲載している掲示板の例を図１１に示す。ブラウザは一般のもので構わない。上記の通り、認証メッセージには、シリアルナンバーを含んだURLが含まれている。このURLのドメイン名は、管理サーバーのものである。管理サーバーが、このURLを受け取ると、シリアルナンバーに対応する管理サーバー内の登録メッセージを含むhtmlファイルを返す。

例えば、図１１で、４番目のメッセージ、すなわちサイバーネームaZ38_Nuagesのメッセージに含まれるURLを表示すると、管理サーバーは"003F4959"というシリアルナンバーを受け取ることになる。すると、管理サーバーは、シリアルナンバー"003F4959"のメッセージと、その前後のaZ38_Nuagesのメッセージを含む発言リストを応答として返す。

メッセージの文字列にＵＲＬが含まれる場合、サイト側で自動的にそのＵＲＬへのリンクに変換する場合が多い。従って、多くの場合は、メッセージの掲載ページでＵＲＬをクリックするだけで、発言リストを表示できる。リンクとなっていない場合には、ＵＲＬを直接ブラウザで開けば良い。

図１２に発言リストの具体例を示す。この発言リストでは、その発言者（ここではaZ38_Nuages）の過去の認証メッセージの一覧を参照することが出来る。相当数の発言がある場合なら、ここで絞込み検索などを利用することにより、aZ38_Nuagesというユーザーの人物像をある程度まで知ることができる。各項目の左下には、そのメッセージが掲載されているサイトへのリンク情報が示されている。

このリンク情報は、上記のとおり、認証時にブラウザから取得されたＵＲＬ１である。なので、認証メッセージの掲載ページへのリンクとなっているとは限らない。しかし、実際の掲載ページを知る上での情報としての利用が可能である。実際の掲載ページのＵＲＬ２が利用可能であれば、それも表示される。

従って、先ず、掲示板の当該メッセージが、発言リストに表示されているシリアルナンバー"003F4959"のメッセージと同一ならば、管理サーバーにおいて認証を受けているということが確認される。管理サーバーの信頼性に依存しないで、シリアルナンバー"003F4959"のメッセージが、確かにサイバーネームaZ38_Nuagesのユーザーによる投稿であることを確認したい場合には、署名確認ボタンをクリックする。すると、図１３のような画面が表示される。この画面には、シリアルナンバー"003F4959"のメッセージに対して行われたユーザー署名と、当該ユーザーの公開鍵と、この公開鍵を掲載したリストファイルをダウンロードする為のボタンと、このリストファイルのハッシュ値を掲載した新聞広告のコピーが表示されている。

従って、先ず新聞広告に含まれるハッシュ値によってリストファイルを検証し、このリストファイルから当該サイバーネームの公開鍵を確認し、この公開鍵によって署名を検証し、更に、格付けとシリアルナンバーを除くメッセージで署名を検証する。これらの手続きによって、該サイバーネームの秘密鍵を所有するユーザーが、このメッセージを作成したということが客観的に確認される。

また、管理サーバーは、認証メッセージの掲載ページの検索を行うようにする。これは、認証メッセージに含まれるサイバーネームや、シリアルナンバーや、単語をサーチタームとして、Webを検索により行う。但し、一般的なサーチエンジンは、インデックスの更新に数日ないし一週間以上かかることがあるので、認証後、しばらくしてから検索を行うようにする。これにより掲載ページのＵＲＬ２を得るようにする。このＵＲＬ２は、図１２のリストの二番目の発言に示されているように、認証時にブラウザから取得されたＵＲＬ１の上に表示しておく。従って、２つのＵＲＬがある場合には、上のＵＲＬをクリックすることで、掲載ページを直接表示することが出来る。

掲載ページを表示する別の方法は、ユーザーの力を借りることである。図１２に発言リストにおいて、サーチエンジンで上記サーチタームを検索するURLへのリンクをおく。ユーザーはこのURLをクリックすることで、サーチエンジンによる検索結果を表示するページを表示することが出来る。サーチエンジンへの登録が行われた後なら、このページには当該認証メッセージが含まれている。

例えば、「子ども手当2-3000円増額は、大歓迎です」という認証メッセージなら、サイバーネームであるaZ38_Nuagesも含めて、ｈｔｔｐ：／／ｗｗｗ．ｗｅｂｓｅａｒｃｈ．ｃｏ．ｊｐ／ｗｅｂ？ｑ＝子ども＋手当＋２−３０００円＋増額＋大歓迎＋aZ38_Nuagesへのリンクを表示する。

更に、図１３の画面で、認証日時確認ボタンをクリックすれば図１４のような画面が表示される。この画面には、シリアルナンバー"003F4959"に近いシリアルナンバーのリンク情報の代表値を公表している新聞広告のコピーが表示されている。一つはシリアルナンバー"003F4959"よりも小さくて最も近いシリアルナンバー"003F4239"に対応するもので、もう一つはシリアルナンバー"003F4959"よりも大きくて最も近いシリアルナンバー"003F5011"に対応するものである。更に、これらの間の照合データ（ハッシュ値）を含むリストファイルをダウンロードする為のボタンも示されている。

このリストファイル(Hash_003F4239_003F5011.list)には、図１５に示したような表データが含まれている。この表データでは、シリアルナンバーと、対応する認証メッセージのハッシュ値と、投稿サイトのURLが関連付けられている。従って、シリアルナンバー"003F4239"に対応するリンク情報から、シリアルナンバー"003F5011"に対応するリンク情報まで、途中のリンク情報を算出し、リストファイルの正当性を確認する。次に、リストファイルに記載されているシリアルナンバー"003F4959"のハッシュ値が、当該メッセージのハッシュ値と一致することを確認する。このようにして、認証日時の検証を行うことが可能である。

上記署名の検証や、ハッシュ値の算出や照合は、一般的な処理であり、当業者であれば容易に実装できる。ユーティリティソフトにそのような機能を実装しておけば良い。

なお、過去の認証メッセージから得られる人物像は、そのサイバーネームを所有する生身の人物の人物像そのものという訳ではない。その生身の人物が、インターネットというサイバー空間で例えば、aZ38_Nuagesという別の人物像を自由に形成できる。すなわち、発言の質と量が、そのサイバーネームの価値を決定する。従って、一つのサイバーネームを大事に育てることが重要で、むやみに多重登録を行っても余り利益は無い。この点をより強調する意味で、客観的なランキングを用いる。

図１２の例では、ランキングとして144/48237と表示されている。これは、48237個のサイバーネームの中で、第114位であることを示している。サイバーネーム管理テーブル６１のランキング・フィールド(Ranking)に格納される情報は、この順位114である。このランキングは、後に説明するポイント数（Points）に基づいて順位付けられる。すなわち、ここでは114番目にポイント数が多いユーザーであることを示している。

また、このランキングに基づいて、ユーザーの格付けが行われる。例えば、サイバーネーム全体の中の上位5%に含まれていれば「AAA」とし、それ以下で上位15%に含まれていれば「AA」とし、更にそれ以下で上位30%に含まれていれば「A」とし、更にそれ以下の場合は「B」とする。この格付けは、認証メッセージに含めて投稿されるので、書き込みを読む際にそのユーザーの格付けが分かって好都合である。

ただし、掲示板などに表示されている認証メッセージの格付けの値は、そのメッセージの書き込みの際の格付けの値である。従って、認証確認の時点での格付けの値とは、一般的に一致しないことになる。

なお、発言リストの各項目の右下には、当該メッセージの内容と類似したメッセージを表示するためのボタンが示されている。このボタンを押すと、図１６のような画面が表示される。ここでは、最上段に当該メッセージが表示され、その下に、内容がより近いものから、古いものを優先的に表示される。これにより、類似のテーマに関する他のユーザーの意見を参考することができる。また、当該メッセージの日付より前のものと後のものを色分けして表示する。このようにすることで、オリジナリティ豊かな内容が含まれていた場合、どのユーザーが最初かを知ることができる。

上記のように発言リストと同じウインドウで、類似メッセージを表示するのではなく、既存の検索エンジンを利用しても良い。この場合、当該メッセージから形態素解析などによりサーチタームを切り分け、検索結果が５〜１０程度になるようにサーチタームの個数を調節して、既存の検索エンジンによる検索を行うようにする。検索結果は、別のウインドウに検索エンジンのページが表示される。

＜ハッシュ値による認証の確認＞ プラグインの実装などにより、ブラウザ自身に認証確認の機能を持たせることもできる。その場合は、ブラウザ側で、表示されているテキストをスキャンし、認証メッセージの候補を検出する。そして、その認証メッセージの候補のシリアルナンバーを指定し、管理サーバーから該当するハッシュ値を取得する。取得されたハッシュ値と、認証メッセージの候補のハッシュ値を比較することで、認証を確認できる。認証が確認できれば、そのメッセージに認証確認の表示を行うようにする。

このような方法を採用すれば、メッセージのページを開きさえすれば、自動的に認証確認の表示により、ユーザーは何もしなくても認証メッセージであることが分かる。また、発言リストを表示したければ、そのシリアルナンバーを含む上記URLのリンクをクリックすればよい。この場合、もしリンクになっていなければ、ブラウザ側でリンクの為のhtmlタグを挿入する。

また、この場合、認証メッセージでのシリアルナンバーは、URLとしての記述である必要はない。シリアルナンバーのみを記載しておき、ブラウザ側でそのシリアルナンバーにリンクを張るようにすればよい。セキュリティ上の理由などから、メッセージにURLを記載することが出来ないような場合もある。このような場合には、シリアルナンバーのみを記載したような認証メッセージがより好都合である。

＜ポイント数＞ ポイント数（Points）は、サイバーネームを所有するユーザーの信頼性を示す数値である。この実施例では、信頼性はユーザー同士が評価し合う。すなわち、夫々のユーザーが、他のユーザーの情報発信に対して評価を行う。ただし、評価を効果的に行うためのルールを適応しておく必要がある。そのようなルールとしては、次のようなものがある。

他のサイバーネームに対する評価ポイントには、マイナスのポイントも含まれる。例えば、剽窃を繰り返すような場合には、そのサイバーネームのポイントを減少させることが出来る。ユーザーの評価ポイントには、そのユーザーのポイント数に応じた評価回数への制限がある。例えば、ランキングがAAAならば、週に１００ポイントまで、AAなら１０ポイントまで、Aなら５ポイントまでの評価が可能で、Bの場合は評価を許可しないものとする。

システムを最初に開始した状態では、評価を行えるユーザーは存在しない。従って、情報発信の内容を吟味して、システム側が、評価ポイントを割り振るようにすると、上記システムが機能するようになる。

ユーザー評価のインターフェースとしては、例えば、図１６の類似発言の一覧などに、「aZ38_Nuagesさんを評価」というボタンを表示する。このボタンが押されると、図１７のようなダイアログが表示される。このダイアログには、本人確認の為のトークンを入力するボックスが含まれている。

ここで、上記ユーティリティソフトを起動させると、図１８のようなトークン生成画面が表示される。この実施例で用いるところのトークンとは、サイバーネームと、確認ハッシュの原像と、次の確認ハッシュとが、改行コードなどのセパレータで区切られた文字列である。確認ハッシュとは、図６のサイバーネーム管理テーブル６１に格納されている数値であるが、ここではBase64で文字列にエンコードされている。

図１８のトークン生成画面においてパスワードを入力して生成ボタンを押すと、ユーティリティソフトは、保存してある暗号化された確認ハッシュの原像を、パスワードを用いて確認ハッシュを復号する。また、次の確認ハッシュの原像として２５６ビットの乱数を生成する。この乱数をSHA-2で処理して次の確認ハッシュを算出する。次の確認ハッシュの原像はパスワードで暗号化し、現在保存してある暗号化された確認ハッシュの原像を置き換える。但し、現在保存してある暗号化された確認ハッシュの原像も一時的に保持しておく。ここで用いるパスワードは秘密鍵を暗号化したものと同じで良い。

以上のようにして求めた確認ハッシュの原像と次の確認ハッシュを、セパレータで区切って文字列としてサイバーネームの後に連結することで、トークンが得られる。このトークンはクリップボードに置かれるので、図１７のトークン生成画面に貼り付けることが出来る。このトークンは、評価フィードバック要求の添付データとして管理サーバーへ送信される。

トークンを受信した管理サーバーは、サイバーネームが評価する権利があることを確認し、サイバーネーム管理テーブル６１の確認ハッシュの値が、トークンの確認ハッシュのハッシュと一致を確認する。確認が取れれば、評価をポイントとしてデータベースに反映させる。また、評価を行ったサイバーネームの確認ハッシュを、トークンに含まれる次の確認ハッシュで上書きする。この場合、管理サーバーはハッシュ関数を一度計算するだけで済む。しかし、トークンを使わないで、aZ38_Nuagesを評価する趣旨の定まったフォーマットの日付を含むテキストに、直接署名した署名文を用いても良い。

また、後述のアフィリエイト・プログラムの成果を、信頼性評価に利用することも出来る。つまり、そのユーザーのページにアクセスして何かを購入するユーザーが多いほど信頼性を高くするようする。このように購入と評価を結びつけることで、不正に評価を操作することを防止することが出来る。

＜著作権＞ 一般ユーザーが発信する場合には、コピペの問題が生じることがある。ユニークで見識の高いメッセージの投稿を見て、それをそのままコピーして自分の認証を付けて、あたかも自分独自のメッセージとして別の掲示板へ投稿するというようなことである。このような場合でも、最初のユーザーが自分の署名を付けていれば、いずれが先かが明瞭となる。

コピペを行ったユーザーのサイバーネームの信頼性は低下するであろう。これをポイント数に反映させるには、悪質と判断したユーザーが、上記のような方法で、対象のサイバーネームのポイントを下げることで達成される。

通常のメッセージではなく、自作曲、イラスト、詩作といった創作コンテンツをネットで発表する場合には、認証の日付があれば他人の盗作に対して一定の歯止めがかかる。例えば、映像や音楽の場合には、ハッシュ値をメッセージに付加してから認証を行うようにする。

図１９では、「忘却の彼方へ」という自作曲に映像を付けて、MPEG-4のファイルとして発表した例を示している。ここでは、「島取への小旅行の記念に曲を作りました。」というメッセージに、「Oblivescence.mpg: SHA-2 a1yOOj…1jO=」を加えて、サイバーネームと共に認証を行っている。Oblivescence.mpgはビデオのファイル名であり、ハッシュ関数としてSHA-2を用い、Base64でエンコードし「a1yOOj…1jO=」というハッシュ値が得られたことを示している。

例えば、他のユーザーが音楽だけを取り出して、少し変えて自作曲として発表したとする。この場合、先のMPEG-4ファイルを発表した認証日時は、盗作であるか否かについての有力な証拠となり得る。

＜Webサイト認証＞ Webサイトのページは複数のファイルから構成されている。このようなデータに対して認証を行うには、認証を確認する為のページを別途設けることが便利である。例えば、図２０に示したようなWebサイトのトップページの場合、認証ページのURL（リンク）を記載しておく。ここでは、個別ファイル認証というボタンに認証ページへのリンクが設定されている。この認証ページは、例えば、図２１に示したような内容を含んでいる。

すなわち、この認証ページには、認証を行うデータ（通常はファイル）のURLが列挙されている。そして、これらのURLで指定されるデータのハッシュ値に対して上記のとおり認証を行っている。

例えば、"myhome.ne.jp/member1/content1.htm"というファイルのハッシュ値を計算し、Base64でエンコードしてテキストデータとする。このテキストデータを、通常のメッセージと同様にユーザー署名を付加して、所定のフォーマットにメッセージを組み立てて、サーバーへ認証を依頼する。図２１では、このファイルが20061223 19:23に作成され、シリアルナンバー00383093で認証されていることを示している。

この場合、認証メッセージは、次のように組み立てられる。すなわち、図２２に示したように、ファイル名、ハッシュ関数、ファイルのハッシュ値、サイバーネーム、格付け(Rating)、認証日時、シール、シリアルナンバーを含むＵＲＬを所定のフォーマットに従って組み合わせれば良い。上記の通り、この認証メッセージのハッシュ値によって認証の確認を行うことができる。Webサイトの作成者が認証を得るには、図２２からＵＲＬを除いたような所定のフォーマットに従って組み立てたメッセージについて、認証を求めれば良い。

Webページは度々更新されることがある。この場合、同じＵＲＬに関して、認証日時の異なる複数の認証を得るようにしても良い。図２１では、"myhome.ne.jp/member1/content2.htm"に別々の認証日時を持つ２つのエントリが示されている。

＜その他の機能＞ 発言リストなどを介して信頼を得ているユーザーに対して直接メールを送りたい場合もある。それには管理サーバーにメール機能を実装すれば良い。このメール機能は、発言リストのウインドウを介して提供される。例えば、図２３に示したように、発言リストのウインドウに設けられたメールタブをクリックすることで利用可能とする。

また、管理サーバーにブログ機能を実装して、これも発言リストのウインドウに設けられたブログタブをクリックすることで利用可能とする。このブログは、サイバーネームで特定されるユーザーの行ったインターネット上のすべての活動とリンクしているという点で、通常のブログとは異なる。

メールの表示を行うには、そのサイバーネームによるログオンが必要となっている。ログオンでの本人確認は確認ハッシュで行ってもよい。メールを送信するには、署名を添付することで、差出人の本人確認を行えるようにすることが望ましい。

＜サイバーネームの無効＞ 各ユーザーは、自分のサイバーネームを無効に出来る。それには、無効の申請を管理サーバーへ署名付きで行えば良い。無効となったサイバーネームと公開鍵の情報も、図２のような新聞広告でハッシュ値が公表されるリストに載せておく。無効にする理由としては、秘密鍵が漏洩してしまった場合などが考えられる。図３では、登録されたサイバーネームのリストの下に無効となったサイバーネームのリストが示されている。その場合、サイバーネーム管理テーブル６１の有効期限（Expiration）フィールドを、無効となった日時で上書きする。サイバーネームが無効となった場合、有効であった過去の発言に関しては発言リストで閲覧できるが、その場面で当該サイバーネームが無効であることと、無効の理由と日時が表示される。

また、サイバーネームには有効期限が設定される。格付けがA以上のユーザーの場合には、自動的に有効期限は更新される。有効期限の更新も新規の登録と同様に、新聞による公表が行われる。しかし、格付けがA以下のユーザーでは、一定期間以上サイバーネームの有効利用がない場合、有効期限の更新は行われない。有効期限が更新されると、サイバーネーム管理テーブル６１の有効期限（Expiration）フィールドが書き換えられる。

＜引用＞ 他人の文章を、そのまま黙って自分の投稿に利用するというのは、余り行儀の良いものではない。しかし、有用な書き込みの再利用はインターネットの利便性を向上させる。この場合、引用先を明記することで、オリジナルの書き手に配慮することができる。それにはシリアルナンバーの表記で足りる。更にサイバーネームを加えておけば、より敬意を払うことになる。

図２４に具体例を示す。ここでは「sn:」の後のシリアルナンバーと「Cbn:」の後のサイバーネームが引用先を示している。プラグインは、認証が成功したメッセージに、引用が含まれていれば、シリアルナンバーの表示に引用先のリンクを設定する。また、引用先サイバーネームの表示にそのユーザーの発言リストへのリンクを設定する。閲覧ユーザーが、引用先や発言リストを参照したい場合には、これらのリンクをクリックすれば良い。上記のとおり、このように引用されて発言リストが表示されれば、ポイントを加算するようにする。

＜収益モデル＞ 図１２のような発言リストには「お気に入り」タブが含まれている。このお気に入りを選択すると図２５のようなウインドウが表示される。このような発言リストを、ネットワークメディアとして利用することで、収益モデルの設計が可能となる。すなわち、ウインドウでお気に入りのタブを選択すれば、そのサイバーネームを所有するユーザーのお薦めの商品やサービスを知ることができる。このお気に入りの内容は、そのユーザーの信頼性が高ければ有効な広告媒体となり得る。また、アフィリエイト・プログラムを利用することも可能である。その収益をユーザーとシステム提供者が分け合うことで、システム運営に必要な収益が可能となる。

＜その他＞ 刊行物での明証化では、一つのハッシュ値を公表すれば足りる。すなわち、図２のような新聞広告は、図２６に示したような８８文字にBase64でエンコードされた５１２ビットのハッシュ値に、提供元の表示のみで十分な機能を果たす。この場合、必要な情報の詳細は、ハッシュ値の原像であるリストファイルに記載しておく。その具体例を図２７に示す。ここでは、図２の新聞広告との関係と、リンク情報の代表値が記載されている。

ここでは、複数のリンク情報代表値が記載されている。これにより、リンク情報を複数のチェーンに分割することで、サイバーネームのメッセージの信頼性によって組み込むチェーンを区別することができる。例えば、信頼性の高いメッセージのチェーンは、日付認証の精度が高くなる。一方で、登録直後やランキングの最下位のサイバーネームに関しては、一つのチェーンに纏める。また、全体のメッセージの数が大きくなった場合に、リンク情報を複数のチェーンに分割することで、照合データの量を小さくする効果もある。

この実施例に関わる識別名管理システムは、実施例１の特徴に加えて、更に公開鍵の変更を可能とする実装が含まれている。実施例１では、ある発言の認証を検証する場合には、そのサイバーネームの登録日から公開鍵の公表データを確認することになる。実施例２では、公開鍵が変更されているので、変更の前と後とでは別の公開鍵を使用する必要がある。勿論、公開鍵の有効期限を過ぎている場合には、変更は許可されない。

実施例２では、図２８に示したようなサイバーネーム管理テーブル６１ｂを用いる。ここでは、実施例１と同様に、サイバーネームの登録日はユーザー公開鍵（Kup_1）の登録日（Registration）となっている。サイバーネーム管理テーブル６１ｂには、第２のユーザー公開鍵（Kup_2）や第３のユーザー公開鍵（Kup_3）が含まれているが、サイバーネームの登録の際には、そのフィールドはNULLとなっている。また、それらの有効期限（Expiration_2、Expiration_3）もNULLに初期化されている。

ここで、ユーザー公開鍵を変更するには、新たな公開鍵をそのユーザーから受け取り、第２のユーザー公開鍵（Kup_2）のフィールドに格納する。また、ユーザー公開鍵（Kup_1）の有効期限（Expiration_1）フィールドを、変更した日付で上書きすると共に、ユーザー公開鍵（Kup_2）の有効期限（Expiration_2）に、所定の日付（例えば、変更日から１年後）を書き込む。サイバーネームと公開鍵（Kup_2）との対応データの新聞広告への公表は、上記登録や更新と同様である。

更に、ユーザー公開鍵を変更するには、新たな公開鍵をそのユーザーから受け取り、第３のユーザー公開鍵（Kup_3）のフィールドに格納する。また、ユーザー公開鍵（Kup_2）の有効期限（Expiration_2）フィールドを、変更した日付で上書きすると共に、ユーザー公開鍵（Kup_3）の有効期限（Expiration_3）に、所定の日付（例えば、変更日から１年後）を書き込む。サイバーネームと公開鍵（Kup_3）との対応データの新聞広告への公表は、上記登録や更新と同様である。

この例では、公開鍵の変更は二回までであるが、ユーザー公開鍵と有効期限のフィールドを追加すれば、更に変更回数を増やすことは可能である。

認証の確認は、実施例１と同様に、図１１のような発言リストを表示させ、内容を確認すれば良い。これは、管理サーバーで署名を確認していることを意味する。更に客観的にユーザー側で立証するには、まず登録日（Registration）や有効期限（Expiration_1、Expiration_2）を参照し、当該メッセージがどの公開鍵に対応するかを確認する。例えば、発言日が有効期限（Expiration_1）と有効期限（Expiration_2）の間にあれば、ユーザー公開鍵（Kup_2）が利用出来るということが分かる。

次に、有効期限（Expiration_1）に対応する新聞広告の公表データに基づいて、対応するリストファイルからユーザー公開鍵（Kup_2）を確認する。そして、このユーザー公開鍵（Kup_2）で当該メッセージの署名を検証すれば良い。

ユーザー公開鍵の変更が必要となる事例としては、対応する秘密鍵の漏洩が考えられる。漏洩が疑われる場合、直ちに変更することが望ましい。秘密鍵による本人確認はできないので、この実施例では別の手段が実装されている。

サイバーネーム管理テーブル６１ｂには、鍵変更ハッシュ（CK Hash）フィールドが含まれている。最初にサイバーネームを登録する際に、ユーザーはハッシュ関数（SHA-256など）で乱数を数回（ここでは２回）処理した結果を、管理サーバーへ鍵変更ハッシュとして登録する。この乱数は変更の際にのみ必要なので、印刷状態でのみ保存するなど安全に保管しておく。

ユーザーがユーザー公開鍵（Kup_2）への鍵変更要求を行うには、鍵変更ハッシュ（CK Hash）の原像を添付しておく必要がある。管理サーバーは、原像をハッシュ関数で処理し、鍵変更ハッシュと一致した場合に、ユーザー公開鍵（Kup_2）への鍵変更を行う。同様に、ユーザーがユーザー公開鍵（Kup_3）への再度の鍵変更要求を行うには、鍵変更ハッシュの原像の原像（すなわち最初の乱数）を添付しておく必要がある。管理サーバーは、原像をハッシュ関数で２度処理し、鍵変更ハッシュ（CK Hash）と一致した場合に、ユーザー公開鍵（Kup_3）への鍵変更を行う。

上記実施例では、公開鍵や署名を管理するためのサーバーが不可欠であるが、メッセージに直接署名を付加するようにしても良い。この場合、ローカルの署名検証プログラムだけで実装することが可能となる。この例では、以下の機能が署名検証プログラムとして実装される。

ユーザーがメッセージに署名を付加するには、秘密鍵が必要である。従って、鍵生成機能が実装される。鍵生成機能では、秘密鍵と公開鍵がペアで生成される。また、秘密鍵を用いて署名を生成する署名生成機能が実装される。更に、メッセージに付加されている署名を検証する為の署名検証機能も不可欠である。更に、秘密鍵や公開鍵をローカルで管理する機能も実装される。更に、公開鍵をネットワーク等から取得する機能も実装される。

＜操作手順＞ 以下、ユーザーが行う操作を順に説明することで、署名検証プログラムの利用法やインターフェイスの概要を記述する。各処理の詳細については後述する。ここでは楕円曲線暗号の１つであるＥＣＤＳＡを利用する。また、サイバーネームは、ユーザーが任意に選択できるコアネームと、先頭に付けられたドルマーク「$」と、「*」をbase64の文字として「_***」の形式のサフィックスとからなる。

署名検証プログラムが起動すると、最初に暗号化された秘密鍵を含む個人鍵ファイル（後述）がハードディスクに存在するか否かを確認する。簡単な方法としては、署名検証プログラムと同じフォルダの特定のファイル名へのアクセスを行えば良い。例えば、初めての使用などでは個人鍵ファイルは存在しない。存在しない場合には、図２９に示したようなダイアログを表示する。勿論、ファイル自体があっても、秘密鍵を含まないようなら、存在しないとみなす。

このダイアログによる鍵生成では、ＥＣＤＳＡのアルゴリズムとして、ＳＥＣＧ標準の１つであるsecp160r1をパラメータに固定している。secp160r1の鍵長は１６０ビットであるが、より長い鍵長は別の詳細設定ダイアログ（図３０参照）によって生成できる。なお、ＥＣＤＳＡでは、同じ長さの鍵長でも、複数の異なる暗号方式が利用できる。これらは楕円曲線に名称を付して区別したりするが、ここでは番号nIDで指定する。

また、図２９に示したダイアログは、コアネーム入力用のボックスと、パスワード入力用のボックスが含まれている。ユーザーは、好きな名前（文字列）を決めてコアネーム入力用ボックスに入力する。また、パスワードも決めてパスワード入力用ボックス入力する。

その後、ユーザーはOKボタンをクリックする。すると、署名検証プログラムは、秘密鍵と公開鍵を生成して、サフィックス「_qv2」を追加する。また、先頭に文字「$」を追加して、公開鍵に対応する識別名であるサイバーネーム（$Suzuki_qv2）を構成する。この「qv2」は、生成された公開鍵をbase64でエンコードし、得られた文字列の３番目の文字から５番目の文字までの３文字である。文字「$」とこのサフィックス導入の意味は後述する。

そして、署名検証プログラムは、インターネット上で同一のサイバーネームが利用されているか否かを検索する。実際には、検索エンジンを用いて、サイバーネームの文字列を検索してヒットしなければ利用されていないと判断する。その具体的な方法は後述する。

もし、文字列がヒットすれば、同一のサイバーネームが利用されている可能性があるので、秘密鍵と公開鍵を再度生成して、サフィックスを変更する。サフィックスの変更は、この文字列検索がヒットしなくなるまで繰り返す。実際には、サフィックスは３文字の乱数なので「$(ユーザー選択コアネーム)_***」という文字列としては、ヒットする可能性は非常に低い。サフィックスを変更した場合には、ユーザーにその旨を通知しておく。

サイバーネームのフォーマットとしては、ユーザーが任意に選択するコアネームに、ランダムな文字列を特殊文字を挟んで連結することで、インターネット上でユニークであるようにできる可能性が高くなる。ここで特殊文字とは、アルファベット、仮名や漢字といった表音文字や表意文字に入らない記号類のことである。

その後、署名検証プログラムは、公開鍵をインターネット上に公開する為のメッセージをクリップボードにコピーして、図３１に示したようなダイアログを表示する。メッセージは、公開鍵情報であることを示すキーワード「$Pblkey」に、丸括弧で括った楕円曲線暗号のパラメータの種類を示す番号nIDと、base64でエンコードされた公開鍵と、鍵括弧で括ったサイバーネームとが並んだ文字列を含んでいる。

図３１で、「$Pblkey」から鍵括弧で括ったサイバーネームまでが公開鍵情報となっている。ユーザーはこの公開鍵情報を、インターネット上の任意のサイトに公開する（図３２参照）。公開するサイトは、SNS, BBS, blogなどで良いが、永続性がない場合には適宜再度公開を行う。また、生成された秘密鍵と公開鍵は、番号nIDおよびサイバーネームと関連付けて、ローカルに保存しておく。ただし、秘密鍵はパスワードで暗号化してからハードディスクの署名検証プログラムと同じフォルダに特定のファイル名で保存する。これが既に述べた個人鍵ファイルである。

ユーザーが署名する手続きは次の通りである。署名には、秘密鍵が必要であるが、ハードディスクに保存されている個人鍵ファイル内では暗号化されているので、そのままでは署名できない。そこで、上記鍵生成の処理の直後は、署名検証プログラムが終了するまでの間、メモリ上の変数として平文の秘密鍵を保持しておく。

また、署名検証プログラムを再度実行した際に、暗号化された秘密鍵のファイルがハードディスクに存在していれば、図３３のようなダイアログを表示して、パスワードの入力を促す。ここで入力されたパスワードを用いて秘密鍵を複合し、署名検証プログラムの実行中はメモリ上に保持することで署名をできるようにする。このダイアログでパスワードを入力せずにキャンセルすると、署名の度にパスワードの入力が求められる。

ユーザーは、先ず署名を行いたいメッセージを作成する。例えば、ＷＥＢページの入力ボックス、あるいはワープロやエディタなどで「子ども手当2-3000円増額は、大歓迎です。」と打ち込む。その全体をクリップボードにコピーしてから、画面に表示してあるアイコンをクリックする。この実施例では、アイコンはタスクトレイに表示されている署名検証プログラムのペンマークのアイコンである（図３４）。

クリックによるイベントを受けると署名検証プログラムは、クリップボード内のデータを確認して、署名が付加されていないメッセージならば、その署名を作成する。そして、サイバーネームと共にクリップボードにコピーする（図３５）。ユーザーがクリップボードの内容をメッセージの末尾に貼り付けると署名付きメッセージとなる。この署名付きメッセージを図３６のような入力ボックスに貼り付けて、利用できる。

ここで、サイバーネームと署名本体はコロンで区切られている。もしも、画面に表示してあるアイコンをクリックした際に、クリップボードのテキストが署名付きのメッセージであれば新たに署名を生成するのではなく、付けられている署名の検証を行い、その結果を表示する。具体的には、テキストの末尾に、サイバーネーム＋コロン＋（base64の所定長の文字列）があれば、署名検証プログラムは署名付きのメッセージと解釈する。

従って、ユーザーが、ウェブページを閲覧していて、署名付きのメッセージの書き手を確認（署名検証）したいと思えば、署名生成の時と同様に、クリップボードにコピーしてから、画面に表示してあるアイコンをクリックする。すると、署名の検証結果が表示される。もし、検証に成功したら、検索ボタンで同じ署名（人物）の情報を検索できる（図３７）。なお、検証に必要な公開鍵の取得方法は後述する。

＜鍵生成＞ ECDSAでは秘密鍵は一定ビットの乱数で表される。上記の例では鍵長１６０ビットなので、２０バイトの数値となる。一方、公開鍵は楕円曲線上の点であり、４０バイトの数値となる。この実施例では圧縮表現を用いているので２１バイトの数値となる。これをBASE64で変換すると、秘密鍵は２７文字、公開鍵は２８文字の文字列となる。BASE64では、バイト表現との整合性から文字数を４の倍数とすることになっているので、秘密鍵では'='でパディングを行い２８文字の文字列となる。なお、署名は鍵長の数値のペアで表現され、４０バイトの数値となる。従って、BASE64では５４文字に'=='でパディングを行い５６文字となる。しかし、ここではできるだけ署名長を短くする為に、冗長なパディングは省略するものとする。なので、鍵長１６０ビットでは、署名長は５４文字となる。

署名検証プログラムでは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」であり、３番目の文字から５番目の文字までの３文字を取ると決めてある場合、サフィックスは「_ohj」となる。どの位置の文字でも利用できるが、ＥＣＤＳＡでは、圧縮された公開鍵の最初の文字には偏りがあるので避けたほうが良い。

３文字を乱数と考えれば、その組み合わせは262,144通りある。実際には、完全な乱数ではないが、後続の任意の文字列との組み合わせで考えると偶然に一致する可能性は極めて低くなる。また、サイバーネームの決定にあたっては、インターネット上でユニークであるか否かを確認するので、CyberNameは常にユニークと考えられる。ここでも先頭のドルマーク（$）に３文字の擬似的な乱数にアンダーバー（_）を付けたサフィックスをサイバーネームを連結し、全体を「"」で括って検索タームとするが、そのことがユニークという点で有効に機能する。

にもかかわらず、誰かが自分と同一のサフィックス付きCyberNameを使っている場合、それは偶然又は過誤とは考えにくく、なりすましと判断される。ただ単に、同一のCyberNameを使った場合、公開鍵との整合性が取れないので、なりすましの公開鍵がどちらであるかは容易に判別される。署名検証プログラムでは、検証を行う際に、公開鍵とサフィックスとの整合性をチェックする。もしも、整合性が無ければ、その公開鍵が不正な目的で生成された可能性が高いことを警告する。

若干の技術的な知識があれば、それなりの手間がかかるものの、サフィックスも含めて完全に同一のCyberNameに対して整合性のとれた異なる公開鍵を生成することも可能ではある。しかし、なりすましの署名では、本家の公開鍵で検証できないので、なりすましを行う意味は非常に小さい。

署名検証プログラムでは、署名付きメッセージの検証を行う場合、サイバーネームを「"」で括って第１の検索タームとし、更に"$Pblkey"を第２の検索タームとして、AND検索を行う。これにより、公開鍵情報が実際に公開されていれば、ほぼユニークにヒットする。

＜ファイルへの署名＞ ファイルへの署名は次のような手順で行うことができる。先ず、ファイルの説明文を作成する。例えば、「電子署名ソフトを開発しました。ハッシュ値は以下の通りです。皆さん使ってみてください」といった文章を作成する。そして、当該ファイルのハッシュ値をBase64でエンコードした文字列を説明文の中に入れて、上記の通りの方法で、説明文に署名を付ける。ここではハッシュ値はＳＨＡ２５６とする。

ハッシュ値の文字列の算出は、例えば、次のような手順で行うことができる。先ず、そのファイルへのリンクをコピーする。Windows（登録商標）であれば、ファイルエクスプローラーで当該ファイルを選択してコピーすれば良い。次に、画面に表示してあるアイコンをクリックする。これでハッシュ値の文字列がクリップボードに格納されるので（図３８）、説明文の中に貼り付ければよい。ここでクリップボードに格納されるハッシュ値の文字列は、キーワード「SHA256:」の後に連結される。例えば、説明文は、図３９のようなものになる。

このようなメッセージの検証は、次のように行われる。既に述べた手順に従って、署名を含めたメッセージ全体をクリップボードにコピーする。そして、画面に表示してあるアイコンをクリックすると、それに応答して署名検証プログラムは署名の検証を行い結果を表示する。ここで、検証に成功したメッセージ本文にキーワード「SHA256:」とそのハッシュ値の文字列が検出されていれば、画面の表示は図４０に示したようなものになる。

この画面表示は、ユーザーからのファイル選択を受け付けるようなものである。この例では、ユーザーがドラッグ・アンド・ドロップ操作でファイル選択を行うと、署名検証プログラムはドロップされたとファイルのハッシュ値を算出しメッセージ本文に含まれているハッシュ値と比較する。一致していれば図４１に示したような画面を表示し、一致していなければ図４２に示したような画面を表示して、ドロップされたファイルが署名されたものかどうかを通知する。

従って、署名検証プログラムでは、アイコンがクリックされるとクリップボードの中身を調べる。ファイルへのリンクであれば、ファイルのハッシュ値の文字列を算出してクリップボードに格納し、その旨の表示を行う。もし、署名が付加されているテキストであれば検証を行い結果を表示する。その際、メッセージにハッシュ値の文字列が含まれていれば、上記の通りローカルのファイルの検証を可能とする。もし、署名が付加されていないテキストであれば、既に述べた手順に従って署名を生成してクリップボードに格納し、その旨の表示を行う。

＜署名の効果＞ ここで付加される署名には対応する公開鍵に対して電子証明書が存在しない為、このままでは何かが保証されるというものではない。同じ公開鍵で同値関係が確立された署名は、対応するメッセージ内容によって互いに保証しあう。例えば、優良な情報や魅力的な内容の発信を繰り返す署名は、内容的に信頼出来ると判断される。新たな情報に、このような署名が付加されていれば、それは信頼出来る一つの目安となり得る。逆に、情報発信力という意味で、その署名の価値は高いと言える。

署名検証プログラムでは、署名の信頼性を評価する為に、署名の検証結果を表示ダイアログ（図３７）に検索ボタンを設けている。このボタンを押せば、同一サイバーネームの検索が行われる。上記の通り、サイバーネームはユニークと考えられるので、検索結果には同じ署名の発信情報が列挙されることになる。これは、署名付きメッセージの信頼性を評価する上で一つの有効な材料となり得る。

しかし、なりすまし署名が付加された発信情報も含まれている可能性もあるので、署名検証プログラムでは、検索結果から個々の署名を検証して検証に失敗する情報があれば表示を変えるようにしている（実際には表示フォントを赤にしている）。検索結果のリストから検証に失敗する情報をすべて削除することもできるが、当初の署名自体がなりすましということもあるので、表示を変えるようにした。

ここでの署名と公開鍵との関係は、従前とは逆転しているとも言える。すなわち、これまではメッセージに署名を付けて、メッセージの出自を署名が証明し、この署名の出自を公開鍵が証明し、公開鍵の出自を電子証明書が証明し、この電子証明書の出自を認証局が証明するという手順となっている。従って、認証局から電子証明書を発行してもらうには、面倒な手続きと一定の費用が必要となる。

これに対して、この発明では何も要求されず、ただ署名を行うだけである。メッセージの価値が、署名の価値を証明し、公開鍵の価値を署名が証明するといったようなものである。この関係を図４３に示す。もし、メッセージの質が低いということであれば、公開鍵の価値を貶めることになる。従って、良質のメッセージが増加するというメリットも期待できる。

実施例３では、暗号化されてはいるが、個人鍵ファイルがローカルのＰＣに保存される。従って、マルウェアなどに感染して個人鍵ファイルが外部に流出するということもありえる。その場合、パスワードでは十分な強度は期待できないので、総当たり攻撃や辞書攻撃で秘密鍵が知られてしまう可能性がある。この実施例４では、署名を別のネットワーク接続で行うことで、そのような危険を回避する。署名の生成以外は、この実施例の処理は上記実施例３と共通する部分が多い。以下、実施例３と異なる部分について説明を行う。

ここでは署名処理を仲介する仲介サーバーを設ける。この仲介サーバーは、識別番号に関連付けてメッセージ等のデータを保存する機能を有する。データと共に登録依頼を受けると、受け取ったデータを一時的に登録し、識別番号を返す。また、識別番号と共にデータ照会依頼を受けると、識別番号に対応するデータを返す。更に、識別番号および更新データと共に更新依頼を受けると、受け取ったデータで識別番号に対応するデータを更新する。

なお、このデータベースは、単純なリングバッファであり、古いものから上書きされていく構造となっている。従って、数分程度でデータへのアクセスはできなくなる。このような短期記憶手段としての実装は、速度面で有利というだけではなく、セキュリティという点でも望ましいものである。なお、この例では、識別番号として６桁の数値を用いる。

この実施例での署名処理は、携帯端末と連携して行われる。従って、携帯端末側には連携アプリがインストールされる。ＰＣを操作し、署名検証を行うユーザーが、この携帯端末を手元に持っているものとする。連携アプリには、ＱＲコード（登録商標）といった二次元コードの読み取りと、仲介サーバーとの通信と、ハッシュ値の署名を生成する機能が含まれている。

鍵生成は上記実施例３と同じであるが、生成した後は、サイバーネーム、番号nIDおよび公開鍵のみをＰＣ側に保存する。一方で、秘密鍵は番号nIDと共に、二次元コードとして画面に表示する。この二次元コードを携帯端末で読み取り、携帯端末側で秘密鍵と番号nIDを保存する。ＰＣ側では秘密鍵を保持しない。

図４４を参照して、実施例４での署名処理を説明する。ユーザーは、メッセージをクリップボードに格納し、やはりアイコンをクリックする。そして、署名検証プログラム７１Ａがサイバーネームを付加し、ハッシュ値（ＳＨＡ２５６）を算出する。ここまでは実施例３と同じである。この後、実施例３では、ローカルのＰＣでハッシュ値に対する署名を生成するのであった。しかし、この実施例４では、以下の通り、携帯端末側で署名を生成する。

先ず、署名検証プログラム７１Ａが、メッセージの登録依頼を仲介サーバー７０に依頼する。ここでのメッセージは、上記の通り本文とサイバーネームとコロンである。仲介サーバーは、登録依頼を受付けて、６桁の識別番号を返す。識別番号は乱数として生成されるので、暗証番号としての機能もある。署名検証プログラム７１Ａはこの識別番号をダイアログ画面に表示する。ユーザーは、手元の携帯端末で連携アプリ７１Ｂを起動して、この識別番号を入力する。

そして、連携アプリ７１Ｂは、仲介サーバーに対して、この識別番号と共にデータ照会を行う。仲介サーバーは対応するメッセージを返す。連携アプリ７１Ｂでは、受け取ったメッセージを表示するので、ユーザーはそれを確認してからOKボタンを押す。すると、連携アプリ７１Ｂは、そのハッシュ値に対する署名値を算出して、更新データとして識別番号と共に仲介サーバーへ送信する。仲介サーバーは、受け取ったデータによって識別番号に対応するデータを更新する。

その後、ユーザーがＰＣ側のダイアログを閉じると、署名検証プログラム７１Ａは、仲介サーバーに対して識別番号と共にデータ照会を行う。そして、更新データとして署名値を受け取る。もし登録したメッセージが返されたら未更新なので、時間をおいて再度データ照会を行うようにする。

このようにすることで、ＰＣがマルウェアに感染したとしても、ＰＣ側には存在しない秘密鍵が漏洩する心配はない。また、トロイの木馬でＰＣの通信を傍受したり制御したとしても、携帯端末へ接続することはできない。署名には携帯端末での操作が必須なので、不正に署名をされてしまうこともない。

一般に携帯電話ではマルウェアの被害は非常に少ない。しかし、近年、特にスマートフォンなどではセキュリティの問題が大きくなってきている。万一、携帯端末から、秘密鍵が漏洩した場合、知識と技術があれば公開鍵を算出することは容易である。公開鍵が分かれば、サイバーネームとの関連付けもされてしまう可能性がある。実施例６では、携帯端末から、秘密鍵の漏洩を防止する対策を講じる。

利便性を考慮して、実施例４では秘密鍵は暗号化していない。パスワードでの暗号化を行ったとしても、暗号化秘密鍵が抜き取られれば、パスワードはユーザーが覚えやすい文字列なので辞書攻撃などで突破される可能性は低くない。ここでは、パスワードではなく十分な長さ（例えば秘密鍵と同じ長さ）の乱数を用いて秘密鍵を暗号化する。以下、実施例４と異なる部分のみを説明する。

最初にＰＣ側で鍵ペアを生成するが、同時に十分な長さの乱数（例えば、２５６ビット）も生成する。この乱数と秘密鍵との排他的論理和を算出して暗号化秘密鍵とする。この暗号化秘密鍵を、二次元コード経由で携帯端末で保存するようにする。ＰＣ側では、公開鍵とこの乱数を保持する。そして、携帯端末で署名を生成する際には、その都度仲介サーバー経由でメッセージと共に乱数も送信する。従って、携帯端末側では、暗号化秘密鍵とこの乱数との排他的論理和を用いて秘密鍵を複合し、メッセージに署名すれば良い。

この場合、ＰＣ側で公開鍵と乱数が漏れても、そこから秘密鍵を算出することは不可能である。また、暗号化秘密鍵も無意味な乱数と考えられるので、携帯端末からどのような情報が漏れても問題はない。

実施例６では、署名検証プログラム７１Ａに更に次のようなオプションも追加される。すなわち、メッセージがあまり長くない場合、例えば２５６バイト以内なら、ＰＣ側では、二次元コードで全文を表示する。これを携帯端末の連携アプリ７２Ｂで読み取って、ハッシュ値そして署名値を算出する。

連携アプリでは、これらハッシュ値と署名値を仲介サーバーに登録する。このハッシュ値は識別番号として登録される。ＰＣ側では、別途ハッシュ値を算出し、これを識別番号として仲介サーバーにデータ照会を行ない、署名値を取得する。

実施例４、５、６では、携帯端末側でメッセージを取得するので、ユーザーは署名の前にメッセージを確認できる。しかし、メッセージの代わりに署名を行うハッシュ値のみを取得し、めくら判を行うようにしても良い。その場合は、次のような処理になる。

先ず、ハッシュ値の二次元コードをＰＣの画面に表示する。次に、携帯端末の連携アプリが、この二次元コードを読み取り、ハッシュ値に対応する署名を算出する。そして、そのハッシュ値と署名を仲介サーバーに登録する。やはりハッシュ値は識別番号として利用される。ＰＣ側では、ハッシュ値を識別番号として仲介サーバーにデータ照会を行ない、署名値を取得する。

実施例４のプロセスを応用して、ユーザー登録の行われたサイトにおける認証手続きにおいて、携帯端末をセキュリティトークンのように利用することもできる。例えば、オンラインバンキングなどでは、ユーザーＩＤとパスワードでログオンを行うことも多いが、更に次のようにして手元の携帯端末を利用して、セキュリティを高めることが出来る。勿論、オンラインバンキング以外にも、認証手続きを用いた一般のログオンに上記方法を利用することが可能である。

やはり、携帯端末には専用のアプリをインストールしておく。図４５を参照すると、先ず、ＰＣ側のブラウザ７２Ａで、サイトの認証サーバー７２にアクセスして、ユーザーＩＤとパスワードでログオンを行う。そして、公開鍵の登録を行うページを開く。

認証サーバー７２は、認証の為の１２８ビットの乱数（nonce）を生成してブラウザ７２Ａへ送信する。また、認証サーバー７２は、この乱数をユーザーＩＤに関連付けてリングバッファ７２Ｒに保持する。ブラウザ７２Ａは、この乱数を二次元コードで表示する。ユーザーは手元の携帯端末で連携アプリ７２Ｂを起動して、この二次元コードを読み取る。また、連携アプリ７２Ｂは、ＥＣＤＳＡの鍵ペアを生成し、その公開鍵を上記乱数とともに認証サーバー７２へ送信する。

認証サーバー７２では、受信した公開鍵に、その乱数に対応するユーザーＩＤに関連付けて、リスト７２Ｌに登録する。そして、登録完了の通知を連携アプリ７２Ｂに送信する。連携アプリ７２Ｂは登録完了の表示を行う。なお、パラメータを決める番号ｎＩＤは予め統一すれば、特に個別に記録する必要はない。

登録が完了した後は、携帯端末を用いた認証手続きによってログオンが可能となる（図４６）。先ず、ブラウザ７２Ａで認証サーバー７２に接続して、この方法による認証画面を表示する。認証サーバー７２では、認証の為の１２８ビットの乱数（nonce）を生成する。ただし、上位２０ビット（＜１０４８５７６）が十進法で７桁となったら、６桁の乱数となるまで生成を繰り返す。そして、その上位２０ビットを識別番号としてブラウザ７２Ａへ送信する。また、認証サーバー７２は、この乱数をユーザーＩＤに関連付けてリングバッファ７２Ｒに保持する。

ＰＣ側の認証画面では、認証サーバー７２から送られた６桁の識別番号をダイアログ画面に表示する。これは図４４に示したものと同様である。

ユーザーは、手元の携帯端末で連携アプリ７２Ｂを起動して、この識別番号を入力する。すると、連携アプリ７２Ｂは、認証サーバー７２にアクセスして、この識別番号を送信する。認証サーバー７２は、この識別番号を上位２０ビットに持つ乱数がリングバッファ７２Ｒにあれば、１２８ビットの乱数全体を、連携アプリ７２Ｂに送信する。

連携アプリ７２Ｂは、受け取った乱数の署名値を算出して、認証サーバー７２に送信する。認証サーバー７２では、この署名値の検証に成功すれば、ＰＣをユーザーＩＤに対応する正規のユーザーとして認証する。

なお、認証においても、識別番号ではなく認証の為の乱数全体をブラウザ７２Ａで二次元コードで表示し、これを携帯端末の連携アプリ７２Ｂで読み取って、その署名値を認証サーバー７２に送信するようにしても良い。認証サーバー７２では、この署名値を検証して成功すれば、ＰＣをユーザーＩＤに対応する正規のユーザーとして認証する。

ＥＣＤＳＡでは、与えられたパラメータを用いて鍵ペアを生成する際に、まず鍵長の乱数（正確にはパラメータとしての位数ｎよりも小さい正の乱数）を生成して秘密鍵とする。この秘密鍵から公開鍵が算出される。

実施例９では、秘密鍵として乱数ではなくハッシュ値を利用する。この場合、乱数に比較して強度が下がる可能性がある。従って、鍵長を長めに設定すると良い。ここでは２５６ビットとする。その他の構成は上記実施例３乃至実施例８のいずれかと同一とするが、それに限らず秘密鍵を自由に設定できるアルゴリズムによる電子署名一般に利用できる。ハッシュ値の原像には、任意のメッセージに乱数を連結したものにする。以下、一つの応用例を示す。

本発明による署名は匿名でも可能であることが一つの特徴となっている。しかし、どうしても本人であることを確認したいという場合もあるかもしれない。そのような自体に備えて、秘密鍵の所有者を特定する情報の書かれたテキストをメッセージとして、これに乱数を連結し、ハッシュ値を算出して秘密鍵としておくことができる。

例えば、「東京都千代田区千代田１−１日本太郎A33MGzOwOUzjJwpz8l+jvRT9ZL48DTEVFQ+2mGOL8ptl」といったテキストとする。ここで乱数はBase64でエンコードしてある。ＳＨＡ２５６でこのテキストのハッシュ値を算出して、秘密鍵とする。ハッシュ値が位数ｎよりも大きくなったら乱数を変更して再度ハッシュ値の算出を行う。原像のテキストは漏洩しないように保管しておく。好ましくは、紙に印刷するなどして、ＰＣにデータとして保存することは避ける。通常は使用しないので、そのような保管で十分である。

具体的な手順の例としては、図３０の詳細設定画面において、埋め込みメッセージのボックスに「東京都千代田区千代田１−１日本太郎」と入力して、「生成」ボタンを押す。すると、署名検証プログラムは２５６ビットの乱数を生成して、ボックスのテキストを「東京都千代田区千代田１−１日本太郎A33MGzOwOUzjJwpz8l+jvRT9ZL48DTEVFQ+2mGOL8ptl」に更新する。そして、このテキストのハッシュ値を算出して秘密鍵とし、それにパラメータの一つである生成元を用いて公開鍵を算出する。これらの秘密鍵と公開鍵は、夫々のボックスに表示する。

サイバーネームとパスワードを入力し「保存」ボタンを押すと、サイバーネームと、ｎＩＤと、公開鍵と、パスワードで暗号化された秘密鍵が保存される。「印刷」ボタンを押すと、サイバーネームと、ｎＩＤと、公開鍵と、平文の秘密鍵と、乱数の付加された埋め込みメッセージが印刷される。

原像のテキストを公表しない限り、乱数を用いた場合と署名の利用シナリオはこれまでと全く同一である。公表する場合に奏する効果の例としては次のようなものが考えられる。

日本太郎は「$Suzuki_qv2」というサイバーネームでインターネット上の様々なサイトで情報の発信を行なっている。ネット上の活動は全てサイバーネームで行い、事実上匿名である。ある時、オリジナルの映像作品を制作して動画投稿サイトに署名付きで投稿した。映像作品は話題となり、「$Suzuki_qv2」の存在感は高まった。しかし運悪く、それと前後して秘密鍵が漏洩してしまった。

一方で、その映像作品に着目した企業が、その買取を希望した。ところが、秘密鍵は漏洩しているので「$Suzuki_qv2」という人物が多数その企業に現れた。どの人物も正規の署名を行うことができた。しかし、日本太郎は、自分が秘密鍵の正規の所有者であることを示す証拠として、ハッシュ値の原像を用いることができた。

この場合は、自身の個人特定情報を組み込んで署名をした有益な情報提供に対して、著作権を主張する目的で秘密鍵を用いている。これに対して、次のようなネガティブなケースも有り得る。例えば、他人の個人特定情報を組み込んだ署名を伴う有害な情報提供を行い、この情報提供が当該他人によるものである証拠として原像を公表するといった場合である。目的は、他人の名誉の毀損である。しかし、このような行為は誰でも可能なので、証拠能力はないことは明らかである。

いずれにせよ正しく用いた場合には、少なくとも本人が主張する限りにおいて、自分の権利を主張するための一つの証拠となり得る。ただし、それには秘密鍵を開示しなければならず、その後の署名について支障をきたす可能性もある。このような場面では、秘密鍵の開示の前に、新たな鍵ペアを生成して、開示前の秘密鍵を用いて新規の公開鍵に対して署名して、切り替えを宣言すれば良い。訴訟などではインカメラ審理といったことも有り得るかもしれない。

図４７に示したように、この方法はネストが可能性である。例えば、「東京都千代田区千代田１−１在住の日本太郎が、２０１２年７月１日にこの署名の利用を開始した。」というテキストの末尾に乱数を連結した文字列のハッシュ値ｈ１を、再び「日本太郎が、２０１２年７月１日にこの署名の利用を開始した。」というテキストの末尾に連結してこれのハッシュ値を秘密鍵とする。上記の通り、秘密鍵と「日本太郎が、・・・開始した。」＋ハッシュ値ｈ１を示すことで、先ず「日本太郎」であることを証明できる。必要があれば、本人（最初の乱数とメッセージを知る者）のみが「東京都千代田区千代田１−１」を開示できる。この場合、最初の乱数と途中のメッセージは、紙に印刷するなどして、保管しておく。なお、ハッシュ値のビット数よりも秘密鍵のビット数が大きい場合には、適宜乱数で補完しておく。

以上のように、本発明による識別名管理システムは、インターネット上での個人による情報発信の量と質を向上させるのに大変有用である。

１０ 管理サーバー
２３ 署名用メッセージ
５５ 認証データ（ＵＲＬ）
６１ サイバーネーム管理テーブル
６２ メッセージ管理テーブル
６３ リンク情報の代表値
７０ 仲介サーバー
７１Ａ 署名検証プログラム
７１Ｂ 連携アプリ
７２ 認証サーバー
７２Ａ ブラウザ
７２Ｂ 連携アプリ

本発明は、インターネットにおいて、一般ユーザーが容易に電子署名を利用できるようにする為の署名検証プログラムに関するものである。

上記課題を解決するために、本発明の署名検証プログラムは、コンピュータ上に実装される署名検証プログラムであって、ユーザーがメッセージに署名をする際には、メッセージ本文を構成する文字列を受信し、前記文字列に対する電子署名を生成し、前記電子署名に対応する文字列を生成し、前記メッセージ本文を構成する文字列に、前記電子署名に対応する文字列を連結し署名付文字列を生成し、また、ユーザーがメッセージを検証する際には、前記署名付文字列を受信し、前記電子署名の検証を行い、前記検証結果を表示し、前記電子署名と同じ秘密鍵により生成された電子署名がなされている他の署名付文字列を表示し、前記署名付文字列は、アプリケーションでコンピュータ画面に表示され、ユーザーが閲覧する文字列であることを特徴とする。

Claims (5)

1. 識別名を検索タームとして、インターネット上に公開された情報から対応する公開鍵を取得し、
   上記公開鍵によって、上記識別名を含むテキスト情報に付加された署名を検証し、上記テキスト情報の出自が、上記公開鍵および上記識別名に帰着されるか否かを確認することによって
   上記公開鍵および上記識別名によって、上記テキスト情報の同値関係を確立することを特徴とする識別名管理方法。
2. 上記識別名は、任意に選択される文字列であるコアネームと、このコアネームに連結されたランダムな文字列とからなる識別名管理方法。
3. 上記ランダムな文字列は、上記識別名がインターネット上でユニークであるように選択される識別名管理方法。
4. 上記コアネームとランダムな文字列は、特殊文字を挟んで連結されている識別名管理方法。
5. 上記識別名は、更に先頭に少なくとも１つの特殊文字が付加されている識別名管理方法。

Images