Notice: Undefined variable: fterm_desc_sub in /mnt/www/biblio_conv.php on line 353
匿名認証システム
説明

匿名認証システム

【課題】公開鍵の大きさを小さくすることにより通信負荷を低減させた匿名認証システムを提供する。
【解決手段】管理装置と、メンバ用装置と、認証装置とからなる匿名認証システムにおいて、管理装置には、メンバを複数のサブグループに分けて、サブグループ用IDと個人用IDとに基づいて生成した所属証明書を記憶した所属証明書用テーブルと、各サブグループの有効なメンバの個人用IDを用いてアキュームレータにより定義された値を公開鍵として記憶した公開鍵用テーブルと、サブグループ用IDにより特定されるサブグループの公開鍵とサブグループ用IDとを用いて生成した補助証明書を記憶した補助証明書用テーブルとを設けて、メンバ用装置の記憶手段に、当該メンバ用の所属証明書と補助証明書を記憶させるとともに、公開鍵を記憶させることとした。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、匿名認証システムに関するものであり、特に、グループ署名を利用した匿名認証システムに関するものである。
【背景技術】
【0002】
インターネットなどのネットワークを利用したサービス提供においては、そのサービスを利用するユーザを管理するために、一般的にIDとパスワードを用いた個人認証が行われており、この個人認証をパスしたユーザのみにサービスを提供するようにしている。
【0003】
この個人認証は、認証サーバと呼ばれる認証装置を用いて行われているが、認証サーバによる認証処理に基づいて、認証サーバには認証履歴がログとして蓄積されることとなっている。
【0004】
この認証履歴は、どのユーザが、いつ、何をしたかといった情報で構成されており、この情報を解析することにより、ユーザのアクセス履歴などの個人情報の取得が可能であり、認証履歴の漏洩は、個人情報の漏洩と同じ意味合いを持っていることとなっている。
【0005】
したがって、認証サーバでは、認証履歴が漏洩することを防止する必要があり、厳重な管理が求められている。
【0006】
このような認証サーバにおける個人ユーザの認証履歴の蓄積を回避するために、匿名での認証を可能とする方法としてグループ署名が提案されている。
【0007】
グループ署名では、各ユーザが所定のグループに所属していることを認証するものであり、認証の際にユーザを個々に特定することなく認証可能としている。
【0008】
すなわち、グループ署名において、管理者は、個々のユーザを識別するためのIDを設けているが、ユーザにはそのIDに基づいて生成した所属証明書をIDの代わりに付与し、各ユーザは、個々の所属証明書に基づいて、所属証明書の所持をその所属証明書自体を漏らすことなく保証する署名を生成し、この署名を所定の認証サーバで検証している。
【0009】
より具体的に説明すると、管理者は、管理上、ユーザiのIDをxiとして管理しており、各ユーザ用の所属証明書Cert(xi)を生成して、この所属証明書Cert(xi)をユーザiに付与している。
【0010】
ユーザiは、インターネットなどの電気通信回線を介して所定のサービスを受ける場合に、所属証明書Cert(xi)から生成した署名を認証サーバに送信し、認証サーバでは、公開鍵を用いて、送信されてきた署名が正しい署名であるかどうかを検証して、署名が正しければユーザiの利用を許可することとしている。なお、署名からxiを特定できないことは、数学的に保証されている。また、管理者は、所定の公開鍵を公開している。
【0011】
このように、認証サーバには、個人を特定できる秘密情報のxiではなく署名が蓄積されるだけであり、この署名からxiが特定できないという匿名性を有していることから、個人情報の漏洩の問題を解消可能となっている。
【0012】
一方で、ユーザiのIDであるxiを管理している管理者だけは、署名からユーザiを特定でき、管理者だけが厳重な情報漏洩対策を施すことにより情報漏洩を防止でき、認証サーバにおける情報漏洩対策を不要として、管理コストを低減可能となっている。そして、不正行為などでユーザiを特定する必要がある場合のみ、管理者がユーザiを特定することにより、信頼性を維持可能としている。なお、グループ署名では、一般的に「ユーザ」を「メンバ」と称しており、本発明においては、「メンバ」の呼称を用いることとする。
【0013】
しかしながら、このような匿名認証を可能とするグループ署名には、個々のメンバを特定しないことのデメリットとして、サービスの利用の停止を申告したメンバや、メンバとしての権限を剥奪されたメンバなどの失効者を特定することが困難となっていた。
【0014】
すなわち、認証サーバに署名データを送信したメンバが、失効者であるかどうかを判断するための処理を、メンバを特定することなく行わなければならないからである。
【0015】
このような、失効者を判別する失効処理を行う方法として、いくつかの方法が提案されている。
【0016】
その一つとして、全メンバのIDの集合、すなわち、x1,・・・,xnを用いてアキュームレータによりf(x1,・・・,xn)=yとして定義される値yをグループの公開鍵として用いるとともに、失効者が発生するごとにグループの公開鍵を更新し、更新されたグループの公開鍵に基づいて各メンバのアキュームレータに関する秘密鍵wjを更新させて、この新しい秘密鍵wjに基づいて署名を生成させる方法が提案されている(例えば、非特許文献1及び非特許文献2参照。)。
【0017】
この場合には、失効の設定がされたメンバは秘密鍵wjを生成できないため、署名を生成して認証サーバで検証された際に正しい署名とは認識できず、失効者を確実に排除することができる。
【0018】
この方式では、xiがアキュームレートされていることを保証するための演算負荷が、失効されたメンバの数に依存しないため、演算を高速化できることとなっている。
【先行技術文献】
【非特許文献】
【0019】
【非特許文献1】Camenish, Lysyanskaya: Dynamic Accumulators and Application to Efficient Revocation of Anonymous Credentials. CRYPTO 2002, pp. 61-76, 2002.
【非特許文献1】Camenish, Kohlweiss, Soriente: An Accumulator Based on Bilinear Maps and Efficient Revocation for Anonymous Credentials. PKC 2009, pp. 481-500, 2009.
【発明の概要】
【発明が解決しようとする課題】
【0020】
しかしながら、アキュームレータによりf(x1,・・・,xn)=yとして定義される値yをグループの公開鍵として用いた場合には、グループの公開鍵に全メンバのIDを用いるため、大規模なグループを構成した際に公開鍵が極めて大きくなり、グループの公開鍵を各メンバに受け渡すための通信負荷が大きくなって、この通信負荷の影響が無視できなくなるおそれがあった。
【0021】
そこで、本発明者は、公開鍵の大きさを小さくすることにより通信負荷を低減させるべく研究開発を行って本発明を成すに至ったものである。
【課題を解決するための手段】
【0022】
本発明の匿名認証システムでは、グループに所属するメンバにそれぞれ付与する所属証明書、失効状態のメンバの情報である失効情報、及び公開鍵を管理する管理手段を備えた管理装置と、前記所属証明書を記憶する記憶手段、及びこの記憶手段に記憶された前記所属証明書を用いて署名を生成する署名生成手段を備えたメンバ用装置と、前記メンバ用装置から送信されてきた前記署名を検証する検証手段を備えた認証装置とからなる匿名認証システムにおいて、前記管理装置には、前記メンバを複数のサブグループに分けて、サブグループ用IDと個人用IDとに基づいて生成した前記所属証明書を記憶した所属証明書用テーブルと、各サブグループの有効なメンバの個人用IDを用いてアキュームレータにより定義された値を公開鍵として記憶した公開鍵用テーブルと、前記サブグループ用IDにより特定されるサブグループの公開鍵と前記サブグループ用IDとを用いて生成した補助証明書を記憶した補助証明書用テーブルとを設けて、前記メンバ用装置の前記記憶手段に、当該メンバ用の所属証明書と補助証明書を記憶させるとともに、前記公開鍵を記憶させることとした。
【0023】
また、本発明の匿名認証システムでは、管理装置が、失効情報が更新されるたびに公開鍵用テーブルに記憶された公開鍵を更新する公開鍵更新手段を有することにも特徴を有するものである。
【0024】
さらに、本発明の匿名認証システムでは、サブグループの数を、メンバの総数をNとした場合にN1/2以上で最小の整数とすることにも特徴を有するものである。
【発明の効果】
【0025】
本発明によれば、メンバをサブグループに分けることにより公開鍵の鍵長を短くすることができ、公開鍵の通信負荷を低減して、高速に匿名認証を実行できる。
【0026】
また、公開鍵の鍵長が短く成ることにより、公開鍵を用いた演算の速度を向上させることができ、演算処理の高速化をはかることもできる。
【0027】
特に、メンバの総数をNとした場合に、N1/2以上で最小の整数の数のサブグループを設けた場合には、各サブグループに所属するメンバの数をN1/2程度とすることができ、例えばメンバの総数が100万人の場合、サブグループのメンバの総数は1000人となって、最も高速に匿名認証を実行できる。
【図面の簡単な説明】
【0028】
【図1】本実施形態に係る匿名認証システムのシステム構成説明図である。
【図2】本実施形態に係る匿名認証システムの動作シーケンスの説明図である。
【発明を実施するための形態】
【0029】
本発明の匿名認証システムは、グループ署名を利用したものであり、図1に示すように、インターネットなどの電気通信回線10には、管理者が使用する管理装置20と、メンバが使用するメンバ用装置30と、認証処理を実行する認証装置40を接続して、メンバ用装置30で生成した署名の検証を認証装置40で行うこととしている。
【0030】
管理装置20と、メンバ用装置30と、認証装置40は、それぞれ電子計算機で構成しており、電気通信回線10に接続可能としている。特に、管理装置20と認証装置40は、単一の電子計算機で構成する場合に限定するものではなく、複数台の電子計算機で構成してもよい。
【0031】
また、図1では、管理装置20を、認証装置40から独立させて設けているが、管理装置20は必ずしも認証装置40から独立している必要はなく、管理装置20と認証装置40とを専用回線で接続し、認証装置40を経由させて管理装置20を電気通信回線10に接続させてもよい。
【0032】
管理装置20には、グループに所属するメンバにそれぞれ付与する所属証明書、失効状態のメンバの情報である失効情報、及び公開鍵を管理する管理手段を設けている。
【0033】
特に、メンバは複数のサブグループに分けおり、所属するサブグループのIDと、サブグループ内での個人用IDとを一組として1人のメンバを特定するIDとしている。ここで、説明の便宜上、サブグループのIDをSjとし、サブグループ内での個人用IDをxiで表すこととする。
【0034】
管理装置20に設けた管理手段は、具体的には、サブグループ用IDと個人用IDとに基づいて生成した所属証明書を記憶した所属証明書用テーブルと、各サブグループの有効なメンバの個人用IDを用いてアキュームレータにより定義された値を公開鍵として記憶した公開鍵用テーブルと、サブグループ用IDにより特定されるサブグループの公開鍵とサブグループ用IDとを用いて生成した補助証明書を記憶した補助証明書用テーブルである。
【0035】
ここで、説明の便宜上、サブグループ用IDであるSjと個人用IDであるとxiに基づいて生成した所属証明書をCert(Sj,xi)と表すこととする。なお、i=1,2,・・・,m、j=1,2,・・・,kである。
【0036】
所属証明書用テーブルには、全メンバのCert(Sj,xi)(i=1,2,・・・,m、j=1,2,・・・,k)を記憶している。
【0037】
また、公開鍵用テーブルに記憶される公開鍵はサブグループごとに設けており、サブグループの有効なメンバの個人用IDを用いてアキュームレータfにより、f(x1,・・・,xn)=yj(j=1,2,・・・,k)として定義し、公開鍵用テーブルに記憶している。
【0038】
補助証明書用テーブル記憶している補助証明書は、サブグループ用IDであるSjと、当該サブグループの公開鍵であるyjとから生成しており、説明の便宜上、補助証明書をCert(Sj,yj)と表すこととする。
【0039】
上述したように、公開鍵は、サブグループの有効なメンバの個人用IDを用いて生成しており、サービスの利用の停止を申告したメンバや、メンバとしての権限を剥奪されたメンバなどの失効者が発生した場合に、管理装置20は、公開鍵を更新している。
【0040】
具体的に説明すると、例えば、x1,x2,x3,x4,x5の5人のメンバでサブグループを構成していた場合、公開鍵はf(x1,x2,x3,x4,x5)=yであり、メンバx3が失効処理されると、管理装置20は、公開鍵更新手段によりf(x1,x2,x4,x5)=y'として新たな公開鍵を生成し、この新たな公開鍵を公開鍵用テーブルに記憶させている。
【0041】
さらに、公開鍵の更新にともなって、管理装置20では、公開鍵を用いて生成される補助証明書Cert(Sj,yj)を補助証明書更新手段により更新して、新たな補助証明書を補助証明書用テーブルに記憶させている。
【0042】
公開鍵更新手段及び補助証明書更新手段は、それぞれ所定のプログラムであって、管理装置20での失効処理にともなって適宜起動させて、公開鍵及び補助証明書をそれぞれ更新している。
【0043】
なお、管理装置20では、想定される最大のメンバ総数に基づいて所属証明書をあらかじめ準備しておき、所属証明書を付与していないメンバを失効者としておくことにより、メンバの増減に容易に対応できる。また、あらかじめ想定していたメンバの総数を超える人数のメンバを管理する必要が生じた場合には、サブグループ単位でメンバの総数を増やすことにより、比較的容易に対応できる。
【0044】
メンバ用装置30には、管理装置20を管理している管理者から付与された当該メンバ用の所属証明書Cert(Sj,xi)及び補助証明書Cert(Sj,yj)を記憶するとともに、管理装置20で公開されている公開鍵yjを記憶する記憶手段と、この所属証明書Cert(Sj,xi)と補助証明書Cert(Sj,yj)と公開鍵を用いて署名を生成する署名生成手段を設けている。
【0045】
ここで、所属証明書Cert(Sj,xi)と補助証明書Cert(Sj,yj)と公開鍵を記憶する記憶手段としては、一般的にはハードディスクであるが、ハードディスクに限定するものではなく、適宜の記憶装置であってもよい。特に、公開鍵は、署名の生成段階で電気通信回線10を介して管理装置20から取得して、適宜のメモリに記憶させてもよい。
【0046】
また、本実施形態では、メンバ用装置30は、署名を生成する際に、管理装置20から公開鍵yjを取得することとして、失効情報が反映された公開鍵yjを用いて署名を生成することとしている。さらに、メンバ用装置30では、取得した公開鍵yjを用いて補助証明書Cert(Sj,yj)を更新し、更新された補助証明書Cert(Sj,yj)を用いて署名を生成することとしている。
【0047】
署名生成手段は、メンバ用装置30で実行される所定のプログラムであって、記憶手段に記憶された所属証明書Cert(Sj,xi)と補助証明書Cert(Sj,yj)と公開鍵を用いて署名を生成している。特に、本実施形態では、ゼロ知識証明により所定の演算を行って署名を生成している。
【0048】
メンバ用装置30は、電気通信回線10を介して生成した署名を認証装置40に送信している。
【0049】
認証装置40には、メンバ用装置30から送信されてきた署名を検証する検証手段を設けている。
【0050】
検証手段は、認証装置40で実行される所定のプログラムであって、メンバ用装置30から送信されてきた署名と、管理装置20で公開されている公開鍵を用いて、送信されてきた署名の真偽を判定し、送信されてきた署名が正しい署名である場合、当該メンバによる所定のサービスの利用を許可することとしている。
【0051】
以下において、図2に示す説明図を用いて、本実施形態の匿名認証システムの動作について説明する。なお、以下においては、メンバ用装置30において署名を生成する際に公開鍵yjを取得する場合について説明する。
【0052】
また、通常、メンバ用装置30が署名を生成する操作はバックグラウンド処理として行われ、メンバがメンバ用装置30を用いて所定のサービスを利用しようとした場合に、バックグラウンドにおいて実行される動作である。
【0053】
ここで、管理装置20には、メンバxiがメンバとして登録されているものとし、メンバ用装置30の記憶手段には所属証明書Cert(Sj,xi)及び補助証明書Cert(Sj,yj)が記憶されているものとする。また、メンバ用装置30の記憶手段には、公開鍵yjも記憶されているものとする。
【0054】
まず、メンバ用装置30において、メンバが所定のサイトへのアクセスを要求すると(ステップS101)、メンバ用装置30は、管理装置20に公開鍵yjを送信するように要求する(ステップS102)。
【0055】
管理装置20は、要求に応じてメンバ用装置30に公開鍵yjを送信する(ステップS103)。なお、公開鍵yjは、管理装置20から取得する場合に限定するものではなく、認証装置40から取得してもよい。
【0056】
メンバ用装置30は、取得した公開鍵yjが失効情報に基づいて更新された公開鍵yjである場合に、メンバ用装置30の記憶手段に記憶した公開鍵yjを更新し、補助証明書Cert(Sj,yj)を更新させる(ステップS104)。
【0057】
次いで、メンバ用装置30は、所属証明書Cert(Sj,xi)と、更新した公開鍵yj及び補助証明書Cert(Sj,yj)を用いて署名を生成し(ステップS105)、生成した署名を認証装置40に送信する(ステップS106)。
【0058】
認証装置40では、署名を受信すると、管理装置20に公開鍵yjを送信するように要求する(ステップS107)。管理装置20は、要求に応じて認証装置40に公開鍵yjを送信し(ステップS108)、取得した公開鍵yjを用いて署名の検証処理を実行する(ステップS109)。
【0059】
認証装置40は、署名が正しい場合に、メンバによる所定のサイトへのアクセスを許可して(ステップS110)、当該サイトにアクセスさせている。
【0060】
上述したように、本実施形態の匿名認証システムでは、メンバをサブグループに分けておくことにより、公開鍵yjの鍵長を短くすることができ、公開鍵yjの通信負荷を低減して、高速に匿名認証を実行できる。
【0061】
また、公開鍵yjの鍵長が短くなることにより、公開鍵を用いた補助証明書Cert(Sj,yj)の送信処理を高速化できる。
【0062】
特に、メンバの総数をNとした場合に、N1/2以上で最小の整数の数のサブグループを設けた場合には、各サブグループに所属するメンバの数をN1/2程度とすることができ、例えばメンバの総数が100万人の場合、サブグループのメンバの総数は1000人となって、最も高速に匿名認証を実行できる。
【0063】
しかも、個人IDには、通常、拡大体の元が用いられるが、サブグループのIDと、サブグループ内の個人IDとでメンバを特定することにより、個人ID用として必要となる拡大体の元の数を大きく削減できるので、これによっても演算の高速化をはかることができる。
【符号の説明】
【0064】
10 電気通信回線
20 管理装置
30 メンバ用装置
40 認証装置

【特許請求の範囲】
【請求項1】
グループに所属するメンバにそれぞれ付与する所属証明書、失効状態のメンバの情報である失効情報、及び公開鍵を管理する管理手段を備えた管理装置と、
前記所属証明書を記憶する記憶手段、及びこの記憶手段に記憶された前記所属証明書を用いて署名を生成する署名生成手段を備えたメンバ用装置と、
前記メンバ用装置から送信されてきた前記署名を検証する検証手段を備えた認証装置と
からなるグループ署名システムにおいて、
前記管理装置には、
前記メンバを複数のサブグループに分けて、サブグループ用IDと個人用IDとに基づいて生成した前記所属証明書を記憶した所属証明書用テーブルと、
各サブグループの有効なメンバの個人用IDを用いてアキュームレータにより定義された値を公開鍵として記憶した公開鍵用テーブルと、
前記サブグループ用IDにより特定されるサブグループの公開鍵と前記サブグループ用IDとを用いて生成した補助証明書を記憶した補助証明書用テーブルと
を設けて、前記メンバ用装置の前記記憶手段に、当該メンバ用の所属証明書と補助証明書を記憶させるとともに、前記公開鍵を記憶させているグループ署名システム。
【請求項2】
前記管理装置は、前記失効情報が更新されるたびに前記公開鍵用テーブルに記憶された前記公開鍵を更新する公開鍵更新手段を有する請求項1に記載のグループ署名システム。
【請求項3】
前記サブグループの数は、前記メンバの総数をNとした場合に、N1/2以上で最小の整数とする請求項1または請求項2に記載のグループ署名システム。

【図1】
image rotate

【図2】
image rotate


【公開番号】特開2011−114504(P2011−114504A)
【公開日】平成23年6月9日(2011.6.9)
【国際特許分類】
【出願番号】特願2009−268168(P2009−268168)
【出願日】平成21年11月26日(2009.11.26)
【出願人】(504147243)国立大学法人 岡山大学 (444)
【Fターム(参考)】