JP2017092713A - 匿名通信システムおよび該通信システムに加入するための方法 - Google Patents

Abstract

【課題】匿名性を保証し、必要に応じユーザを特定可能とし、社会的信頼性の高い匿名通信システムを提供する。【解決手段】ユーザコンピュータ１１は、他の通信システムで使用可能な第１署名鍵４１で署名した電子署名付き加入申込みデータ４３を管理者コンピュータ２１に送信する。管理者コンピュータ２１は、第１公開鍵５１で加入申込みデータ４３の電子署名を検証し、正当性を検証できた場合に第２署名鍵４２を生成し、暗号化してユーザコンピュータ１１に送信する。ユーザコンピュータ１１は、第１署名鍵４１および第２署名鍵４２で二重に署名された電子署名付き受領証データ４４を生成し、管理者コンピュータ２１に送信する。管理者コンピュータ２１は、第１公開鍵５１および第２公開鍵５２を用いて受領証データ４４の電子署名を検証し、正当性を検証できた場合に、その受領証データ４４を含むユーザデータを登録部２４に登録する。【選択図】図６

Description

本発明は、ユーザ同士が互いに匿名で通信を行いつつ、必要な場合にはユーザを特定することが可能な匿名通信システムに関する。

従来、インターネットにおいて、ユーザが通信相手を認証しながら安全に通信できる通信システムの構築は、その存亡にかかわる重要な問題であった。この問題への一つの解として、インターネットで利用できる認証システムである公開鍵基盤（Public Key Infrastructure，PKI，非特許文献１）が広く用いられている。

しかし、公開鍵基盤による通信システムでは、認証の際にユーザを特定する情報が必ず通信相手に開示されるため、必要でない場合にもユーザの識別情報を提示しなければ、認証ができないという問題があった。そこで、匿名性を高めた通信システムであるTor（特許文献１）や認証システムである簡易公開鍵基盤（非特許文献２）が実用に供され、また、仮名（Pseudonym）通信やグループ署名を用いた匿名認証の技術が提案されている。

特開２００４−２２９０７１号公報 特開２００８−２７８１４４号公報

ITU-T Recommendation X.509 The Directory - Authentication Framework IETF Request for Comments 2692 & 2693 Simple Public Key Infrastructure

しかし、簡易公開鍵基盤、仮名署名、グループ署名に基づく匿名通信では、匿名のまま通信システムに参加する方法がなく、通信経路上及び通信相手に対して匿名性が担保されても、参加時に身元を明かさなければならず、また、管理サーバーなどに実名が記録されているため実名が漏洩する危険があり、匿名通信システムとしては不完全なものであった。一方、Torでは、中間中継点が全て協力した時のみ追跡が可能であり、犯罪・テロなどの有事の際に通信者を特定することが事実上不可能であった。実際、Torを利用して外国の中継点経由で他人のPCを乗っ取り、警察の追及を免れた事例も発生している。

そこで、本発明の主要な目的は、通信経路及び通信相手に対して匿名性を保証する匿名通信システムにおいて、該通信システムへの参加を匿名で行えるにもかかわらず、有事の際には通信者を特定することを可能とする方法を提供する点にある。具体的には、他の（匿名）通信システムに参加しているという「信用」をベースに、匿名通信システムに参加する方法を提供する。あるコミュニティに参加しているという「信用」をもとに、別のコミュニティに参加するコミュニティ形成の形態は、実社会においては一般的であり、実社会との親和性が高い方法である。

上記課題を解決するために、本発明は、ユーザの匿名による通信を可能とする匿名通信システムであり、匿名のまま当該通信システムのユーザとして登録することが可能である一方、有事の際には通信者を特定できることを特徴とするシステムを提供する。この匿名通信システムは、ユーザが操作するユーザコンピュータと、当該匿名通信システムの管理者が操作する管理者コンピュータとを備え、ユーザコンピュータが、当該匿名通信システムとは別の通信システムで使用可能なユーザ固有の第１署名鍵と、当該匿名通信システムで使用するユーザ固有の第２署名鍵とにより二重に電子署名が付された署名付きデータを生成する手段を含み、管理者コンピュータが、第１署名鍵と対をなす第１公開鍵と、第２署名鍵と対をなす第２公開鍵を用いて電子署名を検証する手段と、この電子署名の正当性が検証されたときに、署名付きデータを含むユーザデータを登録するユーザデータ登録手段とを含むことを特徴とする。

本発明の一つの実施形態では、管理者コンピュータが、ユーザごとに異なる第２署名鍵を生成してユーザコンピュータに提供する手段を更に含む。本発明の別の実施形態では、ユーザコンピュータがユーザ固有の公開鍵ペアの秘密鍵を第２署名鍵として生成する手段を更に含み、管理者コンピュータが公開鍵ペアの公開鍵に対してユーザの識別情報を含まない匿名公開鍵証明証を発行する手段を更に含む。本発明の他の実施形態では、ユーザコンピュータが、第２公開鍵によって検証可能な第２署名鍵を管理者コンピュータとの通信を介して生成する手段と、第２署名鍵を管理者に対して秘密に保持する手段とを更に含む。

また、本発明の匿名通信システムでは、管理者コンピュータのユーザデータ登録手段に登録されるユーザデータが、ユーザ毎に異なる第１署名鍵と一意に対をなす第１公開鍵とユーザを一意に識別する情報とを内包する第１公開鍵証明証を含むことができる。このような第１公開鍵証明証の例は、公開鍵基盤（PKI）に基づき認証局により発行される公開鍵証明証であり、ユーザ登録時にシステム管理者が第１公開鍵証明証に記載された識別情報（または、第１公開鍵）からユーザを特定することが可能である。

上記とは異なり、第１公開鍵証明証がユーザを一意に識別する情報を含まず、かつ、システム管理者が第１公開鍵証明証に記載された公開鍵からユーザを特定することが不可能とすることもできる。この場合、例えば、第１署名鍵を、前項と同じくユーザ毎に異なる署名鍵としたまま、第１公開鍵証明証にユーザを一意に識別する情報を記載しないようにすることができる。公開鍵証明証に記載する識別情報は、空欄でもよいし、ユーザの仮名（本当の識別情報と紐付かない仮の識別情報）やユーザが属する別の匿名通信システムの識別情報でもよい。第１公開鍵証明証からユーザの識別情報を得ることはできない。

別の実施形態として、第１署名鍵をグループ署名の署名鍵とし、第１公開鍵をグループ（別の匿名通信システム）の公開鍵とすることができる。公開鍵証明証にはグループの識別情報のみが記載され、また、公開鍵はユーザに固有ではなく、グループに所属するすべてのユーザの署名鍵と等しく対応するので、識別情報と公開鍵とからユーザ個人を識別・追跡することは不可能である。

ユーザの追跡不能性は、匿名性より強いプライバシー保護の要請であり、ユーザの身許を秘匿するだけでなく、複数のイベントがたとえ同一のユーザによって為されたものであっても、その事実を秘匿することを要請する。これに対し、前述した仮名による匿名性は追跡不能性を満足しない。実際、同じ仮名による署名イベントは、匿名ではあっても、同一の作為者の行為の結果であることがわかる。この場合、なんらかの理由でひとつのイベントにおいて身許が露呈すると、連鎖的に、同じ仮名を用いたイベントにおける身許が明らかになってしまう。追跡不能性は、ひとつのイベントで身許が露呈しても、同一の行為者による他のイベントにおいて匿名性が保護されることを要請する。

グループ署名では、グループに所属する各ユーザが独自の署名鍵（グループ署名鍵）を保持するが、それらの署名鍵で生成される署名は共通のグループ公開鍵によって検証ができる。更に、異なるユーザ・同一のユーザによる署名を識別することは計算量的に不可能で（計算量に関する妥当な仮説から数学的に証明される）、これにより追跡不能性が計算量的に実現される。

一方、ユーザのグループ署名鍵は、グループの秘密情報を管理するグループ管理者の協力のもとでのみ生成が可能で、グループ管理者は、正当な理由がある時には、任意の署名値から、その署名を生成する際に用いたグループ署名鍵、即ち、グループ署名鍵の保有者であるユーザを特定することができる。一旦グループ署名の署名者が特定されると、否認拒否性により、署名者は署名の事実を否認することができない。

第２署名鍵と第２公開鍵は、第２署名鍵を用いてユーザが生成した署名データからユーザを識別することが不可能であるという要件、即ち、匿名性を満足するように構成される。前述した仮名が記された公開鍵証明書とグループ署名による実施形態はこの要求を満足する。但し、仮名公開鍵証明書による実施形態では、公開鍵はユーザ固有であるため、同じ公開鍵を追跡することにより、誰かは特定できないが、同一のユーザを追跡することは可能である。匿名性のみで十分なのか、追跡不可能性も必要なのかは、匿名通信システムの性質とポリシーに依存して個別に定められる。

本発明の匿名通信システムは、有事の際に通信者を特定する手段を備えたことを特徴とする。すなわち、管理者コンピュータが、ユーザデータ登録手段からユーザデータを読み出す手段と、読み出したユーザデータ中にユーザを一意に識別可能な情報が含まれている場合に、この情報に基づいてこのユーザの身許を特定する手段と、読み出したユーザデータ中にユーザを一意に識別可能な情報が含まれていない場合に、ユーザが作成した署名付きデータを提示して別の通信システムの管理者にそのユーザの身許を照会する手段とを更に含む。

また、本発明は、上記のように構成された匿名通信システムを少なくとも二つ含む複合的な匿名通信システムを提供する。この複合的匿名通信システムは、第１匿名通信システムの第２署名鍵を第２匿名通信システムの第１署名鍵として使用することを特徴とする。これにより、ユーザは、第２匿名通信システムへのユーザ登録時に、識別情報を提示することなく、匿名で登録が行えるようになる。一方、有事の際の通信者の特定は、第２匿名通信システムの管理者が、第１匿名通信システムの管理者に問い合わせることで実施する。第１匿名通信システムは、有事の際には通信者を特定する機能を具備しているので、第２匿名通信システムの管理者は第１匿名通信システムの管理者から通信者の識別情報を得ることができる。具体的には、第２匿名通信システムの管理者コンピュータは、第２匿名通信システムのユーザの第２署名鍵により生成された署名データをもとに、ユーザデータ登録手段からユーザが当該第２匿名通信システムに加入した際に登録した第１署名鍵による署名付きデータを特定する手段と、特定した署名付きデータを提示して第１匿名通信システムの管理者に加入済みユーザの身許を照会する手段とを備える。

前記のように、本発明は、複数の匿名通信システムを重層的に組み合わせ、各匿名通信システムへのユーザ登録はユーザ個人の識別情報を提示せず匿名で行える手段を具備する一方、有事の際には、匿名通信システムの階層を逆に辿ることにより、通信者の身許を特定する手段を具備する。特に、有事における通信者の特定では、階層を逆に辿った結果、通信者の特定を他者に依存せず実施できる通信システムに到達できなければならない。このため、階層の最下層では、ユーザの識別を確実に行う公開鍵基盤（ITU-T X.509など）に基づく通信システムを構築するのが望ましい。

通信者の特定におけるもう一つの要件は、証拠能力である。暗号理論の分野では、否認拒否性（Non-Repudiation）と呼ばれる要件である。ある署名鍵を用いて生成された署名データは当該署名鍵に一意に対応する公開鍵により検証可能であるが、否認拒否性は、逆に、ある公開鍵で検証可能な署名データは対応する署名鍵でのみ生成可能であることを理論的に保証することである。現在実用に供されているすべての電子署名方式は否認拒否性を満足する。法制的にも、「電子署名法」により、否認拒否性をもつ電子署名方式で生成された署名データは法的な証拠能力を有することが認められている。

翻って、証拠能力の観点から、本発明における通信者の特定を考える時、第２匿名通信システムの管理者は、いずれかのユーザの第２署名鍵による署名付きデータを取得するが、管理者は当該署名付きデータを検査することで、署名者のユーザ登録データを特定する手段を有する。例えば、仮名公開鍵証明証を用いた実施形態では、管理者が認証局として仮名公開鍵証明証を発行し、その際に当該公開鍵証明証、したがって、公開鍵とユーザ登録データとの紐付けを行う。グループ署名による実施形態では、管理者は管理者鍵を用いて署名付きデータから署名者を特定する機能が、署名方式の中に埋め込まれている。上記の方法により、管理者は取得した署名付きデータから、該当する署名者のユーザ登録データを特定することができる。否認拒否性に基づき、この特定には証拠能力が伴う。一方、ユーザ登録データは、ユーザの第１署名鍵による署名が付されている。本発明による匿名通信システムの「複合的」な構成では、当該第１署名鍵は、別の匿名通信システムの第２署名鍵であるので、前記署名付きユーザ登録データを、当該第１署名鍵を第２署名鍵とする前記匿通信システムの管理者に提示することで、同様に、証拠能力を有する形で署名者を特定することが可能となる。問題は、第１署名鍵の所有者と第２署名鍵の所有者が同一であることを、証拠能力を伴って証明することができるかという点にある。この問題を解決するために、本発明では、ユーザ登録データを第１署名鍵と第２署名鍵の両方を用いて二重に署名するように定める。すなわち、第２署名鍵による署名は、第１署名鍵による署名の否認拒否性の効力下にあるため、第１署名鍵の保有者は、第２署名鍵を用いた署名生成の事実を否認できず、したがって、第２署名鍵の所有を否認できない。

また、本発明は、ユーザの匿名による通信を可能とする匿名通信システムに加入するために、ユーザが操作するユーザコンピュータと、当該匿名通信システムの管理者が操作する管理者コンピュータとが実行する新規な方法を提供する。この方法は、ユーザコンピュータが、当該匿名通信システムとは別の通信システムで使用可能なユーザ固有の第１署名鍵と、当該匿名通信システムで使用するユーザ固有の第２署名鍵とにより二重に電子署名が付された署名付きデータを生成する段階と、この署名付きデータをユーザコンピュータから管理者コンピュータに提供する段階と、管理者コンピュータが、第１署名鍵と対をなす第１公開鍵と第２署名鍵と対をなす第２公開鍵を用いて電子署名を検証する段階と、電子署名の正当性が検証されたときに、管理者コンピュータが署名付きデータを含むユーザデータを登録する段階とを含むことを特徴とする。

上記方法において、第２署名鍵を管理者コンピュータによって生成し、管理者コンピュータからユーザコンピュータに提供することができる。この場合、管理者コンピュータは、ユーザコンピュータから提供された第１署名を検証した後に、第２署名鍵を暗号化してユーザコンピュータに提供し、ユーザコンピュータが第１署名鍵と第２署名鍵とにより二重に暗号化された電子署名付きのデータを生成し、これを管理者コンピュータに提供するという手順を採用することができる。

また、上記方法において、第２署名鍵をユーザ固有の公開鍵ペアの秘密鍵とし、ユーザコンピュータから管理者コンピュータに提供し、管理者コンピュータが公開鍵ペアの公開鍵に対してユーザの識別情報を含まない匿名公開鍵証明証を発行するという手順を採用することもできる。あるいは、ユーザコンピュータが、管理者コンピュータとの通信を介して、第２署名鍵を当該匿名通信システムの第２公開鍵で検証可能に生成し、生成した第２署名鍵を管理者に対して秘密に保持するという手順を採用することもできる。さらに、第２署名鍵にグループ署名の署名鍵を使用し、第２署名鍵をグループ署名における署名鍵の生成手順に従って生成することもできる。

本発明のシステムおよび方法によれば、ユーザが別の通信システムで信用を得た署名鍵を利用して新たな匿名通信システムに加入するので、高い匿名性を確保できるとともに、必要に応じてユーザを特定することもでき、もって、当該通信システムの社会的信頼性を高めることができるという効果がある。

本発明の一実施形態を示す複合的匿名通信システムのブロック図である。 図１の匿名通信システムにおいてユーザ登録手順を示すブロック図である。 図１の匿名通信システムにおいてユーザ特定手順を示すブロック図である。 本発明による複合的匿名通信システムの変更例を示すブロック図である。 匿名通信システムのユーザ及び管理者コンピュータの構成を示すブロック図である。 ユーザ登録時におけるコンピュータ間のデータ授受を示すブロック図である。 匿名通信システムへの加入申込み手続きを示すフローチャートである。 有事の際のユーザ特定手続きを示すフローチャートである。 匿名通信システムの別の実施例を示すブロック図である。 匿名通信システムのさらに別の実施例を示すブロック図である。

以下、本発明の実施形態を図面に基づいて説明する。図１に示す複合的匿名通信システム１００は、第１匿名通信システム１と第２匿名通信システム２と第３匿名通信システム３とから構成されている。第1匿名通信システム１は、各ユーザの身許を特定するための識別情報をシステム管理者に提供することを条件に加入が認可されるシステムである。具体的には、実ユーザは公開鍵ペア（公開鍵と署名鍵）を保持しており、公開鍵に対しては、公開鍵基盤の認証局からＩＴＵ−Ｔ Ｘ．５０９準拠の公開鍵証明証の発行を受けている。Ｘ．５０９公開鍵証明証の発行は、認証局によるユーザの身元の確認を伴い、Ｘ．５０９証明証にはユーザを一意に特定する識別情報が記載される。実ユーザが第１匿名通信システム１に登録し、第１匿名通信システム１内に仮想ユーザ１のアカウントを作成する際には、このＸ．５０９公開鍵証明証の登録が求められるものとする。これにより、第１匿名通信システムの管理者は、仮想ユーザ１の識別情報を知ることができる。

登録された仮想ユーザ１のアカウントには、匿名公開鍵１と匿名署名鍵１が保持される。匿名公開鍵１は、管理者１が発行する匿名公開鍵証明証１（図示略）に指定される。匿名公開鍵１、及び、匿名公開鍵証明証１は、ユーザを特定しないように構成される。例えば、匿名公開鍵１と匿名署名鍵１とは、通常の公開鍵暗号における公開鍵ペアとするが、匿名公開鍵証明証１は管理者１が当該ユーザの識別情報を記載せずに発行する公開鍵証明証とする。公開鍵ペアそのものはユーザ固有ではあるが、匿名公開鍵証明証１から署名者を特定できないので、仮想ユーザ１は匿名で署名を行うことができる。一方、匿名公開鍵証明証１は第１匿名通信システム１の管理者が署名しているので、匿名署名鍵１による署名付きデータの受領者は、第１匿名通信システム１に正しく登録しているユーザが署名したデータであることを検証することができる。更に、第１匿名通信システム１が「ユーザ登録時にＸ．５０９証明証に基づいた身許の確認を行う」旨のポリシーを公開することにより、前記受領者は、自らは署名者の身許はわからないものの、第１匿名通信システム１において正しく身許が確認されたユーザであることを知ることができる。別の例として、匿名公開鍵１をグループ署名の公開鍵、匿名署名鍵１をグループ署名の署名鍵とすることもできる。この場合、匿名公開鍵１は第１匿名通信システム１のユーザ全てに共通の鍵となり、かつ、匿名公開鍵証明証１はグループ、この場合、第１匿名通信システム１の公開鍵証明証となり、いかなるユーザかを特定する情報とはならない。グループ署名の機能から、匿名署名鍵１はユーザ毎に固有の異なる鍵となるが、匿名署名鍵１により生成される署名は、共通のグループ公開鍵、即ち、匿名公開鍵１により検証可能である。

これに対し、第２および第３匿名通信システム２、３は、それぞれ、ユーザが自身の身許を特定するための識別情報をシステム管理者に提供することなく、登録が認可されるシステムである。実際、仮想ユーザ１が第２匿名通信システム２に仮想ユーザ２を登録してアカウントを作成するにあたり、管理者２への匿名公開鍵証明証１の提出が求められる。前述のように、匿名公開鍵証明証１には第１匿名通信システムの管理者１の署名が付されているので、管理者２は仮想ユーザ１が第１匿名通信システム１の正しいユーザであることを確認できるが（正確には受領証データ２の署名を検証することで確認するが、詳しくは後述）、仮想ユーザ２を特定することはできず、従って、実ユーザを特定することもできない。匿名公開鍵証明証１にはユーザを特定する情報が記載されないからである。仮想ユーザ２が、第３匿名通信システム３に仮想ユーザ３を登録してアカウントを作成する場合も同様である。第３匿名通信システムにおいてユーザ登録データの一部として保持される匿名公開鍵証明証２は、仮想ユーザ２を特定せず、従って、仮想ユーザ１及び実ユーザを特定することはない。

ただし、本発明の複合的匿名通信システム１００は、図１の実施例に示すような単純な階層構造に限定されず、任意数の匿名通信システム間の自由なネットワーク構成を取り得る。例えば、第３匿名通信システム３に仮想ユーザ３を登録するために、第１匿名通信システム１のアカウントを利用、即ち、匿名公開鍵証明証１を登録しても構わないし、また、実ユーザの身許を特定するＸ．５０９公開鍵証明証を登録してアカウントを作成しても構わない。どの匿名通信システムの匿名公開鍵証明証を受理するか、または、匿名公開鍵証明証とＸ．５０９公開鍵証明証が混在する登録を認めるかは、その匿名通信システムのポリシーで決められるべき事項である。

図４は、より自由な複合的匿名通信システム２００の構成例を示す。第１匿名通信システム１は、ユーザ登録に際して、「実ユーザの身許の確認を実施し、実ユーザの識別情報が記載されたＸ．５０９公開鍵証明証を登録する」というポリシーをもつ。図中、矢印はどのユーザに基づいて新たな仮想ユーザが作成されるかを示し、実線矢印は身許の確認を伴う実ユーザからのユーザ登録、破線矢印は仮想ユーザに基づき匿名で行われるユーザ登録を示す。実際、仮想ユーザ１１、１２、及び、１３は、それぞれ、実ユーザ１、２、及び、３が身許を管理者１に対して証明して作成した仮想ユーザである。一方、第２匿名通信システム２は、「実ユーザの身許の確認を伴う仮想ユーザの登録のみを認める」というポリシーを有する。仮想ユーザ１１、及び、１２はこのポリシーの条件を満たすので、仮想ユーザ１１、及び、１２に基づいて、仮想ユーザ２１、及び、２２が作成される。この時、第２匿名通信システム２に登録される公開鍵証明証は、仮想ユーザ１１、及び、１２の匿名署名を検証するための匿名公開鍵証明証であり、前述のように、匿名公開鍵証明証からユーザを特定することはできない。同様に、第３匿名通信システム３は、「仮想ユーザに基づく匿名の登録と、実ユーザに基づく身許確認を伴う登録の両方を受理する」というポリシーを有し、第４匿名通信システム４は「任意の仮想ユーザに基づく匿名登録を受理する」というポリシーを有する。

図２は図１に基づいて、ユーザ登録を更に詳しく説明するためのものである。ユーザ登録においては、仮想ユーザ、または、実ユーザの公開鍵証明証を登録するのみではなく、当該ユーザによる署名がなされた受領証データを登録する。例えば、受領証データ１は、登録を行った実ユーザの署名鍵と、登録によって作成された仮想ユーザ１の匿名署名鍵１とにより、二重に署名されたデータである。図中、矢印は、矢印の始点が示す署名鍵により終点が示すデータが署名されていることを示す。匿名署名鍵１は、管理者が生成して実ユーザに送付する、ユーザが独自に生成する、ユーザと管理者が通信を介して生成する等の方法が考えられ、各匿名通信システムにおける匿名署名の方式、例えば、グループ署名の個別のアルゴリズムに依存する。ユーザが匿名署名鍵の生成に関わる場合は、匿名署名鍵を管理者に対して秘密にすることが目的であり、これにより厳密な否認拒否性が成り立つ。同一の受領証データに対して、二つの鍵で二重に署名する狙いは、二つのユーザ、すなわち、登録の基礎となった実ユーザと、登録の結果作成された仮想ユーザ１とを、結びつける点にある。この意味は、後述する。同様に、仮想ユーザ２を仮想ユーザ１に基づいて作成するためには、仮想ユーザ１は受領証データ２に対して、匿名署名鍵１と匿名署名鍵２を用いて二重に署名する。署名済み受領証データ２は、仮想ユーザ２が、実は、仮想ユーザ１であることの証拠となる。

図３は、ユーザ間の紛争、捜査機関の要請など、有事の際に、ユーザの身許を特定する手順を示す。第３匿名通信システム３の管理者３は、匿名署名鍵３による署名付きデータと、当該署名を検証するための匿名公開鍵３を記載した匿名公開鍵証明証３を、ユーザの身許の開示請求とともにうけとる。管理者３は、まず、匿名公開鍵３により当該署名が正しく検証されることを確認し、ついで、開示請求の理由を審査する。匿名通信システムのポリシーに照らして、開示請求理由が妥当である場合は、匿名公開鍵証明証３と署名付きデータから、署名者である仮想ユーザ３のユーザ登録データを特定する。これは、例えば、以下のように実施される。匿名公開鍵３が仮想ユーザ３に固有のデータである場合、つまり、仮想ユーザ２が匿名署名鍵３と匿名公開鍵３を独自に作成し、管理者３が仮想ユーザ２の識別情報を含まない匿名公開鍵３の匿名公開鍵証明証３を生成した場合、ユーザ固有の匿名公開鍵３を検索のキーとしてユーザ登録データを特定できる。また、匿名公開鍵３がグループ署名の公開鍵である場合、匿名公開鍵３はグループで共通であり、匿名公開鍵証明証３もグループで共通である。しかしながら、グループ署名の機能により、管理者３は管理者の秘密である管理者鍵を用いることにより、署名者である仮想ユーザ３を特定できる。ここでは、グループ署名の方式により、匿名署名鍵３そのものを特定できる場合もあり、また、仮想ユーザ３の識別子を特定できる場合もある。いずれの場合も、得られた情報をもとに、ユーザ登録データを特定することができる。

前記特定されたユーザ登録データには、匿名公開鍵証明証２と受領証データ３が含まれている。受領証データ３は、仮想ユーザ２によって匿名署名鍵２による署名が施されているので、管理者３が匿名公開鍵証明証２と受領証データ３をユーザの身許の開示請求とともに管理者２に送付すると、管理者２は前述と同じ方法で、仮想ユーザ２のユーザ登録データを特定することができる。更に、管理者２は、特定されたユーザ登録データ中の匿名公開鍵証明証１と受領証データ２とを開示請求とともに、管理者１に送付する。管理者１は、前述と同じ方法で、仮想ユーザ１のユーザ登録データを特定する。

仮想ユーザ１のユーザ登録データには、実ユーザのＸ．５０９公開鍵証明証が登録され、当該公開鍵証明証には実ユーザの識別情報が記載されているので、実ユーザを特定することが可能となる。

管理者１は、特定した実ユーザの識別情報を、開示請求の請求元である管理者２に回答し、管理者２は、得られた実ユーザの識別情報を、開示請求元である管理者３に回答する。最後に、管理者３は、もともとの開示請求の請求元に得られた実ユーザの識別情報を回答する。これにより、開示請求の請求元は、匿名署名鍵３による署名付きデータから署名を行った実ユーザを特定することが可能となる。

図３を用いて、否認拒否性について説明する。否認拒否性とは、署名者が署名の事実を否認できないことを保証するもので、電子署名の基本要件のひとつである。即ち、ある署名がある公開鍵を用いて検証された場合、当該署名が当該公開鍵と数学的に紐付けられた特定の署名鍵を用いて生成されたことを、数学的に証明できる性質を指す（正確には、当該署名鍵を用いずに生成される確率が天文学的に小さいことを証明することができる）。即ち、否認拒否性により、署名鍵の所有者が署名を行ったことを証明することが可能となる。厳密には、署名鍵を認証局が生成してユーザに発行することは一般に行われており、その場合、署名鍵を知る者は認証局と署名鍵の所有者であるユーザの二者となるが、認証局は信頼できる第三者（Ｔｒｕｓｔｅｄ Ｔｈｉｒｄ Ｐａｒｔｙ）と認定されるため、当該ユーザは署名の事実を否認できない。

図３で求められている否認拒否性は、管理者３に提出された、匿名署名鍵３による署名付きデータに関して、仮想ユーザ３の実体である実ユーザが署名の事実を否認できないことを意味する。この事実は、以下のように、再帰的に証明できる。まず、受領証データ１には、Ｘ．５０９公開鍵証明証に記載の公開鍵で検証可能な署名が付されている。従って、実ユーザは、受領証データへの署名の事実を否認することはできない。一方、受領証データには匿名署名鍵１による署名も付されているので、実ユーザは受領証データへの匿名署名鍵１への署名の事実を否認できず、即ち、匿名署名鍵１を所持している事実を否認できない。次いで、受領証データ２には、匿名署名鍵１による署名が付されているので、否認拒否性より、実ユーザは受領証データ２への匿名署名鍵１による署名の事実を否認できず、受領証データ２には匿名署名鍵２による署名が付されているので、前記の理由により、実ユーザは匿名署名鍵２を所持している事実を否認することはできない。更に、同様の議論を、受領証データ３についても適用すると、実ユーザは匿名署名鍵３を所持している事実を否認することはできない。最後に、開示請求とともに管理者３に提示された署名付きデータは匿名署名鍵３により署名されているので、実ユーザは当該署名付きデータへの署名の事実を否認することはできない。

図５は、上述した複合的匿名通信システム１００または２００に含まれる一つの匿名通信システム１０の構成を示し、図６は該通信システム１０におけるデータの授受を示す。図５、図６に示す匿名通信システム１０は、当該匿名通信システム１０に加入するユーザが操作するユーザコンピュータ１１と、匿名通信システム１，２の管理者が操作する管理者コンピュータ２１とを備えている。そして、ユーザコンピュータ１１と管理者コンピュータ２１とがインターネット４０またはその他の通信回線を介して接続されている。

ユーザコンピュータ１１には、署名鍵保持部１２、署名付きデータ生成部１３、ＣＰＵ１４、メモリ１５、通信インターフェース１６が設けられている。署名鍵保持部１２には、当該匿名通信システム１０とは別の匿名通信システムで使用可能なユーザ固有の第１署名鍵４１と、当該匿名通信システム１０で使用できるように管理者コンピュータ２１から提供されたユーザ固有の第２署名鍵４２とが保持されている。署名付きデータ生成部１３では、第１署名鍵４１により署名された電子署名付きの加入申込みデータ４３が生成されるとともに、第１署名鍵４１と第２署名鍵４２で二重に署名された電子署名付きデータである受領証データ４４（図１に示す受領証データ１，２，３に相当）が生成される。

管理者コンピュータ２１には、第２署名鍵生成部２２、署名検証部２３、ユーザデータ登録部２４、ユーザ特定部２５、ユーザ照会部２６、ＣＰＵ２７、メモリ２８、通信インターフェース２９が設けられている。第２署名鍵生成部２２は、ユーザごとに異なる第２署名鍵４２を生成し、通信インターフェース２９を介してユーザコンピュータ１１に提供する手段として機能する。署名検証部２３は、第１署名鍵４１と対をなす第１公開鍵５１を用いて加入申込みデータ４３の電子署名を検証するとともに、第１公開鍵５１に加え第２署名鍵４２と対をなす第２公開鍵５２を用いて受領証データ４４の電子署名を検証する。

そして、匿名通信システム１，２への加入時には、ユーザコンピュータ１１が加入申込みデータ４３を管理者コンピュータ２１に提供し、管理者コンピュータ２１が加入申込みデータ４３の電子署名を検証した後に、第２署名鍵４２を生成してユーザコンピュータ１１に提供し、第２署名鍵４２を受け取ったユーザコンピュータ１１が二重署名付きの受領証データ４４を管理者コンピュータ２１に提供し、管理者コンピュータ２１が受領証データ４４の電子署名を検証し、その電子署名の正当性を検証できたときに、受領証データ４４を含むユーザデータをユーザデータ登録部２４に登録するようになっている。

ユーザデータ登録部２４に登録されるユーザデータには、受領証データ４４に加え、第１署名鍵４１と対をなす第１公開鍵５１が記載された第１公開鍵証明証５３と、第２署名鍵４２と対をなす第２公開鍵５２が記載された第２公開鍵証明証５４とが含まれる。例えば、図１に示す第１匿名通信システム１へのユーザ登録がユーザの身許の確認を要求する場合には、第１公開鍵証明証５３は、ユーザ固有の公開鍵と識別情報を記載した、例えば、ＩＴＵ−Ｔ Ｘ．５０９準拠の公開鍵証明証である。この場合、システム管理者は、必要に応じて、ユーザデータからユーザを一意に識別することができる。一方、図１に示す第２匿名通信システム２がユーザの身許の確認を要求しない場合は、第１公開鍵証明証５３にはユーザの識別情報は記載されない。この場合、第１公開鍵証明証５３は、ユーザの仮名のみを記載した匿名公開鍵証明証とすることもできるし、グループ署名におけるグループの公開鍵とグループの識別情報を記載した公開鍵証明証とすることもできる。

一方、第２匿名通信システム２は、ユーザに匿名通信を提供しているため、第２公開鍵証明証５４は、ユーザの識別情報を含まない、例えば、ユーザの仮名のみを記載した匿名公開鍵証明証やグループ署名におけるグループの公開鍵とグループの識別情報を記載した公開鍵証明証となる。前者の例では、第２署名鍵４２はユーザ毎に異なる署名鍵となり、第２署名鍵４２と対をなす第２公開鍵５２もユーザ毎に異なるが、第２公開鍵証明証５４には仮名のみが記載され、ユーザを識別しないため、通信相手は第２公開鍵証明証５４に記載された第２公開鍵５２により第２署名鍵４２による署名の検証を行うことができても、署名者の特定はできない。後者の例では、第２署名鍵４２はグループ署名の署名鍵であるため、通信相手は第２公開鍵証明証５４に記載された第２公開鍵５２により第２署名鍵４２による署名の検証を行うことができる。グループの公開鍵である第２公開鍵５２はグループに所属する全てのメンバー（この場合、第２匿名通信システム２に登録を行ったすべてのユーザ）に共通であるため、検証に伴って署名者を特定することは原理的に不可能である。但し、仮名公開鍵証明書を用いた前者の例では、ユーザ毎に異なる第２公開鍵５２で署名検証を行うため、二つの署名が与えられた時、それが同一の第２署名鍵によるものであるか否かは判別することができる。一方、グループ署名による後者の例では、全ての署名の検証に同一の第２公開鍵５２を使用するため、第２署名鍵の同一性の判別も不可能である。すなわち、後者の例の方が、追跡不可能性を満足している点で、より高い匿名性の水準を満足していると云える。

管理者は、第２署名鍵４２による通信内容への署名に基づいて、署名者を登録情報上で識別する作業を行うことができる。この作業が必要となる例として、通信者間の紛争が考えられる。例えば、ネット上の販売サイトとその顧客が通信を通して契約を行う場合、顧客は支払い同意書に署名を行って、販売サイトに送付するとする、この時、顧客がプライバシーの観点から身許を販売サイトに知られたくないという要求があれば、顧客は自身の第２署名鍵４２による署名を行う。販売サイトは第２公開鍵５２によって署名を検証することで、支払いの意思を確認することができるが、第２公開鍵証明書から顧客の身許を特定することはできない。この後、万が一、顧客が支払いを行わなかった場合、販売サイトは顧客を特定して督促等の手段を講じなければならないが、この時、販売サイトは、顧客が送付した第２署名鍵４２による署名と、署名検証に用いた第２公開鍵証明書５４とを管理者に提示する。一方、管理者は、署名と第２公開鍵証明証５４とから、ユーザデータ登録部２４に登録されたユーザ登録データを特定する。例えば、第２公開鍵証明証５４が前記仮名証明証である場合には、第２公開鍵証明証５４に記載されている公開鍵はユーザ固有であることから、当該公開鍵を検索のキーとして、ユーザ登録データの特定が可能である。また、第２公開鍵証明証５４に記載されている公開鍵がグループ署名の公開鍵である場合には、グループ署名の仕組みを用いて、管理者の秘密である管理者鍵を用いることにより、署名値から第２署名鍵４２を識別することができ、よって、ユーザ登録データを特定することが出来る。

ユーザ登録データに、ユーザの識別子が記載された第１公開鍵証明証５３が含まれている場合、例えば、第１公開鍵証明証５３がＩＴＵ−Ｔ Ｘ．５０９に準拠する公開鍵証明証である時、当該証明証に記載されている識別情報によりユーザを特定することができる。一方、第１公開鍵証明証５３がユーザの識別情報を含まない場合、ユーザ登録データのうち、第１公開鍵証明証５３と署名済み受領証データ４４とを匿名通信システム１０の管理者に送付することにより、匿名通信システム１０の管理者をして、ユーザを特定せしめることができる。例えば、第１公開鍵証明証５３が前記匿名公開鍵証明証である場合、第１公開鍵証明証５３に記載の公開鍵はユーザ固有であり、当該公開鍵を検索のキーとして、匿名通信システム１０の管理者は匿名通信システム１０におけるユーザ登録データを特定できる。第１公開鍵証明証５３がグループ署名の公開鍵である場合は、グループ署名の仕組みを用いて、受領証データ４４の署名から第１署名鍵を識別することができ、よって、匿名通信システム１０におけるユーザ登録データを特定できる。

前記のように、ユーザの識別情報の特定は再帰的な問い合わせによって実行される。ある匿名通信システムの管理者は、第１公開鍵証明証５３からユーザの識別情報が得られない場合、別の匿名通信システムの管理者に問い合わせを行う。別の匿名通信システムの管理者も、自身の匿名通信システム１のユーザ登録データ中の公開鍵証明証５３から、問い合わされたユーザの識別情報が得られない場合は、更に別の匿名通信システムの管理者に問い合わせを行う。このような再帰的問い合わせにおいて、最終的にユーザの識別情報が得られる保証が必要であるが、時系列的に最初に形成される匿名通信システム（例えば、図１、図４に示す第１匿名通信システム１）においては、ユーザ登録時にユーザ識別情報を記載した第１公開鍵証明証、例えば、ＩＴＵ−Ｔ Ｘ．５０９準拠の公開鍵証明証に基づいてユーザ登録を行わざるを得ないので、階層的に構築された匿名通信システム群（複合的匿名通信システム）においては、再帰的問い合わせには最終的に回答がもたらされる。

次に、上記のように構成された匿名通信システム１０にユーザが加入するための方法を主に図７に基づいて説明する。図７は、ユーザが匿名通信システム１０に加入する際にユーザコンピュータ１１と管理者コンピュータ２１とが実行する加入申込み手続きを示すフローチャートである。まず、ユーザが加入申込み操作（Ｗｅｂ画面等において加入申込みボタンやリンクをクリックする等）を行うと、加入申込み手続きが開始し（Ｓ１０１）、ユーザコンピュータ１１は加入申込みデータ４３を生成し（Ｓ１０２）、第１署名鍵４１を用いて加入申込みデータ４３に電子署名を行い（Ｓ１０３）、管理者コンピュータ２１に送信する（Ｓ１０４）。

ユーザコンピュータ１１から加入申込みデータ４３を受信すると、管理者コンピュータ２１は、第１公開鍵５１を用いて加入申込みデータ４３の電子署名を検証する（Ｓ１０５）。そして、電子署名の正当性を検証できなかったときは（Ｓ１０６：Ｎｏ）、加入を拒否し、加入申込み手続きを終了させる（Ｓ１１６）。電子署名の正当性を検証できたときは（Ｓ１０６：Ｙｅｓ）、管理者コンピュータ２１が、第２署名鍵生成部２２で第２署名鍵４２を生成し（Ｓ１０７）、これをユーザコンピュータ１１のみが復号できるよう暗号化して（Ｓ１０８）、ユーザコンピュータ１１に送信する（Ｓ１０９）。

管理者コンピュータ２１から第２署名鍵４２を受信すると、ユーザコンピュータ１１は、受領証データ４４を生成し（Ｓ１１０）、第１署名鍵４１および復号した第２署名鍵４２を用いて、受領証データ４４に二重の電子署名を行い（Ｓ１１１）、この署名付きデータを管理者コンピュータ２１に送信する（Ｓ１１２）。

ユーザコンピュータ１１から受領証データ４４を受領すると、管理者コンピュータ２１は、第１，２公開鍵５１，５２を用いて、受領証データ４４の二重の電子署名を検証する（Ｓ１１３）。そして、二重の電子署名のうちいずれか一方でもその正当性を検証できなかったときは（Ｓ１１４：Ｎｏ）、加入を拒否し、加入申込み手続きを終了させる（Ｓ１１６）。また、二重の電子署名全ての正当性を検証できたときは（Ｓ１１４：Ｙｅｓ）、ユーザデータ登録部２４に二重署名付き受領証データ４４、第１公開鍵証明証、および、第２公開鍵証明証を登録した後に（Ｓ１１５）、加入申込み手順を終了させる（Ｓ１１６）。

したがって、この匿名通信システム１０によれば、ユーザはこれまで別の通信システムで使用してきた署名鍵を第１署名鍵４１として、当該署名鍵で署名した加入申込みデータ４３および受領証データ４４をシステム管理者に提示することで、自身の身許を明かすことなく新たな匿名通信システムに加入することが可能となるので、必要以上に自分のプライバシーを晒すことなく、高度の匿名性が保証されたコミュニティでより広範囲のユーザと各種データを交換し合うことができる。特に、この実施形態の匿名通信システム１０は、加入申込みデータ４３の電子署名を検証できたことを条件にして、管理者コンピュータ２１が第２署名鍵４２をユーザコンピュータ１１に提供するように構成されているので、悪意ある参入者を事前に排除し、システムの安全性、信頼性を高めることもできる。

また、管理者コンピュータ２１は、加入申込みデータ４３中の第１署名鍵４１をそのユーザの信用性の証として検証するのみならず、受領証データ４４中の第１署名鍵４１を必要に応じてそのユーザを特定するための情報として利用することで、ユーザの匿名性を犠牲にすることなく、システムの安全性ならびに社会的信頼性をより一層高めることができる。図８は、管理者コンピュータ２１が受領証データ４４を利用してユーザを特定するための手続きを例示する。

図８に示すフローチャートにおいて、ユーザ特定手続が開始されると（Ｓ２０１）、まず、管理者コンピュータ２１は匿名通信システム１０の内外からシステム加入者に関する問合せ情報を受信する（Ｓ２０２）。次に、問い合わせ情報に含まれる第２署名鍵４２により署名されたデータ、及び、第２公開鍵証明証５４を取得する。第２公開鍵証明証５４が当該匿名通信システムで共通である場合には、第２公開鍵証明証５４を問い合わせ情報に含める必要はない。更に、第２公開鍵証明証５４に記載されている第２公開鍵５２を用いて、前記署名付きデータの署名を検証し、検証が失敗した場合には、不正な問い合わせと判断してユーザ特定手続きを終了させる。署名の検証が成功した場合には、引き続いて、問合せの理由を精査し、その理由が正当であるかどうかを判断する（Ｓ２０３）。問合せ理由に正当性がない場合には、問い合わされたユーザ（システム加入者）の個人情報を保護するためにユーザ特定手続を終了させる（Ｓ２０８）。問合せ理由に正当性がある場合には、問い合わされたユーザに関するユーザ登録データをユーザデータ登録部２４から読み出す（Ｓ２０４）。この時、ユーザ登録データを特定する方法は、第２署名鍵４２と第２公開鍵５２の構成方法に依存して異なる。例えば、第２公開鍵証明証５４が、ユーザ固有の公開鍵を記載する匿名公開鍵証明証である場合には、第２公開鍵署名証５４を検索キーとして、ユーザ登録データを特定することができる。また、第２公開鍵証明証５４が、グループ署名の公開鍵を記載する公開鍵証明証である場合には、第２公開鍵証明証５４はユーザに依存しないグループ（匿名通信システム）共通のデータであるので、検索キーとして用いることはできない。しかし、グループ署名の機能から、管理者の秘密である管理者鍵を利用することで、問い合わせ情報に付随する署名データから第２署名鍵４２を識別することが可能である。ユーザデータ登録部２４において第２署名鍵４２の識別情報とユーザ登録データとを紐づけておけば、ユーザ登録データを特定することが可能となる。

続いて、管理者コンピュータ２１は、読み出したユーザ登録データ中にユーザを一意に識別可能な情報が含まれているか否かを判断する（Ｓ２０５）。例えば、ユーザが、ユーザ固有の識別情報と固有の公開鍵を記載した第１公開鍵証明証５３、例えば、ＩＴＵ−Ｔ Ｘ．５０９準拠の公開鍵証明証を提示してユーザ登録を行った場合には、当該第１公開鍵証明証５３からユーザの識別情報を取得することができる。そして、受領証データ４４中に一意の識別情報が含まれている場合には、ユーザ特定部２５がその識別情報からユーザの身許を特定する情報を抽出し（Ｓ２０６）、ユーザ特定手続を終了させる（Ｓ２０８）。一方、読み出したユーザデータ中に一意の識別情報が含まれていない場合には、ユーザ照会部２６が二重署名付きデータである受領証データ４４と第１公開鍵証明証５３を提示して別の匿名または非匿名の通信システムの管理者にそのユーザの身許を照会した後に（Ｓ２０７）、ユーザ特定手続を終了させる（Ｓ２０８）。

したがって、この実施形態の匿名通信システム１０によれば、システム自身がユーザの身許を特定するための具体的な情報を保持していない場合でも、二重署名付き受領証データ４４中の第１署名鍵４１を利用して他の通信システムの管理者に問題あるユーザの身許を照会し、照会により得られたユーザデータを当該匿名通信システム１０のセキュリティ強化に活用し、もって、システムの社会的信頼性をより確かなものとすることができる。

図９および図１０は匿名通信システムの別の実施例を示すもので、それぞれ、第２署名鍵を管理者コンピュータ２１が生成するのではなく、ユーザコンピュータ１１が生成するように構成されている。その他の構成は、前記実施例と同様であり、図面に同一符号を付して重複する説明を省き、以下に相違点について説明する。

図９に示す匿名通信システムでは、ユーザコンピュータ１１にユーザ固有の公開鍵ペアを生成する手段として公開鍵ペア生成部１７が設けられている。公開鍵ペアは、ユーザ固有の秘密鍵（または個人鍵）４６と、その秘密鍵４６に対をなす匿名公開鍵５５とからなっている。管理者コンピュータ２１には、公開鍵ペアの匿名公開鍵５５に対してユーザの識別情報を含まない匿名公開鍵証明証５６を発行する手段として匿名公開鍵証明証発行部３０が設けられている。そして、匿名通信システム１０への加入時には、ユーザコンピュータ１１が第１署名鍵４１と第２署名鍵である秘密鍵４６を用いて、匿名公開鍵５５を含むデータに二重に署名して署名付きデータ４７とし、署名付きデータ４７を管理者コンピュータ２１に提供するように構成されている。通常、公開鍵証明証の発行を認証局に依頼する際には、証明証署名要求（ＣＳＲ、Ｃｅｒｔｉｒｉｃａｔｅ Ｓｉｇｎｉｎｇ Ｒｅｑｕｅｓｔ）を生成し、認証局に送付する。通常、証明証署名要求は、鍵所有者の識別情報と証明証に記載されるべき公開鍵が含まれ、対応する署名鍵で署名される。本発明における署名付きデータ４７は、ユーザの識別情報を含まず、匿名公開鍵５５を含むデータに秘密鍵４６を用いて署名を付したものに、更に、第１署名鍵４１により署名を付したデータとすることが出来る。管理者が生成する匿名公開鍵証明証５６は第２公開鍵証明証、匿名公開鍵５５は第２公開鍵として用いられる。

図１０に示す匿名通信システムでは、ユーザコンピュータ１１に、第２公開鍵５２によって検証可能な第２署名鍵４８を管理者コンピュータ２１との通信を介して生成する第２署名鍵生成部１８と、生成した第２署名鍵４８をシステム管理者に対して秘密に保持する署名鍵保持部１２とが設けられている。一方、管理者コンピュータ２１には、ユーザコンピュータ１１との通信により第２署名鍵４８の生成を補助する第２署名鍵生成補助部３１が設けられている。そして、匿名通信システム１０への加入時に、ユーザコンピュータ１１が自身で生成した第２署名鍵４８と第１署名鍵４１とで二重に署名した署名付きデータ４７を管理者コンピュータ２１に提供するように構成されている。

図９および図１０に示す匿名通信システムによれば、第２署名鍵をユーザコンピュータ１１自身が生成するように構成されているので、当該匿名通信システムで使用する秘密鍵４６または第２署名鍵４８をシステム管理者に対して秘匿することができるので、前記実施例と比較し、否認拒否性を厳密に満足する。即ち、前記実施例では、第２署名鍵はユーザと管理者で共有しているため、署名付きデータが与えられた時、悪意の管理者がユーザになりすまして署名を行った事実を否定できない。一方、図９及び図１０の実施例では、第２署名鍵はユーザのみの秘密であるため、否認拒否性が厳密に成立する。

以上詳述したように、本発明によれば高度の匿名性と厳密な否認拒否性が保証されるので、産業上の多様な分野において本発明の匿名通信システムを実用化することができる。本発明の実用化の例として、以下に図書館システムとオンラインオークションについて説明する。

図書館業務においては、個人への貸し出しのプライバシーを守ることは、憲法に定められた信条の自由を守る上で重要である。コンピュータが導入される以前では、ブラウン方式・逆ブラウン方式などの方法が利用されてきた。ブラウン方式では、図書館の利用者には氏名・連絡先などが記載された袋状の貸出券が配布され、各図書には書誌情報を記載したブックカードが用意される。図書を貸し出す時には、貸出券にブックカードを挿入し、返却時まで保管する。図書の返却時には、貸出券のみを利用者に返却する。この方法により、図書を返却してしまえば、当該図書を借り出した記録は一切残らず、プライバシーを守ることができる一方、図書が貸し出されている間は、図書館は誰が書籍を借り出しているかを知ることができ、貸出期限を超過した時に返却を督促するなど、問題が出来した際に適切な対応を取ることができる。逆ブラウン方式は、貸出券とブックカードの形状を逆にした方式である。ブラウン方式・逆ブラウン方式を用いた場合でも、貸出期間中は書籍と利用者の関係を知ることができ、この間に不法に記録をとることは可能であるので、完全にプライバシーを保護できるわけではない。コンピュータが導入されてからは、この方式が用いられることはなくなったが、コンピュータにより、方式をエミュレートすることは可能である。しかし、その場合でも、通常の方法では利用者のプライバシーを完全に保護することが不可能であるだけではなく、コンピュータシステムへの外部侵入など、その危険は増大し、また、実行者を特定することはより困難となる。

本発明を利用することで、この問題を本質的に解決することが可能となる。以下に述べる例は、全ての図書館で共有する基幹システムと、各図書館が個別に運用する個別システムとからなる。基幹システムの機能は利用者の識別情報を管理すること、個別システムの機能は図書の貸出業務を実行することである。まず、利用者は、自らの身元を証明して基幹システムに登録を行う。住民基本台帳カードを利用して登録を行う際、即ち、利用者の識別情報として、当該カード中に記録された公開鍵証明証を用いる際には、オンラインでインターネットから登録を行うことができる。運転免許証・健康保険証などの紙媒体の書類を用いて識別を行う場合には、来館して対面で登録を行う。登録のための審査に合格すると、基幹システムは、当該利用者固有のグループ署名の署名鍵を生成する。このグループ署名鍵を、「共通署名鍵」と呼ぶ。共通署名鍵は、一切のデータを記録していない新しいＩＣカードに記録され、利用者に郵送されるか、手交される。このＩＣカードを、「図書館利用共通カード」と呼ぶ。基幹システムへの登録は、氏名・住所など、識別情報が変更されない限りは、どの図書館を利用する場合でも、一度でよい。

次に、利用者は利用したい図書館に登録を行う。例えば、市町などの地方公共団体が運用する図書館を利用する場合を考える。利用者は、該当する図書館（以下、個別図書館と呼ぶ）に赴く。図書館は、利用者の図書館利用共通カードに記録された共通署名鍵を用いて登録申し込みデータに署名するように利用者を促し、署名された登録申し込みデータを基幹システムにオンラインで送付する。個別図書館は、特定の地方公共団体が住民に対して提供しているサービスであるので、申し込みを行った利用者が当該公共団体に所属していることを確認することが目的である。グループ署名の特性から、基幹システムは登録申し込みデータの署名から利用者を特定し、居住地情報から当該公共団体の地域に住所を有しているか否かのみを、個別図書館に対して回答する。個別図書館は、利用者が該当する地域に住所を有することを確認し、登録作業を行う。登録作業では、グループ署名に基づいて利用者固有のグループ署名鍵を生成し、利用者の図書館利用共通カードに記録する。このグループ署名鍵を「個別署名鍵」と呼ぶ。この際、個別署名鍵受領データを作成し、当該利用者の共通署名鍵と個別署名鍵による二重署名とともに、システム内で記録する。

利用者が図書を借り出す際には、図書館利用共通カードを提示する。図書館は、当該図書の貸出データを作成し、当該貸出データに対して当該図書館が発行した個別署名鍵で署名するよう利用者を促し、さらに、その図書館のグループ公開鍵を用いて署名を検査する。署名が検証できた場合に限り、そのデータを署名とともに記録する。署名はグループ署名に従っているため、署名のプロセスにおいて利用者個人を識別する情報が流出することはなく、誰がその図書を借り出したのか判定できない。

一方、貸出期限を過ぎても図書を返却しない場合など、図書を借り出した利用者を特定する必要がある場合には、貸出データの署名から、当該利用者の個別署名鍵受領データを特定する。これは、グループ署名の特性から可能である。個別署名鍵受領データは、当該利用者の共通署名鍵による署名も施されているので、個別署名鍵受領データを署名と共に基幹システムに送付すれば、基幹システムは、登録された当該利用者の識別情報を検索することが可能である。基幹システムは、図書館による身元開示要求が正当と判断された場合にのみ、識別情報のうち当該図書館が業務を実施する上で必要な情報のみを当該図書館に回答する。

上記の例では、図書の貸出に際してグループ署名鍵である「個別署名鍵」で署名するため、図書館は利用者が登録済みであることを確認することはできても、その身元を識別することはできない。一方、有事の際には、個別署名鍵の署名から検索される共通署名鍵による署名を基幹システムに提示することにより、各図書館は利用者の識別を行うことが可能となる。

次に、本発明をオンラインオークションに実用化したシステムについて説明する。このシステムは、複数のオークション主催者に対して「会場」を提供する基幹システムと、オークションを主宰する主催者システムとからなる。オークションの参加者は、まず、基幹システムに登録して、会員資格を取得する。登録に際して、参加者は住民基本台帳カードなど、公的機関や金融機関が発行した公開鍵証明証と署名鍵を用いて、身元の証明を行う。この署名鍵を「基本署名鍵」と呼ぶ。一方、身元の確認の後、基幹システムは参加者にグループ署名を発行するが、このグループ署名鍵を「会員署名鍵」と呼ぶ。基幹システムは、参加者の登録に際して、基本署名鍵と会員署名鍵とで二重に署名された会員署名鍵受領データをシステム内に記録する。受領データは基本署名鍵により署名されているため、会員を識別する情報となるとともに、会員が会員署名鍵を受領した事実を否認できない否認拒否性を有する。

参加者が特定のオークションに参加する場合には、当該オークションの主催者システムに登録する。登録に際しては、会員署名鍵を用いる。主催者システムは、会員にグループ署名鍵である参加者署名鍵を発行するが、その際、参加者署名鍵受領データに参加者署名鍵と会員署名鍵の両方で署名することを求める。署名された受領データは主催者システムに記録される。

オークションの参加者は、匿名でオークションに参加することができる。即ち、入札に際しては、入札額を含む入札データに参加者署名鍵で署名し、主催者に送付する。参加者署名鍵はグループ署名鍵であるため、主催者以外は入札者を追跡することができない（従って、当然匿名性も保たれる）。一方、会員署名鍵もグループ署名鍵であるため、主催者は自分のオークションの中では入札者を追跡することはできるが、入札者を識別することはできない。また、自分が主宰しないオークションにおいては、追跡を行うこともできない。

オークションが終了し落札者が決定した時は、主催者は入札データへの参加者署名鍵による署名から、主催者システムに記録された参加者署名鍵受領データを特定し、基幹システムに送付する。受領データは会員署名鍵で署名されているため、基幹システムのみは、署名から会員署名鍵受領データを特定することができる。受領データには会員の識別情報が記載されているので、その情報をオークションの主催者に回答する。主催者は、識別情報をもとに、落札者に対して、支払いの請求と落札品の配達を実施する。

万一、落札者が入札の事実を否認しようとした場合、署名の否認拒否性を利用して、その主張を拒否することができる。即ち、会員署名鍵受領データには、公的機関が発行した公開鍵証明証で検証可能な署名が施されているため、落札者は会員署名鍵の保有の事実を拒否できない。次いで、参加者署名鍵受領データは当該会員鍵で署名されているため、参加者署名鍵の保有を拒否できない。最後に、入札データは当該参加者署名鍵で署名されているため、入札の内容、特に、入札の事実を拒否できない。

なお、本発明は、上記実施形態に限定されるものではなく、例えば、単独の匿名通信システムを構成したり、通信目的の異なる多種類の匿名通信システムを組み合わせて複合的通信システムを構成したりするなど、本発明の趣旨を逸脱しない範囲で、各部の構成を任意に変更して実施することも可能である。

１ 第１匿名通信システム
２ 第２匿名通信システム
３ 第３匿名通信システム
１０ 匿名通信システム
１１ ユーザコンピュータ
１２ 署名鍵保持部
１３ 署名付きデータ生成部
１７ 公開鍵ペア保持部
１８ 第２署名鍵生成部
２１ 管理者コンピュータ
２２ 第２署名鍵生成部
２３ 署名検証部
２４ ユーザデータ登録部
２５ ユーザ特定部
２６ ユーザ照会部
３０ 匿名公開鍵証明証発行部
４０ インターネット
４１ 第１署名鍵
４２ 第２署名鍵
４３ 加入申込みデータ
４４ 受領証データ（署名付きデータ）
４６ 公開鍵ペアの秘密鍵
４７ 署名付きデータ
４８ 第２署名鍵
５１ 第１公開鍵
５２ 第２公開鍵
５３ 第１公開鍵証明証
５４ 第２公開鍵証明証
５５ 公開鍵ペアの匿名公開鍵
５６ 匿名公開鍵証明証
５７ 第２公開鍵
５８ 第２公開鍵証明証
１００ 複合的匿名通信システム

Claims (18)

1. ユーザの匿名による通信を可能とする匿名通信システムであって、
   前記ユーザが操作するユーザコンピュータと、当該匿名通信システムの管理者が操作する管理者コンピュータとを備え、
   前記ユーザコンピュータが、当該匿名通信システムとは別の通信システムで使用可能なユーザ固有の第１署名鍵と、当該匿名通信システムで使用するユーザ固有の第２署名鍵とにより二重に電子署名が付された署名付きデータを生成する手段を含み、
   前記管理者コンピュータが、前記第１署名鍵と対をなす第１公開鍵と、前記第２署名鍵と対をなす第２公開鍵を用いて前記電子署名を検証する手段と、該電子署名の正当性が検証された前記署名付きデータを含むユーザデータを登録するユーザデータ登録手段とを含むことを特徴とする匿名通信システム。
2. 前記管理者コンピュータが、ユーザごとに異なる第２署名鍵を生成してユーザコンピュータに提供する手段を更に含む請求項１記載の匿名通信システム。
3. 前記ユーザコンピュータがユーザ固有の公開鍵ペアの秘密鍵を第２署名鍵として生成する手段を更に含み、前記管理者コンピュータが公開鍵ペアの公開鍵に対してユーザの識別情報を含まない匿名公開鍵証明証を発行する手段を更に含む請求項１記載の匿名通信システム。
4. 前記ユーザコンピュータが、前記第２公開鍵によって検証可能な第２署名鍵を管理者コンピュータとの通信を介して生成する手段と、該第２署名鍵を前記管理者に対して秘密に保持する手段とを更に含む請求項１記載の匿名通信システム。
5. 前記ユーザデータ登録手段に登録されるユーザデータが、前記第１署名鍵と対をなす第１公開鍵が記載された第１公開鍵証明証を含む請求項１〜４の何れか一項に記載の匿名通信システム。
6. 前記第１公開鍵証明証がユーザを一意に識別する情報を含み、前記管理者は第１公開鍵証明証に記載された第１公開鍵からユーザを特定可能である請求項５記載の匿名通信システム。
7. 前記第１公開鍵証明証がユーザを一意に識別する情報を含まず、前記管理者は第１公開鍵証明証に記載された公開鍵からユーザを特定することが不可能である請求項５に記載の匿名通信システム。
8. 前記第２署名鍵がグループ署名の署名鍵であり、前記管理者は第２署名鍵による電子署名からユーザを特定することが不可能である請求項１〜７の何れか一項に記載の匿名通信システム。
9. 前記第２署名鍵がユーザ毎に異なる署名鍵であり、第２署名鍵と対をなす前記第２公開鍵は第２公開鍵証明証に記載され公開されるが、第２公開鍵証明証にユーザを一意に識別する情報が記載されていないか、ユーザを一意に識別する情報の代わりにユーザの仮名が記載されているため、前記管理者は第２署名鍵による電子署名からユーザを特定することが不可能である請求項１〜７の何れか一項に記載の匿名通信システム。
10. 前記管理者コンピュータは、ユーザデータ登録手段からユーザデータを読み出す手段と、読み出したユーザデータ中にユーザを一意に識別可能な情報が含まれている場合に、該情報に基づいて前記ユーザの身許を特定する手段と、読み出したユーザデータ中にユーザを一意に識別可能な情報が含まれていない場合に、前記ユーザが作成した前記署名付きデータを提示して前記別の通信システムの管理者に前記ユーザの身許を照会する手段とを更に含む請求項１記載の匿名通信システム。
11. 請求項１〜１０の何れか一項に記載された第１匿名通信システムと、請求項１〜１０の何れか一項に記載された第２匿名通信システムとを含み、第１匿名通信システムの第２署名鍵が第２匿名通信システムの第１署名鍵として使用されることを特徴とする複合的匿名通信システム。
12. 前記第２匿名通信システムの管理者コンピュータは、前記ユーザデータ登録手段から当該第２匿名通信システムに加入済みのユーザが作成した前記署名付きデータを特定する手段と、特定した前記署名付きデータを提示して第１匿名通信システムの管理者に前記加入済みユーザの身許を照会する手段とを備える請求項１１記載の複合的匿名通信システム。
13. ユーザの匿名による通信を可能とする匿名通信システムに加入するために、前記ユーザが操作するユーザコンピュータと、当該匿名通信システムの管理者が操作する管理者コンピュータとが実行する方法であって、
    前記ユーザコンピュータが、当該匿名通信システムとは別の通信システムで使用可能なユーザ固有の第１署名鍵と、当該匿名通信システムで使用するユーザ固有の第２署名鍵とにより二重に電子署名が付された署名付きデータを生成する段階と、
    前記署名付きデータをユーザコンピュータから管理者コンピュータに提供する段階と、
    前記管理者コンピュータが、前記第１署名鍵と対をなす第１公開鍵と前記第２署名鍵と対をなす第２公開鍵を用いて前記電子署名を検証する段階と、
    前記電子署名の正当性が検証されたときに、前記管理者コンピュータが、前記署名付きデータを含むユーザデータを登録する段階とを含むことを特徴とする方法。
14. 前記第２署名鍵が、管理者コンピュータによって生成され、管理者コンピュータからユーザコンピュータに提供される請求項１３記載の方法。
15. 前記管理者コンピュータは、ユーザコンピュータから提供された前記第１署名鍵を検証した後に前記第２署名鍵をユーザコンピュータに提供する請求項１４記載の方法。
16. 前記第２署名鍵が、ユーザ固有の公開鍵ペアの秘密鍵であり、ユーザコンピュータから管理者コンピュータに提供され、管理者コンピュータが前記公開鍵ペアの公開鍵に対してユーザの識別情報を含まない匿名公開鍵証明証を発行する請求項１３記載の方法。
17. 前記第２署名鍵が、前記第２公開鍵で検証可能となるように管理者コンピュータとの通信を介してユーザコンピュータにより生成され、かつ管理者に対して秘密に保持される請求項１３記載の方法。
18. 前記第２署名鍵が、グループ署名の署名鍵であり、グループ署名における署名鍵の生成手順に従って生成される請求項１３〜１７の何れか一項に記載の方法。

Images