JP7617481B2 - 情報処理プログラム、情報処理方法、および情報処理装置 - Google Patents

Description

本発明は、情報処理プログラム、情報処理方法、および情報処理装置に関する。

マッチングシステムは、需要と供給を結び付けるためのサービスである。マッチングシステムは、求人マッチング、リソースマッチング、フリーマーケット、マッチングアプリなどの様々な形で展開されている。マッチングシステムでは、例えば、ユーザが提出する属性情報と、別のユーザが提出する属性への興味とを突合することで、ユーザ同士のマッチングが行われる。

先行技術としては、例えば、患者の身元を保護する方法で医療記録を集約するものがある。また、訪問者の特徴部分の少なくとも一部を秘匿化した秘匿化メディア情報を生成し、秘匿化メディア情報と、蓄積された登録秘匿化メディア情報とを秘匿化したまま照合して照合結果を生成する技術がある。登録秘匿化メディア情報は、不特定の人物が記録されたメディア情報において人物の特徴部分の少なくとも一部を秘匿化した情報である。

米国特許出願公開第２０１５／０１４９２０８号明細書 特開２０１６－７１６３９号公報

しかしながら、従来技術では、マッチング対象となるユーザについてのデータの内容を第三者に秘匿しつつ、データの真正性を担保することが難しい。

一つの側面では、本発明は、データの内容を第三者に秘匿しつつ、データの真正性を担保することを目的とする。

１つの実施態様では、第１鍵を用いた指数化により第１データを暗号化した第１暗号化データと、前記第１データに付与された電子署名と、前記電子署名が前記第１暗号化データの元データの真正性を検証可能な情報であることを証明するための証明情報とを受け付け、第２鍵を用いた指数化により第２データを暗号化した第２暗号化データを受け付け、前記証明情報を用いて前記電子署名の正当性を検証し、前記第１鍵および前記第２鍵を管理する管理装置から、所定の関数を用いて前記第１鍵および前記第２鍵から演算された第１演算結果を取得し、取得した前記第１演算結果と、前記所定の関数を用いて前記第１暗号化データおよび前記第２暗号化データから演算される第２演算結果とを照合する、情報処理プログラムが提供される。

本発明の一側面によれば、データの内容を第三者に秘匿しつつ、データの真正性を担保することができるという効果を奏する。

図１は、実施の形態１にかかる情報処理方法の一実施例を示す説明図である。 図２は、情報処理システム２００のシステム構成例を示す説明図である。 図３は、マッチング装置２０１等のハードウェア構成例を示すブロック図である。 図４は、鍵保管ＤＢ２２０の記憶内容の一例を示す説明図である。 図５は、鍵管理サーバ２０２の機能的構成例を示すブロック図である。 図６は、クライアント端末Ｃｉの機能的構成例を示すブロック図である。 図７は、マッチング装置２０１の機能的構成例を示すブロック図である。 図８は、マッチング装置２０１のマッチング処理例を示す説明図である。 図９は、実施の形態１にかかる情報処理システム２００の動作例を示す説明図である。 図１０は、鍵管理サーバ２０２のセットアップ処理手順の一例を示すフローチャートである。 図１１は、クライアント端末Ｃｉの鍵生成／アップデート処理手順の一例を示すフローチャートである。 図１２は、鍵管理サーバ２０２の鍵登録処理手順の一例を示すフローチャートである。 図１３は、情報処理システム２００のマッチング処理手順を示すシーケンス図（その１）である。 図１４は、情報処理システム２００のマッチング処理手順を示すシーケンス図（その２）である。 図１５は、クライアント端末Ｃｉの証明生成処理の具体的処理手順の一例を示すフローチャートである。 図１６は、マッチング装置２０１の証明検証処理の具体的処理手順の一例を示すフローチャートである。 図１７は、マッチング装置２０１の照合処理の具体的処理手順の一例を示すフローチャートである。 図１８は、情報処理システム２００の実施例を示す説明図である。 図１９は、実施の形態２にかかる情報処理システム２００の動作例を示す説明図である。

以下に図面を参照して、本発明にかかる情報処理プログラム、情報処理方法、および情報処理装置の実施の形態を詳細に説明する。

（実施の形態）
図１は、実施の形態１にかかる情報処理方法の一実施例を示す説明図である。図１において、情報処理装置１０１は、暗号化されたデータ同士を照合するコンピュータである。暗号化されたデータ同士の照合とは、例えば、暗号化されたデータ同士を突き合わせて一致するか否かを判定することである。

暗号化されたデータの元の平文（元データ）は、マッチング対象となるユーザについてのデータであり、例えば、属性情報や要件情報である。属性情報は、ユーザの属性を示す情報である。要件情報は、ユーザが要求する属性に対する条件（興味など）を示す情報である。

マッチングシステムにおいて、ユーザ同士のマッチングは、例えば、ユーザが提出する属性情報と、別のユーザが提出する属性への興味とを突合することで行われる。求人マッチングを例に挙げると、学生が提出する属性情報（年齢、学歴、職歴など）と、企業が提出する雇用条件（年齢、学歴、職歴など）とを突合することでマッチングが行われる。

しかし、既存のマッチングシステムでは、ユーザが提出する属性情報の正しさを厳密には要求しない、もしくは要求したとしても、その正しさのチェックを自動化していない場合があり、属性情報の真正性を担保することが難しい。例えば、求人マッチングにおいて、学生は自らの学歴や成績などを提出するものの、その正しさの証明は義務化されていない場合が多く、また、その正しさを自動的にチェックする機構が用意されていない場合が多い。

また、マッチングシステムにおいて、ユーザは、自らのパーソナルデータを、マッチングシステムの運営者に無加工のまま提出する場合がある。この場合、運営者に多くのパーソナルデータが蓄積されていくことになり、ユーザがプライバシーに懸念を抱いたり、運営者が漏洩時のリスクを考慮したりすることになる。

ここで、属性情報の真正性の課題に関しては、既存の各種電子署名方式を用いて、ユーザが提出する属性情報に信頼できる第三者が署名することで、真正性を検証可能にすることができる。しかし、電子署名方式だけでは、プライバシーの課題を解決することはできない。

一方、プライバシーの課題に関しては、Ｒｅｌａｔｉｏｎａｌ Ｈａｓｈ（非特許文献１）などの既存技術を用いることで、ユーザの提出した属性情報および属性への興味を秘匿したまま、第三者に突合させることが可能である。しかし、Ｒｅｌａｔｉｏｎａｌ Ｈａｓｈ方式だけでは、属性情報の真正性の課題を解決することはできない。

Ｒｅｌａｔｉｏｎａｌ Ｈａｓｈとは、ある関係性（例えば、等しいという関係性）を満たす２つの平文について、ある鍵を用いてハッシュ化する方法であって、その鍵を知る第三者が元の平文を知ることなしに、その２つの平文が関係性を満たすかどうかを知ることができる技術である。なお、Ｒｅｌａｔｉｏｎａｌ Ｈａｓｈについては、例えば、下記非特許文献１を参照することができる。

非特許文献１：Ｍａｎｄａｌ， Ａｖｒａｄｉｐ， ａｎｄ Ａｒｎａｂ Ｒｏｙ． “Ｒｅｌａｔｉｏｎａｌ ｈａｓｈ： ｐｒｏｂａｂｉｌｉｓｔｉｃ ｈａｓｈ ｆｏｒ ｖｅｒｉｆｙｉｎｇ ｒｅｌａｔｉｏｎｓ， ｓｅｃｕｒｅ ａｇａｉｎｓｔ ｆｏｒｇｅｒｙ ａｎｄ ｍｏｒｅ．” Ａｎｎｕａｌ Ｃｒｙｐｔｏｌｏｇｙ Ｃｏｎｆｅｒｅｎｃｅ． Ｓｐｒｉｎｇｅｒ， Ｂｅｒｌｉｎ， Ｈｅｉｄｅｌｂｅｒｇ，２０１５．

ここで、Ｒｅｌａｔｉｏｎａｌ Ｈａｓｈ方式を求人マッチングに適用した場合を例に挙げて、属性情報の真正性の課題について説明する。まず、信頼できる第三者が鍵を一つ用意し、ユーザ同士で共有する。学生は、ハッシュ関数Ｈａｓｈ１を用いて、提出する属性情報（学歴）をハッシュ化する。企業は、ハッシュ関数Ｈａｓｈ２を用いて、属性への興味である求人要件（学歴）をハッシュ化する。

そして、マッチング事業者は、信頼できる第三者から提供される同じ鍵を用いて、ハッシュ値の元の平文を知らずに突合を行う。この際、マッチング事業者は、２つの文字列（ハッシュ値）が、元々等しい平文のハッシュであること、または、元々異なる平文のハッシュであることを検知することができるが、元の平文の内容を知ることはできない。したがって、学生の学歴に関するプライバシーは保護される。

このように、Ｒｅｌａｔｉｏｎａｌ Ｈａｓｈ方式では、プライバシーの課題を解決する一方で、属性情報の真正性の課題を解決することができない。また、属性情報の正しさを担保する技術として、電子署名技術があるが、平文に対する署名は、ハッシュ値に対する署名ではないため、そのまま適用することはできない。

例えば、Ｒｅｌａｔｉｏｎａｌ Ｈａｓｈ方式を求人マッチングに適用した場合において、学生の属性情報（学歴）に電子署名が付与されており、属性情報（学歴）に対する真正性が担保されているとする。しかし、属性情報（学歴）のハッシュ値に対しては、その電子署名は有効ではないため、真正性を担保することができない。

なお、既存の電子署名技術を利用して、属性情報（学歴）のハッシュ値に再度署名を依頼することが考えられる。例えば、属性情報（学歴）が学生の卒業大学名、属性情報に付与された電子署名がその卒業大学による署名であるとする。この場合、属性情報（学歴）のハッシュ値に対しても、卒業大学の署名を付与してもらう方法が考えられる。

しかし、この方法では、大学側は、ハッシュ値に署名を発行することになる。したがって、大学側は、そのハッシュ値がどの平文のハッシュ値なのかを了解する必要がある。ところが、Ｒｅｌａｔｉｏｎａｌ Ｈａｓｈにおけるハッシュ化は、確率的アルゴリズムである。

このため、大学側に、例えば、平文ｍ、ハッシュ値Ｈ、ハッシュ関数Ｈａｓｈ１を提示しても、「ハッシュ値Ｈが平文ｍをハッシュ関数Ｈａｓｈ１によってハッシュ化したものである」ことを大学側が確かめることは難しい。さらに、この方法は、署名を発行する大学への新たなアプリケーションの開発なども要請するため、マッチングシステムの運用コストの増大を招くおそれがある。

そこで、本実施の形態では、マッチング対象となるユーザについてのデータの内容を第三者に秘匿しつつ、データの真正性を担保する情報処理方法について説明する。以下、情報処理装置１０１の処理例（下記（１）～（５））について説明する。

（１）情報処理装置１０１は、第１暗号化データ１１１と電子署名１１２と証明情報１１３とを受け付ける。ここで、第１暗号化データ１１１は、第１鍵ｋ１を用いた指数化により第１データ１１０を暗号化した情報（暗号文）である。第１データ１１０は、マッチング対象となる第１ユーザ１０３についてのデータであり、例えば、第１ユーザ１０３の属性を示す属性情報である。

第１鍵ｋ１は、暗号化に用いられる鍵であり、第１ユーザ１０３によって生成されて、管理装置１０２において管理されている。電子署名１１２は、第１データ１１０に付与されている署名であり、例えば、署名者の公開鍵を用いて第１データ１１０の真正性を検証可能な情報である。

証明情報１１３は、電子署名１１２が第１暗号化データ１１１の元データの真正性を検証可能な情報であることを証明するための情報である。証明情報１１３は、例えば、電子署名１１２が署名者の公開鍵を用いて第１暗号化データ１１１の元データの真正性を検証可能な情報であることを証明するためのゼロ知識証明文を含む。ゼロ知識証明とは、自分が秘密情報を知っているという事実を、検証者に対して秘密情報そのものを開示せずに証明する手法である。

（２）情報処理装置１０１は、第２暗号化データ１２１を受け付ける。ここで、第２暗号化データ１２１は、第２鍵ｋ２を用いた指数化により第２データ１２０を暗号化した情報（暗号文）である。第２データ１２０は、マッチング対象となる第２ユーザ１０４についてのデータであり、例えば、第２ユーザ１０４が要求する属性に対する条件を示す要件情報である。第２鍵ｋ２は、暗号化に用いられる鍵であり、第２ユーザ１０４によって生成されて、管理装置１０２において管理されている。

（３）情報処理装置１０１は、証明情報１１３を用いて電子署名１１２の正当性を検証する。情報処理装置１０１は、証明情報１１３を用いて電子署名１１２の正当性を検証することによって、第１暗号化データ１１１の真正性を担保し、ひいては、第１暗号化データ１１１の元データ（第１データ１１０）の真正性を担保する。

具体的には、例えば、情報処理装置１０１は、公開鍵と電子署名１１２と第１暗号化データ１１１とを用いて、証明情報１１３に含まれるゼロ知識証明文を証明することによって、電子署名１１２の正当性を検証する。公開鍵は、例えば、証明情報１１３に含まれていてもよく、また、電子署名１１２の署名者から取得されてもよい。

（４）情報処理装置１０１は、管理装置１０２から、第１演算結果１３０を取得する。第１演算結果１３０は、所定の関数Ｆを用いて第１鍵ｋ１および第２鍵ｋ２から演算された演算結果である。所定の関数Ｆは、例えば、双準同型性のある演算を行うペアリング関数である。管理装置１０２は、信頼できる第三者の一例であり、第１鍵ｋ１および第２鍵ｋ２を外部に公開しないように管理する。

（５）情報処理装置１０１は、取得した第１演算結果１３０と、所定の関数Ｆを用いて第１暗号化データ１１１および第２暗号化データ１２１から演算される第２演算結果１４０とを照合する。具体的には、例えば、情報処理装置１０１は、所定の関数Ｆの双準同型性を利用して、第１演算結果１３０と第２演算結果１４０とが一致するか否かを判定することにより、元データ同士（第１データ１１０、第２データ１２０）が等しいかどうかを判断する。

このように、情報処理装置１０１によれば、マッチング対象となるユーザについてのデータの内容を第三者に秘匿しつつ、データの真正性を担保することができる。例えば、第１データ１１０の秘匿に指数化による暗号化を用いることで、第１暗号化データ１１１を簡単化してゼロ知識証明文といった証明情報１１３を生成することが可能になり、署名された第１データ１１０の真正性を担保することができる。さらに、第１暗号化データ１１１にも署名するというアプローチをとらないため、署名者に依頼してさらに署名を発行してもらうといった手続きを行わなくてもよい。また、例えば、指数化による暗号化とペアリングの双準同型性を用いることで、第１ユーザ１０３、第２ユーザ１０４についての第１データ１１０、第２データ１２０の内容を第三者（例えば、マッチング事業者）に秘匿しつつ、ユーザ同士のマッチングを行うことができる。

（情報処理システム２００のシステム構成例）
つぎに、実施の形態１にかかる情報処理システム２００のシステム構成例について説明する。情報処理システム２００は、例えば、求人マッチング、リソースマッチング、フリーマーケット、マッチングアプリなどのマッチングシステムに適用される。

以下の説明では、図１に示した情報処理装置１０１を、情報処理システム２００内のマッチング装置２０１に適用した場合を例に挙げて説明する。また、図１に示した管理装置１０２を、情報処理システム２００内の鍵管理サーバ２０２に適用した場合を例に挙げて説明する。

図２は、情報処理システム２００のシステム構成例を示す説明図である。図２において、情報処理システム２００は、マッチング装置２０１と、鍵管理サーバ２０２と、クライアント端末Ｃ１～Ｃｎ（ｎ：２以上の自然数）と、を含む。情報処理システム２００において、マッチング装置２０１、鍵管理サーバ２０２およびクライアント端末Ｃ１～Ｃｎは、有線または無線のネットワーク２１０を介して接続される。ネットワーク２１０は、例えば、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどである。

ここで、マッチング装置２０１は、暗号化されたデータ同士のマッチングを行うコンピュータである。マッチング装置２０１は、例えば、マッチングシステムを提供する事業者（マッチング事業者）のサーバである。

鍵管理サーバ２０２は、鍵保管ＤＢ（Ｄａｔａｂａｓｅ）２２０を有し、データを暗号化するための鍵を管理するコンピュータである。鍵は、例えば、クライアント端末Ｃ１～Ｃｎにおいて生成される。鍵管理サーバ２０２は、例えば、マッチングに関わる当事者（ユーザ、マッチング事業者）以外の信頼できる第三者のサーバである。

なお、鍵保管ＤＢ２２０の記憶内容については、図４を用いて後述する。

クライアント端末Ｃ１～Ｃｎは、情報処理システム２００のユーザが使用するコンピュータである。クライアント端末Ｃ１～Ｃｎは、例えば、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、タブレットＰＣ、スマートフォンなどである。なお、図１に示した第１ユーザ１０３および第２ユーザ１０４は、例えば、情報処理システム２００のユーザに相当する。

以下の説明では、クライアント端末Ｃ１～Ｃｎのうちの任意のクライアント端末を「クライアント端末Ｃｉ」と表記する場合がある（ｉ＝１，２，…，ｎ）。

（マッチング装置２０１等のハードウェア構成例）
つぎに、図３を用いて、マッチング装置２０１、鍵管理サーバ２０２およびクライアント端末Ｃｉのハードウェア構成例について説明する。ここでは、マッチング装置２０１、鍵管理サーバ２０２およびクライアント端末Ｃｉを「マッチング装置２０１等」と表記する。

図３は、マッチング装置２０１等のハードウェア構成例を示すブロック図である。図３において、マッチング装置２０１等は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３０１と、メモリ３０２と、ディスクドライブ３０３と、ディスク３０４と、通信Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）３０５と、可搬型記録媒体Ｉ／Ｆ３０６と、可搬型記録媒体３０７と、を有する。また、各構成部は、バス３００によってそれぞれ接続される。

ここで、ＣＰＵ３０１は、マッチング装置２０１等の全体の制御を司る。ＣＰＵ３０１は、複数のコアを有していてもよい。メモリ３０２は、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）およびフラッシュＲＯＭなどを有する。具体的には、例えば、フラッシュＲＯＭがＯＳのプログラムを記憶し、ＲＯＭがアプリケーションプログラムを記憶し、ＲＡＭがＣＰＵ３０１のワークエリアとして使用される。メモリ３０２に記憶されるプログラムは、ＣＰＵ３０１にロードされることで、コーディングされている処理をＣＰＵ３０１に実行させる。

ディスクドライブ３０３は、ＣＰＵ３０１の制御に従ってディスク３０４に対するデータのリード／ライトを制御する。ディスク３０４は、ディスクドライブ３０３の制御で書き込まれたデータを記憶する。ディスク３０４としては、例えば、磁気ディスク、光ディスクなどが挙げられる。

通信Ｉ／Ｆ３０５は、通信回線を通じてネットワーク２１０に接続され、ネットワーク２１０を介して外部のコンピュータに接続される。そして、通信Ｉ／Ｆ３０５は、ネットワーク２１０と装置内部とのインターフェースを司り、外部のコンピュータからのデータの入出力を制御する。通信Ｉ／Ｆ３０５には、例えば、モデムやＬＡＮアダプタなどを採用することができる。

可搬型記録媒体Ｉ／Ｆ３０６は、ＣＰＵ３０１の制御に従って可搬型記録媒体３０７に対するデータのリード／ライトを制御する。可搬型記録媒体３０７は、可搬型記録媒体Ｉ／Ｆ３０６の制御で書き込まれたデータを記憶する。可搬型記録媒体３０７としては、例えば、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）－ＲＯＭ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリなどが挙げられる。

なお、マッチング装置２０１等は、上述した構成部のほかに、例えば、入力装置、ディスプレイなどを有することにしてもよい。また、マッチング装置２０１等は、上述した構成部のうち、例えば、可搬型記録媒体Ｉ／Ｆ３０６、可搬型記録媒体３０７を有さないことにしてもよい。

（鍵保管ＤＢ２２０の記憶内容）
つぎに、鍵管理サーバ２０２が有する鍵保管ＤＢ２２０の記憶内容について説明する。鍵保管ＤＢ２２０は、例えば、図３に示した鍵管理サーバ２０２のメモリ３０２、ディスク３０４などの記憶装置により実現される。

図４は、鍵保管ＤＢ２２０の記憶内容の一例を示す説明図である。図４において、鍵保管ＤＢ２２０は、ＩＤおよび鍵のフィールドを有し、各フィールドに情報を設定することで、鍵管理情報（例えば、鍵管理情報４００－１，４００－２）をレコードとして記憶する。

ここで、ＩＤは、ユーザを一意に識別する識別子である。鍵は、ユーザに対応する鍵である。鍵は、クライアント端末Ｃｉにおいて生成されて、鍵管理サーバ２０２において管理される。例えば、鍵管理情報４００－１は、ユーザＵ１の鍵Ｋｅｙ１を示す。

（情報処理システム２００の機能的構成例）
つぎに、図５～図７を用いて、情報処理システム２００の機能的構成例について説明する。まず、図５を用いて、鍵管理サーバ２０２の機能的構成例について説明する。

図５は、鍵管理サーバ２０２の機能的構成例を示すブロック図である。図５において、鍵管理サーバ２０２は、セットアップ処理部５０１と、受付部５０２と、登録部５０３と、ペアリング演算部５０４と、を含む。セットアップ処理部５０１～ペアリング演算部５０４は制御部となる機能であり、具体的には、例えば、図３に示した鍵管理サーバ２０２のメモリ３０２、ディスク３０４、可搬型記録媒体３０７などの記憶装置に記憶されたプログラムをＣＰＵ３０１に実行させることにより、または、通信Ｉ／Ｆ３０５により、その機能を実現する。各機能部の処理結果は、例えば、鍵管理サーバ２０２のメモリ３０２、ディスク３０４などの記憶装置に記憶される。

セットアップ処理部５０１は、鍵生成に関する情報を設定する。鍵は、データを暗号化するための鍵である。具体的には、例えば、セットアップ処理部５０１は、素数ｐを設定する。また、セットアップ処理部５０１は、ドメインの集合Ｕを設定し、ＴＡＢＬＥ（辞書型対応ＴＡＢＬＥ）を設定する。

ここで、ドメインとは、例えば、ユーザから提供される属性や、属性への興味が取りうる空間および範囲のことである。辞書型対応ＴＡＢＬＥは、ドメインの集合Ｕの要素をキー、集合［ｐ］＝｛０，…，ｐ－１｝の要素をバリューとする。ただし、このＴＡＢＬＥを写像と同一視したとき、ＴＡＢＬＥ：Ｕ→［ｐ］は単射であるように設計する。

また、セットアップ処理部５０１は、ペアリング演算に関する情報を設定する。具体的には、例えば、セットアップ処理部５０１は、素数位数ｑの群Ｇと、素数位数ｐの群Ｈを設定する（ｑ＞ｐ）。また、セットアップ処理部５０１は、ペアリングｅを設定する。ここで、ペアリングｅは、双準同型性のある演算を行うペアリング関数である。

ここでは、ペアリングｅを「ｅ：Ｇ×Ｇ→Ｈ」とする。ペアリングｅ：Ｇ×Ｇ→Ｈは、任意のｇ₁，ｇ₂∈Ｇ，ｈ₁，ｈ₂∈Ｈに対して、ｅ（ｇ₁ｇ₂，ｈ₁）＝ｅ（ｇ₁，ｈ₁）ｅ（ｇ₂，ｈ₁）かつｅ（ｇ₁，ｈ₁ｈ₂）＝ｅ（ｇ₁，ｈ₁）ｅ（ｇ₁，ｈ₂）を満たす写像である（双準同型性）。

セットアップ処理部５０１は、ドメインの集合Ｕと、ＴＡＢＬＥと、素数位数ｑの群Ｇとを情報処理システム２００全体に公開する。

受付部５０２は、クライアント端末Ｃｉから鍵登録要求を受け付ける。ここで、鍵登録要求とは、鍵の登録を要求するものである。鍵登録要求には、例えば、ＩＤと鍵とが含まれる。ＩＤは、ユーザを一意に識別する識別子である。鍵は、クライアント端末Ｃｉにおいて生成された鍵である。具体的には、例えば、クライアント端末Ｃｉから鍵登録要求を受信することにより、受信した鍵登録要求を受け付ける。

登録部５０３は、ユーザと対応付けて、鍵を登録する。具体的には、例えば、登録部５０３は、鍵登録要求を受け付けた場合、鍵登録要求に含まれるＩＤと対応付けて、鍵登録要求に含まれる鍵を、図４に示した鍵保管ＤＢ２２０に登録する。なお、鍵登録要求に含まれるＩＤに対応する鍵が登録済みの場合、登録部５０３は、鍵登録要求に含まれる鍵で上書きすることにしてもよい。

また、受付部５０２は、マッチング装置２０１からペアリング演算要求を受け付ける。ここで、ペアリング演算要求とは、ペアリング演算の結果を要求するものである。ペアリング演算要求には、例えば、ペアリング対象となる２ユーザのＩＤの組み合わせ（例えば、Ｕ１とＵ２）が含まれる。

ペアリング演算部５０４は、ペアリング演算を行う。具体的には、例えば、ペアリング演算部５０４は、ペアリング演算要求を受け付けた場合、ペアリング演算要求に含まれる各ＩＤに対応する鍵を、鍵保管ＤＢ２２０から取得する。つぎに、ペアリング演算部５０４は、取得した各ＩＤに対応する鍵をペアリングｅに入力して計算することにより、ペアリングｅの演算結果を取得する。

そして、ペアリング演算部５０４は、ペアリングｅの演算結果をマッチング装置２０１に送信する。この際、ペアリング演算部５０４は、ペアリングｅの演算結果とともに、ペアリングｅをマッチング装置２０１に送信する。ただし、ペアリングｅは、ペアリング事業者（マッチング装置２０１）と事前に共有済みであってもよい。

つぎに、図６を用いて、クライアント端末Ｃｉの機能的構成例について説明する。

図６は、クライアント端末Ｃｉの機能的構成例を示すブロック図である。図６において、クライアント端末Ｃｉは、鍵生成部６０１と、暗号化部６０２と、証明生成部６０３と、通信部６０４と、を含む。鍵生成部６０１～通信部６０４は制御部となる機能であり、具体的には、例えば、図３に示したクライアント端末Ｃｉのメモリ３０２、ディスク３０４、可搬型記録媒体３０７などの記憶装置に記憶されたプログラムをＣＰＵ３０１に実行させることにより、または、通信Ｉ／Ｆ３０５により、その機能を実現する。各機能部の処理結果は、例えば、クライアント端末Ｃｉのメモリ３０２、ディスク３０４などの記憶装置に記憶される。

鍵生成部６０１は、鍵を生成する。具体的には、例えば、鍵生成部６０１は、鍵管理サーバ２０２によって公開された素数位数ｑの群Ｇの元を一つ選択することによって、鍵を生成する。そして、鍵生成部６０１は、自端末に対応するＩＤと、生成した鍵とを含む鍵登録要求を鍵管理サーバ２０２に送信する。自端末に対応するＩＤは、クライアント端末Ｃｉを使用するユーザのＩＤである。

これにより、クライアント端末Ｃｉのユーザは、自らの鍵を生成して、鍵管理サーバ２０２にアップロード（登録）することができる。

暗号化部６０２は、生成された鍵を用いて、マッチング対象となるデータを暗号化する。マッチング対象となるデータは、例えば、属性情報や要件情報である。属性情報は、ユーザの属性を示す情報である。ユーザの属性は、例えば、年齢、学歴、職歴、性別、業績などである。

要件情報は、ユーザが要求する他ユーザの属性に対する条件を示す情報である。他ユーザの属性に対する条件は、他ユーザの属性への興味に相当する。他ユーザの属性に対する条件は、例えば、企業（ユーザ）が求職者（他ユーザ）に要求する雇用条件（年齢、学歴、職歴、性別、業績など）である。

以下の説明では、マッチング対象となるデータのうち、一方のデータを「属性情報ｍ」と表記し、他方のデータを「要件情報ｎ」と表記する場合がある。また、属性情報ｍを提供するユーザ（属性情報提供者）の鍵を「ｇ」と表記し、要件情報ｎを提供するユーザ（要件情報提供者）の鍵を「ｈ」と表記する場合がある。

具体的には、例えば、暗号化部６０２は、鍵ｇを用いた指数化により属性情報ｍを暗号化する。より詳細に説明すると、例えば、暗号化部６０２は、鍵管理サーバ２０２によって公開されたＴＡＢＬＥを用いて、属性情報ｍをエンコードすることにより、属性値ｍを作成する。そして、暗号化部６０２は、鍵ｇをｍ乗することにより、暗号化データｍ’を生成する。暗号化データｍ’は、「ｍ’＝ｇ^m」である。

また、暗号化部６０２は、鍵ｈを用いた指数化により要件情報ｎを暗号化する。より詳細に説明すると、例えば、暗号化部６０２は、鍵管理サーバ２０２によって公開されたＴＡＢＬＥを用いて、要件情報ｎをエンコードすることにより、要件値ｎを作成する。そして、暗号化部６０２は、鍵ｈを（１／ｎ）乗することにより、暗号化データｎ’を生成する。暗号化データｎ’は、「ｎ’＝ｈ^1/n」である。

ここで、ｍ→ｇ^mという変換と、ｎ→ｈ^1/nという変換による暗号化について説明する。このｍ→ｇ^mは、数字にエンコードされた平文ｍを暗号化する際、有限巡回群Ｇと、その生成元ｇを固定し、ｍをｍ’＝ｇ^mと変換することを意味する。変換例としては、（大きな）素数ｐ、整数ｇ∈｛１，．．．，ｐ－１｝を固定し、メッセージをｍ∈｛０，．．．，ｐ－１｝とエンコードした上で、ｍをｍ’＝ｇ^m（ｍｏｄ ｐ）と変換する方法が挙げられる。

この変換が暗号化となる理由として、平文ｍをｍ’＝ｇ^mと変換したとき、情報「ｇとｍ’」から「ｍ」を効率的に計算するのが困難であることがよく知られているため、ｇとｍ’を公開しても元々の平文ｍを導くことは困難であることが挙げられる。また、この変換は、暗号化の性質を満たしつつ、従来のＲｅｌａｔｉｏｎａｌ Ｈａｓｈによるハッシュ化と比較して単純化されている。この単純化が作用して、後述する電子署名σのＺＫＰの生成を可能にしている。

証明生成部６０３は、マッチング対象となるデータに電子署名σが付与されている場合、証明情報を生成する。ここで、電子署名σは、署名者の公開鍵ｐｋによってデータの真正性を検証可能な情報である。電子署名σは、信頼できる第三者によって発行される。例えば、属性情報ｍが「卒業大学名」を示す場合、電子署名σは、その卒業大学によって発行される。

電子署名σは、例えば、属性情報ｍに付与される。以下の説明では、属性情報ｍに電子署名σが付与されている場合を想定する。

証明情報は、電子署名σが暗号化データｍ’の元データ（元の平文である属性情報ｍ）の真正性を検証可能な情報であることを証明するための情報である。具体的には、例えば、証明情報は、電子署名σが署名者の公開鍵ｐｋを用いて暗号化データｍ’の元データの真正性を検証可能な情報であることを証明するためのゼロ知識証明文Πを含む。

ゼロ知識証明文Πは、属性値ｍをｍ’に暗号化した際、第三者の公開鍵ｐｋで検証できる電子署名σが元々の属性値ｍ（属性情報ｍ）に与えられているとき、「σはｐｋで検証できるｍ’の元の平文の署名である」ことを示す。より詳細に説明すると、ゼロ知識証明文Πは、「ｍ’＝ｇ＾ｍ、かつ、σはｍに対する公開鍵ｐｋで検証できる署名であるようなｍ」の知識をゼロ知識証明するための情報である。

ゼロ知識証明文Πは、属性情報ｍを公開せず、ｍ’＝ｇ＾ｍ，σ，ｐｋを公開して、「ｍ’＝ｇ＾ｍ、かつ、σはｍに対する公開鍵ｐｋで検証できるｍの署名である」ことを証明可能にする。なお、ゼロ知識証明文Πの生成方法は、例えば、署名形式に依存して変わりうる。

以下の説明では、ゼロ知識証明文Πを「電子署名σのＺＫＰ（Ｚｅｒｏ－Ｋｎｏｗｌｅｄｇｅ Ｐｒｏｏｆ）」と表記する場合がある。

通信部６０４は、暗号化データを含むマッチング依頼をマッチング装置２０１に送信する。ここで、マッチング依頼は、暗号化データを用いたマッチングを依頼するものである。暗号化データは、マッチング対象となるデータを暗号化したものである。

例えば、マッチング対象となるデータを「属性情報ｍ」とし、属性情報ｍに電子署名σが付与されているとする。この場合、通信部６０４は、暗号化データｍ’、公開鍵ｐｋ、電子署名σおよびゼロ知識証明文Π（電子署名σのＺＫＰ）を含むマッチング依頼をマッチング装置２０１に送信する。ただし、公開鍵ｐｋは、例えば、マッチング装置２０１が電子署名σの署名者から取得することにしてもよい。

また、マッチング対象となるデータを「要件情報ｎ」とする。この場合、通信部６０４は、暗号化データｎ’を含むマッチング依頼をマッチング装置２０１に送信する。

また、通信部６０４は、マッチング結果をマッチング装置２０１から受信することにしてもよい。マッチング結果は、マッチング依頼に対する応答である。マッチング結果は、例えば、マッチング成功またはマッチング失敗を示す情報であってもよい。また、マッチング成功の場合、マッチング結果には、マッチング相手を特定する情報が含まれていてもよい。

つぎに、図７を用いて、マッチング装置２０１の機能的構成例について説明する。

図７は、マッチング装置２０１の機能的構成例を示すブロック図である。図７において、マッチング装置２０１は、受付部７０１と、検証部７０２と、取得部７０３と、照合部７０４と、出力部７０５と、を含む。受付部７０１～出力部７０５は制御部となる機能であり、具体的には、例えば、図３に示したマッチング装置２０１のメモリ３０２、ディスク３０４、可搬型記録媒体３０７などの記憶装置に記憶されたプログラムをＣＰＵ３０１に実行させることにより、または、通信Ｉ／Ｆ３０５により、その機能を実現する。各機能部の処理結果は、例えば、マッチング装置２０１のメモリ３０２、ディスク３０４などの記憶装置に記憶される。

以下の説明では、属性情報ｍを提供するユーザ（属性情報提供者）が使用するクライアント端末を「クライアント端末Ｃｉ」と表記する場合がある。また、要件情報ｎを提供するユーザ（要件情報提供者）が使用するクライアント端末を「クライアント端末Ｃｊ」と表記する場合がある（ｊ≠ｉ、ｊ＝１，２，…，ｎ）。

受付部７０１は、クライアント端末Ｃｉから第１マッチング依頼を受け付ける。具体的には、例えば、受付部７０１は、クライアント端末Ｃｉから第１マッチング依頼を受信することにより、受信した第１マッチング依頼を受け付ける。ここで、第１マッチング依頼は、例えば、暗号化データｍ’、公開鍵ｐｋ、電子署名σおよびゼロ知識証明文Π（電子署名σのＺＫＰ）を含む。

暗号化データｍ’は、マッチング対象となる属性情報ｍ（第１データ）を、ユーザ（属性情報提供者）の鍵ｇ（第１鍵）を用いた指数化により暗号化した情報であり、「ｍ’＝ｇ^m」である。公開鍵ｐｋは、電子署名σの署名者の公開鍵である。なお、公開鍵ｐｋは、マッチング装置２０１が電子署名σの署名者から直接取得することにしてもよい。

電子署名σは、属性情報ｍに付与された署名であって、公開鍵ｐｋを用いて属性情報ｍの真正性を検証可能な情報である。ゼロ知識証明文Πは、電子署名σのＺＫＰであり、電子署名σが暗号化データｍ’の元データ（元の平文である属性情報ｍ）の真正性を検証可能な情報であることを証明するための証明情報である。

また、受付部７０１は、クライアント端末Ｃｊから第２マッチング依頼を受け付ける。具体的には、例えば、受付部７０１は、クライアント端末Ｃｊから第２マッチング依頼を受信することにより、受信した第２マッチング依頼を受け付ける。

ここで、第２マッチング依頼は、例えば、暗号化データｎ’を含む。暗号化データｎ’は、マッチング対象となる要件情報ｎ（第２データ）を、ユーザ（要件情報提供者）の鍵ｈ（第２鍵）を用いた指数化により暗号化した情報であり、「ｎ’＝ｈ^1/n」である。

検証部７０２は、第１マッチング依頼に電子署名σが含まれる場合、第１マッチング依頼に含まれる証明情報を用いて、電子署名σの正当性を検証する。具体的には、例えば、検証部７０２は、公開鍵ｐｋと電子署名σと暗号化データｍ’とを用いて、ゼロ知識証明文Π（電子署名σのＺＫＰ）を証明することによって、電子署名σの正当性を検証する。

ゼロ知識証明文Πを用いて電子署名σの正当性が検証された場合、暗号化データｍ’の真正性が担保され、ひいては、暗号化データｍ’の元データ（属性情報ｍ）の真正性が担保されたといえる。なお、ｐｋ、σ、ｍ’を用いたゼロ知識証明文Πの証明方法は、署名形式に依存して変わりうる。

取得部７０３は、所定の関数を用いて鍵ｇ（第１鍵）および鍵ｈ（第２鍵）から演算された第１演算結果を鍵管理サーバ２０２から取得する。ここで、所定の関数は、例えば、双準同型性のある演算を行うペアリング関数（ペアリングｅ）である。

具体的には、例えば、取得部７０３は、第１マッチング依頼および第２マッチング依頼を受け付けた場合、ペアリング演算要求を鍵管理サーバ２０２に送信する。ペアリング演算要求には、ユーザ（属性情報提供者）のＩＤと、ユーザ（要件情報提供者）のＩＤとが含まれる。

そして、取得部７０３は、鍵管理サーバ２０２からペアリングｅおよび演算結果ｅ（ｇ，ｈ）を受信することにより、演算結果ｅ（ｇ，ｈ）を取得する。演算結果ｅ（ｇ，ｈ）は、ペアリングｅに鍵ｇ，ｈを入力して得られるペアリングｅの演算結果（第１演算結果）である。鍵ｇは、ユーザ（属性情報提供者）のＩＤに対応する鍵である。鍵ｈは、ユーザ（要件情報提供者）のＩＤに対応する鍵である。ただし、ペアリングｅについては、取得部７０３が鍵管理サーバ２０２から予め取得しておいてもよい。

照合部７０４は、証明情報を用いて電子署名σの正当性が検証された場合、取得された第１演算結果と、所定の関数を用いて暗号化データｍ’および暗号化データｎ’から演算される第２演算結果とを照合する。所定の関数は、例えば、鍵管理サーバ２０２から提供されるペアリング関数（ペアリングｅ）である。

具体的には、例えば、照合部７０４は、ペアリングｅに暗号化データｍ’，ｎ’を入力することにより、演算結果ｅ（ｇ^m，ｈ^1/n）を計算する。演算結果ｅ（ｇ^m，ｈ^1/n）は、第２演算結果に相当する。そして、照合部７０４は、演算結果ｅ（ｇ，ｈ）と演算結果ｅ（ｇ^m，ｈ^1/n）とを照合する。

ここで、演算結果ｅ（ｇ，ｈ）と演算結果ｅ（ｇ^m，ｈ^1/n）とが一致する場合、属性情報ｍと要件情報ｎとが等しいといえる。この照合は、ペアリングｅの双準同型性を利用して、「ｍ→ｇ^m」により変換された元のメッセージの一致判定を、ペアリング写像で可能にすることにより実現する。具体的には、片方の変換を「ｍ→ｇ^m」とし、もう一方の変換を「ｎ→ｈ^1/n」とすることで、ペアリングｅの演算結果が「ｅ（ｇ^m，ｈ^1/n）＝ｅ（ｇ，ｈ）^m/n」となることを利用して、属性情報ｍと要件情報ｎとが等しいかどうかを確かめることができる。

出力部７０５は、照合された照合結果を出力する。出力部７０５の出力形式としては、例えば、マッチング装置２０１のメモリ３０２、ディスク３０４などの記憶装置への記憶、通信Ｉ／Ｆ３０５による他のコンピュータ（例えば、クライアント端末Ｃｉ，Ｃｊ）への送信、不図示のディスプレイへの表示、不図示のプリンタへの印刷出力などがある。

具体的には、例えば、出力部７０５は、照合結果が「一致」の場合、マッチング成功を示すマッチング結果をクライアント端末Ｃｉ，Ｃｊに送信することにしてもよい。このマッチング結果には、例えば、クライアント端末Ｃｉ，Ｃｊのユーザを特定する情報が含まれていてもよい。また、出力部７０５は、照合結果が「不一致」の場合、マッチング失敗を示すマッチング結果をクライアント端末Ｃｉ，Ｃｊに送信することにしてもよい。

また、出力部７０５は、電子署名σの正当性が検証されなかった場合、暗号化データｍ’の真正性の検証に失敗したことを示す検証結果を出力することにしてもよい。具体的には、例えば、出力部７０５は、暗号化データｍ’の真正性の検証に失敗したことを示す検証結果を含むマッチング結果をクライアント端末Ｃｉに送信する。この場合、出力部７０５は、マッチング失敗を示すマッチング結果をクライアント端末Ｃｊに送信することにしてもよい。

なお、取得部７０３は、証明情報を用いて電子署名σの正当性が検証された場合に、鍵管理サーバ２０２から第１演算結果を取得することにしてもよい。これにより、電子署名σの正当性が検証されず、第１演算結果と第２演算結果との照合が行われないにもかかわらず、鍵管理サーバ２０２から第１演算結果が取得されるのを防ぐことができる。

また、照合部７０４は、証明情報を用いた電子署名σの正当性の検証結果にかかわらず、第１演算結果と第２演算結果とを照合することにしてもよい。この場合、出力部７０５は、電子署名σの正当性の検証結果とともに、第１演算結果と第２演算結果との照合結果を出力することにしてもよい。

（マッチング装置２０１のマッチング処理例）
ここで、図８を用いて、マッチング装置２０１のマッチング処理例について説明する。

図８は、マッチング装置２０１のマッチング処理例を示す説明図である。図８において、事業者８０１は、マッチング事業者を表しており、マッチング装置２０１に対応する。求職者８０２は、属性情報ｍを提供するユーザ（属性情報提供者）を表しており、クライアント端末Ｃｉに対応する。企業８０３は、要件情報ｎを提供するユーザ（要件情報提供者）を表しており、クライアント端末Ｃｊに対応する。なお、図８では、電子署名σを「署名σ」と表記している。

事業者８０１（マッチング装置２０１）は、求職者８０２（クライアント端末Ｃｉ）からｇ^mとゼロ知識証明文Πとを受け付ける。ｇ^mは、求職者８０２の鍵ｇを用いて属性値ｍ（属性情報ｍ）を暗号化した暗号化データｍ’である。ゼロ知識証明文Πは、電子署名σのＺＫＰである。電子署名σは、属性値ｍ（属性情報ｍ）に対して有効である。ゼロ知識証明文Πは、ｇ^mに対して有効である。

また、事業者８０１（マッチング装置２０１）は、企業８０３（クライアント端末Ｃｊ）からｈ^1/nを受け付ける。ｈ^1/nは、企業８０３の鍵ｈを用いて要件値ｎ（要件情報ｎ）を暗号化した暗号化データｎ’である。要件情報ｎは、求人要件を表す。

事業者８０１（マッチング装置２０１）は、ゼロ知識証明文Πを用いて、電子署名σの正当性を検証する。ゼロ知識証明文Πを用いて電子署名σの正当性が検証された場合、ｇ^m（暗号化データｍ’）の真正性が担保され、ひいては、ｇ^mの元データ（属性値ｍ）の真正性が担保される。

なお、既存のＲｅｌａｔｉｏｎａｌ Ｈａｓｈに対して署名のＺＫＰを生成することも考えられる。しかしながら、ハッシュ関数が複雑であるため、従来知られているゼロ知識証明の生成技術をそのまま当てはめることはできない。より詳細に説明すると、Ｒｅｌａｔｉｏｎａｌ Ｈａｓｈで用いられるハッシュ関数を、入力に依らない算術回路で書き下すことが困難であるため、ゼロ知識証明を生成する際にＺＫ－ＳＮＡＲＫｓの既存のフレームワークを適用することができない。したがって、属性情報ｍを秘匿するにあたり、「ｍ→ｇ^m」といった形の指数化による暗号化を用いて、暗号化データを簡単化するアプローチが有効となる。

事業者８０１（マッチング装置２０１）は、ゼロ知識証明文Πを用いて電子署名σの正当性が検証された場合、鍵ｇ，ｈを用いることなく、ペアリングｅの双準同型性を利用してマッチングを行う。具体的には、例えば、事業者８０１（マッチング装置２０１）は、「ｅ（ｇ^m，ｈ^1/n）＝ｅ（ｇ，ｈ）^m/n」が「ｅ（ｇ，ｈ）」と一致するか否かを判定する。ｅ（ｇ，ｈ）は、鍵管理サーバ２０２から得られるペアリングｅの第１演算結果である。ｅ（ｇ^m，ｈ^1/n）は、ペアリングｅにｇ^m，ｈ^1/nを入力することにより得られる第２演算結果である。

これにより、事業者８０１（マッチング装置２０１）は、ペアリング写像という概念を応用して、属性値ｍ（属性情報ｍ）と要件値ｎ（要件情報ｎ）とが一致しているか否かを、属性情報ｍと要件情報ｎを復号することなく判定することができる。

（情報処理システム２００の動作例）
つぎに、図９を用いて、実施の形態１にかかる情報処理システム２００の動作例について説明する。ここでは、求人マッチングにおいて、求職者Ａと企業Ｂとのマッチングを事業者Ｃが行う場合を例に挙げて説明する。

図９は、実施の形態１にかかる情報処理システム２００の動作例を示す説明図である。図９において、事業者Ｃは、マッチング事業者を表しており、マッチング装置２０１に対応する。求職者Ａは、ユーザ（属性情報提供者）を表しており、クライアント端末Ｃｉに対応する。企業Ｂは、ユーザ（要件情報提供者）を表しており、クライアント端末Ｃｊに対応する。なお、図９では、電子署名σを「署名」と表記している。

まず、求職者Ａ（クライアント端末Ｃｉ）は、鍵ｇを生成して、鍵管理サーバ２０２に登録する。また、企業Ｂ（クライアント端末Ｃｊ）は、鍵ｈを生成して、鍵管理サーバ２０２に登録する。鍵ｇ，ｈは、鍵管理サーバ２０２以外には公開されない。鍵管理サーバ２０２は、ペアリング写像を準備する。

求職者Ａ（クライアント端末Ｃｉ）は、鍵ｇを用いて、属性情報ｍをｇ^mに変換して、事業者Ｃ（マッチング装置２０１）に送付する。ｇ^mは、属性情報ｍの暗号文とみなすことができる。ここでは、属性情報ｍを「学歴：Ｘ大卒（＝ｍ）」とし、属性情報ｍが「学歴：Ｆ３２Ｒ３（＝ｇ^m）」という暗号化データに変換された場合を想定する。

さらに、求職者Ａ（クライアント端末Ｃｉ）は、属性情報ｍに第三者（Ｘ大学）による電子署名σが付与されている場合、その電子署名σが暗号化データｇ^mの平文ｍに対して有効であることのゼロ知識証明文Πを生成して、事業者Ｃ（マッチング装置２０１）に送付する。これにより、求職者Ａ（クライアント端末Ｃｉ）は、事業者Ｃに提出した暗号化データｇ^mの真正性を保証する。

一方、企業Ｂ（クライアント端末Ｃｊ）は、鍵ｈを用いて、要件情報ｎをｈ^1/nに変換して、事業者Ｃ（マッチング装置２０１）に送付する。ｈ^1/nは、要件情報ｎの暗号文とみなすことができる。企業側では、求職者側と異なり、鍵ｈを用いた暗号化の際に、逆数のべきをとることで、後のペアリングによる一致判定を行いやすくすることができる。

ここでは、要件情報ｎを「要求学歴：Ｘ大卒、Ｙ大卒、…（＝ｎ１，ｎ２，…）」とし、要件情報ｎが「要求学歴：４ｎ４Ｇｇ，ａ３ＱＣｓ，…（＝ｈ^1/n1，ｈ^1/n2，…）」という暗号化データに変換された場合を想定する。

事業者Ｃ（マッチング装置２０１）は、求職者Ａ（クライアント端末Ｃｉ）から、暗号化データｇ^m、ゼロ知識証明文Πを受け付ける。また、事業者Ｃ（マッチング装置２０１）は、企業Ｂ（クライアント端末Ｃｊ）から、暗号化データｈ^1/nを受け付ける。これにより、求職者Ａから属性情報ｍの暗号化データｇ^m、属性情報ｍに付与された電子署名σの正当性に関するゼロ知識証明文Πが事業者Ｃに与えられる。また、企業Ｂから要件情報ｎの暗号化データｈ^1/nが事業者Ｃに与えられる。

事業者Ｃ（マッチング装置２０１）は、鍵管理サーバ２０２から、求職者Ａや企業Ｂの鍵ｇ，ｈではなく、ペアリング演算に関する種々の情報（ペアリングｅ，演算結果ｅ_AB＝（ｇ，ｈ））を受け取る。そして、事業者Ｃ（マッチング装置２０１）は、ゼロ知識証明文Πを用いて電子署名σの正当性が検証された場合、暗号化データｇ^m，ｈ^1/nから平文を復号することなく、ペアリングｅの双準同型性を利用してマッチングを行う。

ここでは、事業者Ｃ（マッチング装置２０１）は、ｅ_ABが、ｅ（”Ｆ３２Ｒ３”，”４ｎ４Ｇｇ”），ｅ（”Ｆ３２Ｒ３”，”ａ３ＱＣｓ”），…と一致するかを判定していき、等号が成立すれば要件にマッチ（マッチング成功）したと判断する。

なお、ｅ（”Ｆ３２Ｒ３”，”４ｎ４Ｇｇ”）は、ペアリングｅに「Ｆ３２Ｒ３（＝ｇ^m）」と「４ｎ４Ｇｇ（＝ｈ^1/n1）」を入力することにより得られる演算結果である。また、ｅ（”Ｆ３２Ｒ３”，”ａ３ＱＣｓ”）は、ペアリングｅに「Ｆ３２Ｒ３（＝ｇ^m）」と「ａ３ＱＣｓ（＝ｈ^1/n2）」を入力することにより得られる演算結果である。

このように、情報処理システム２００によれば、マッチング対象のデータ（ｍ，ｎ）を暗号化し、その暗号文を復号することなく、元データが等しいかどうかを判定することで、プライバシーを保護したマッチングを行うことができる。また、情報処理システム２００によれば、ゼロ知識証明文Πの検証を行うことで、暗号文から平文を復号することなく、求職者Ａの提出した属性情報ｍの真正性を検証することができる。なお、要件情報ｎは、企業Ｂの属性への興味を示すものであり、真正性を担保しなくてもよい。このため、要件情報ｎには、署名が付与されていない。

（情報処理システム２００の各種処理手順）
つぎに、図１０～図１７を用いて、情報処理システム２００の各種処理手順について説明する。

・鍵管理サーバ２０２のセットアップ処理手順
まず、鍵管理サーバ２０２のセットアップ処理手順について説明する。

図１０は、鍵管理サーバ２０２のセットアップ処理手順の一例を示すフローチャートである。図１０のフローチャートにおいて、まず、鍵管理サーバ２０２は、ドメインの集合Ｕを設定する（ステップＳ１００１）。つぎに、鍵管理サーバ２０２は、素数ｐを設定する（ステップＳ１００２）。

そして、鍵管理サーバ２０２は、ドメインの集合Ｕの要素をキー、集合［ｐ］＝｛０，…，ｐ－１｝の要素をバリューとするＴＡＢＬＥを作成する（ステップＳ１００３）。つぎに、鍵管理サーバ２０２は、素数位数ｑの群Ｇと、素数位数ｐ（ｑ＞ｐ）の群Ｈを設定する（ステップＳ１００４）。

つぎに、鍵管理サーバ２０２は、ペアリングｅ「ｅ：Ｇ×Ｇ→Ｈ」を設定する（ステップＳ１００５）。そして、鍵管理サーバ２０２は、ドメインの集合Ｕと、ＴＡＢＬＥと、素数位数ｑの群Ｇとを情報処理システム２００全体に公開して（ステップＳ１００６）、本フローチャートによる一連の処理を終了する。

これにより、鍵管理サーバ２０２は、鍵生成に関する情報とペアリング演算に関する情報とを用意することができる。

・クライアント端末Ｃｉの鍵生成／アップデート処理手順
つぎに、クライアント端末Ｃｉの鍵生成／アップデート処理手順について説明する。

図１１は、クライアント端末Ｃｉの鍵生成／アップデート処理手順の一例を示すフローチャートである。図１１のフローチャートにおいて、まず、クライアント端末Ｃｉは、鍵管理サーバ２０２によって公開された素数位数ｑの群Ｇの元を一つ選択することによって、鍵を生成する（ステップＳ１１０１）。

そして、クライアント端末Ｃｉは、自端末に対応するＩＤと、生成した鍵とを含む鍵登録要求を鍵管理サーバ２０２に送信して（ステップＳ１１０２）、本フローチャートによる一連の処理を終了する。

これにより、クライアント端末Ｃｉは、自端末のユーザの鍵を生成して、鍵管理サーバ２０２にアップロード（登録）することができる。

・鍵管理サーバ２０２の鍵登録処理手順
つぎに、鍵管理サーバ２０２の鍵登録処理手順について説明する。

図１２は、鍵管理サーバ２０２の鍵登録処理手順の一例を示すフローチャートである。図１２のフローチャートにおいて、まず、鍵管理サーバ２０２は、クライアント端末Ｃｉから鍵登録要求を受信したか否かを判断する（ステップＳ１２０１）。ここで、鍵管理サーバ２０２は、クライアント端末Ｃｉから鍵登録要求を受信するのを待つ（ステップＳ１２０１：Ｎｏ）。

そして、鍵管理サーバ２０２は、クライアント端末Ｃｉから鍵登録要求を受信した場合（ステップＳ１２０１：Ｙｅｓ）、鍵登録要求に含まれるＩＤと対応付けて、鍵登録要求に含まれる鍵を鍵保管ＤＢ２２０に登録して（ステップＳ１２０２）、本フローチャートによる一連の処理を終了する。

これにより、鍵管理サーバ２０２は、クライアント端末Ｃｉにおいて生成された各ユーザの鍵を、鍵保管ＤＢ２２０に登録して管理することができる。なお、ステップＳ１２０２において、鍵登録要求に含まれるＩＤに対応する鍵が登録済みの場合、鍵管理サーバ２０２は、鍵登録要求に含まれる鍵で上書きする。

つぎに、情報処理システム２００のマッチング処理手順について説明する。ただし、ユーザ（属性情報提供者）のクライアント端末を「クライアント端末Ｃｉ」とし、ユーザ（要件情報提供者）のクライアント端末を「クライアント端末Ｃｊ」とする。

図１３および図１４は、情報処理システム２００のマッチング処理手順を示すシーケンス図である。図１３のシーケンス図において、まず、クライアント端末Ｃｉは、鍵管理サーバ２０２によって公開されたＴＡＢＬＥを用いて、属性情報ｍをエンコードすることにより、属性値ｍに変換する（ステップＳ１３０１）。

そして、クライアント端末Ｃｉは、鍵ｇを用いて、属性値ｍをｇ^mと暗号化することにより、暗号化データｍ’（ｍ’＝ｇ^m）を生成する（ステップＳ１３０２）。つぎに、クライアント端末Ｃｉは、証明生成処理を実行する（ステップＳ１３０３）。なお、証明生成処理の具体的な処理手順については、図１５を用いて後述する。

ここでは、属性情報ｍ（属性値ｍ）に付与されている電子署名σのゼロ知識証明文Πが生成された場合を想定する。そして、クライアント端末Ｃｉは、暗号化データｍ’、公開鍵ｐｋ、電子署名σおよびゼロ知識証明文Πを含むマッチング依頼をマッチング装置２０１に送信する（ステップＳ１３０４）。

マッチング装置２０１は、クライアント端末Ｃｉからマッチング依頼を受信すると（ステップＳ１３０５）、マッチング依頼に含まれるゼロ知識証明文Πについての証明検証処理を実行する（ステップＳ１３０６）。なお、証明検証処理の具体的な処理手順については、図１６を用いて後述する。

クライアント端末Ｃｊは、鍵管理サーバ２０２によって公開されたＴＡＢＬＥを用いて、要件情報ｎをエンコードすることにより、要件値ｎに変換する（ステップＳ１３０７）。つぎに、クライアント端末Ｃｊは、鍵ｈを用いて、要件値ｎをｈ^1/nと暗号化することにより、暗号化データｎ’（ｎ’＝ｈ^1/n）を生成する（ステップＳ１３０８）。

そして、クライアント端末Ｃｊは、暗号化データｎ’を含むマッチング依頼をマッチング装置２０１に送信する（ステップＳ１３０９）。なお、ステップＳ１３０７～Ｓ１３０９の処理は、ステップＳ１３０１～Ｓ１３０４の処理よりも前に実行されてもよく、また、ステップＳ１３０１～Ｓ１３０４の処理と並列に実行されてもよい。

図１４のシーケンス図において、まず、マッチング装置２０１は、クライアント端末Ｃｊからマッチング依頼を受信すると（ステップＳ１４０１）、ペアリング演算要求を鍵管理サーバ２０２に送信する（ステップＳ１４０２）。ペアリング演算要求には、クライアント端末Ｃｉのユーザ（属性情報提供者）のＩＤと、クライアント端末Ｃｊのユーザ（要件情報提供者）のＩＤとが含まれる。

鍵管理サーバ２０２は、マッチング装置２０１からペアリング演算要求を受信すると、ペアリング演算要求に含まれる各ＩＤに対応する鍵ｇ，ｈを、鍵保管ＤＢ２２０から取得する（ステップＳ１４０３）。つぎに、鍵管理サーバ２０２は、取得した鍵ｇ，ｈをペアリングｅに入力することにより、ペアリングｅの演算結果ｅ（ｇ，ｈ）を算出する（ステップＳ１４０４）。

そして、鍵管理サーバ２０２は、ペアリングｅおよびペアリングｅの演算結果ｅ（ｇ，ｈ）をマッチング装置２０１に送信する（ステップＳ１４０５）。マッチング装置２０１は、ペアリングｅおよびペアリングｅの演算結果ｅ（ｇ，ｈ）を受信すると、照合処理を実行する（ステップＳ１４０６）。なお、照合処理の具体的な処理手順については、図１７を用いて後述する。

そして、マッチング装置２０１は、照合結果に応じたマッチング結果をクライアント端末Ｃｉ，Ｃｊに送信して（ステップＳ１４０７）、本シーケンス図による一連の処理を終了する。

つぎに、図１５を用いて、図１３に示したステップＳ１３０３のクライアント端末Ｃｉの証明生成処理の具体的な処理手順について説明する。

図１５は、クライアント端末Ｃｉの証明生成処理の具体的処理手順の一例を示すフローチャートである。図１５のフローチャートにおいて、まず、クライアント端末Ｃｉは、属性情報ｍに電子署名σが付与されているか否かを判断する（ステップＳ１５０１）。

ここで、属性情報ｍに電子署名σが付与されていない場合（ステップＳ１５０１：Ｎｏ）、クライアント端末Ｃｉは、証明生成処理を呼び出したステップに戻る。一方、属性情報ｍに電子署名σが付与されている場合（ステップＳ１５０１：Ｙｅｓ）、クライアント端末Ｃｉは、電子署名σのゼロ知識証明文Πを生成して（ステップＳ１５０２）、証明生成処理を呼び出したステップに戻る。

これにより、クライアント端末Ｃｉは、電子署名σが署名者の公開鍵ｐｋを用いて暗号化データｍ’の元データの真正性を検証可能な情報であることを証明するための証明情報を生成することができる。

つぎに、図１６を用いて、図１３に示したステップＳ１３０６のマッチング装置２０１の証明検証処理の具体的な処理手順について説明する。

図１６は、マッチング装置２０１の証明検証処理の具体的処理手順の一例を示すフローチャートである。図１６のフローチャートにおいて、まず、マッチング装置２０１は、公開鍵ｐｋと電子署名σと暗号化データｍ’とを用いて、ゼロ知識証明文Π（電子署名σのＺＫＰ）を証明することによって、電子署名σの正当性を検証する（ステップＳ１６０１）。

そして、マッチング装置２０１は、電子署名σの正当性の検証に成功したか否かを判断する（ステップＳ１６０２）。ここで、電子署名σの正当性の検証に成功した場合（ステップＳ１６０２：Ｙｅｓ）、マッチング装置２０１は、証明検証処理を呼び出したステップに戻る。

一方、電子署名σの正当性の検証に失敗した場合（ステップＳ１６０２：Ｎｏ）、マッチング装置２０１は、暗号化データｍ’の真正性の検証に失敗したことを示す検証結果をクライアント端末Ｃｉに送信して（ステップＳ１６０３）、本フローチャートによる一連の処理を終了する。

これにより、マッチング装置２０１は、ゼロ知識証明文Πを用いて電子署名σの正当性を検証することで、ｇ^m（暗号化データｍ’）の真正性を担保し、ひいては、ｇ^mの元データ（属性情報ｍ）の真正性を担保することができる。

つぎに、図１７を用いて、図１４に示したステップＳ１４０６のマッチング装置２０１の照合処理の具体的な処理手順について説明する。

図１７は、マッチング装置２０１の照合処理の具体的処理手順の一例を示すフローチャートである。図１７のフローチャートにおいて、まず、マッチング装置２０１は、鍵管理サーバ２０２からペアリングｅおよびペアリングｅの演算結果ｅ（ｇ，ｈ）を受信すると（ステップＳ１７０１）、ペアリングｅを用いて、暗号化データｍ’，ｎ’から演算結果ｅ（ｇ^m，ｈ^1/n）を算出する（ステップＳ１７０２）。

つぎに、マッチング装置２０１は、ペアリングｅの双準同型性を利用して、鍵管理サーバ２０２から受信した演算結果ｅ（ｇ，ｈ）と、算出した演算結果ｅ（ｇ^m，ｈ^1/n）とが一致するか否かを判定する（ステップＳ１７０３）。

ここで、演算結果ｅ（ｇ，ｈ）と演算結果ｅ（ｇ^m，ｈ^1/n）とが一致する場合（ステップＳ１７０３：Ｙｅｓ）、マッチング装置２０１は、マッチング成功と判断して（ステップＳ１７０４）、照合処理を呼び出したステップに戻る。

一方、演算結果ｅ（ｇ，ｈ）と演算結果ｅ（ｇ^m，ｈ^1/n）とが一致しない場合（ステップＳ１７０３：Ｎｏ）、マッチング装置２０１は、マッチング失敗と判断して（ステップＳ１７０５）、照合処理を呼び出したステップに戻る。

これにより、マッチング装置２０１は、ペアリングｅの双準同型性を利用して、属性情報ｍと要件情報ｎとが等しいかどうかを確かめることができる。

以上説明したように、実施の形態１にかかるマッチング装置２０１によれば、鍵ｇ（第１鍵）を用いた指数化により属性情報ｍ（第１データ）を暗号化した暗号化データｍ’（第１暗号化データ）と、属性情報ｍに付与された電子署名σと、証明情報とを受け付けることができる。証明情報は、電子署名σが暗号化データｍ’の元データ（元々の平文）の真正性を検証可能な情報であることを証明するための情報である。そして、マッチング装置２０１によれば、証明情報を用いて電子署名σの正当性を検証することができる。また、マッチング装置２０１によれば、鍵ｈ（第２鍵）を用いた指数化により要件情報ｎ（第２データ）を暗号化した暗号化データｎ’（第２暗号化データ）を受け付けることができる。また、マッチング装置２０１によれば、鍵管理サーバ２０２から、ペアリングｅを用いて鍵ｇおよび鍵ｈから演算された演算結果ｅ（ｇ，ｈ）を取得することができる。ペアリングｅは、双準同型性のある演算を行うペアリング関数である。そして、マッチング装置２０１によれば、取得した演算結果ｅ（ｇ，ｈ）と、ペアリングｅを用いて暗号化データｍ’および暗号化データｎ’から演算される演算結果（ｇ^m，ｈ^1/n）とを照合することができる。

これにより、マッチング装置２０１は、マッチング対象となるユーザ（属性情報提供者、要件情報提供者）についてのデータの内容を第三者（マッチング事業者）に秘匿しつつ、データの真正性を担保することができる。例えば、属性情報ｍの秘匿に「ｍ→ｇ^m」といった形の指数化による暗号化を用いることで、暗号化データｍ’を簡単化して証明情報を生成することが可能になり、署名された属性情報ｍの真正性を担保することができる。また、指数化による暗号化とペアリングｅの双準同型性を用いることで、各ユーザについての属性情報ｍ、要件情報ｎの内容を第三者に秘匿しつつ、ユーザ同士のマッチングを行うことができる。例えば、求人マッチングにおいて、求職者（個人）の属性（年齢、学歴など）と、企業（法人）の属性への興味（年齢、学歴など）とを照合して、求職者と企業とのマッチングを行うことができる。

また、マッチング装置２０１によれば、電子署名σの正当性が検証された場合に、演算結果ｅ（ｇ，ｈ）と演算結果（ｇ^m，ｈ^1/n）とを照合することができる。

これにより、マッチング装置２０１は、属性情報ｍの真正性が担保された場合に、演算結果ｅ（ｇ，ｈ）と演算結果（ｇ^m，ｈ^1/n）とを照合して、ユーザ同士のマッチングを行うことができる。

また、マッチング装置２０１によれば、電子署名σが署名者の公開鍵ｐｋを用いて暗号化データｍ’の元データの真正性を検証可能な情報であることを証明するためのゼロ知識証明文Π（電子署名σのＺＫＰ）を、証明情報として受け付けることができる。そして、マッチング装置２０１によれば、公開鍵ｐｋと電子署名σと暗号化データｍ’とを用いて、ゼロ知識証明文Πを証明することによって、電子署名σの正当性を検証することができる。

これにより、マッチング装置２０１は、ゼロ知識証明を利用して、電子署名σの正当性を検証することで、暗号化データｍ’の真正性を担保し、ひいては、元の平文である属性情報ｍの真正性を担保することができる。例えば、暗号文（暗号化データｍ’）に対しても有効なゼロ知識証明であって、元々検証する際に使用される公開鍵ｐｋで検証可能なものを用意できれば、マッチング事業者は、その暗号文も第三者が認可したものであることを確認することができる。

また、マッチング装置２０１によれば、照合した照合結果を出力することができる。

これにより、マッチング装置２０１は、マッチング対象となるユーザ（属性情報提供者、要件情報提供者）やマッチング事業者に対して、マッチングの成否を通知することができる。

また、マッチング装置２０１によれば、証明情報（ゼロ知識証明文Π）を用いて電子署名σの正当性が検証された場合に、鍵管理サーバ２０２から演算結果ｅ（ｇ，ｈ）を取得することができる。

これにより、マッチング装置２０１は、例えば、電子署名σの正当性が検証されず、演算結果の照合が行われないときには、鍵管理サーバ２０２から演算結果ｅ（ｇ，ｈ）を取得する処理を行わずに処理負荷を抑えることができる。

また、マッチング装置２０１によれば、証明情報（ゼロ知識証明文Π）を用いて電子署名σの正当性が検証されなかった場合、暗号化データｍ’の真正性の検証に失敗したことを示す検証結果を出力することができる。

これにより、マッチング装置２０１は、暗号化データｍ’の元の平文である属性情報ｍの真正性を担保できないためマッチングができないことを、マッチング対象となるユーザ（属性情報提供者、要件情報提供者）やマッチング事業者に通知することができる。

（実施例）
つぎに、実施の形態１にかかる情報処理システム２００を、複数の求職者と複数の企業とのマッチングを行う求人マッチングに適用した場合の実施例について説明する。

図１８は、情報処理システム２００の実施例を示す説明図である。図１８において、複数の求職者がＡ₁，Ａ₂，…，Ａ_n存在し、複数の企業がＢ₁，Ｂ₂，…，Ｂ_m存在する場合を想定する。また、Ａ₁，Ａ₂，…，Ａ_n，Ｂ₁，Ｂ₂，…，Ｂ_mは、ユーザのＩＤを表すものとする。

まず、鍵管理サーバ２０２は、セットアップ処理を実行する（例えば、図１０参照）。セットアップ時に用意されるペアリングｅ：Ｇ×Ｇ→Ｈは、非自明である。Ｇは素数位数ｑの群、かつ、Ｈは位数ｐとする。ペアリングｅ：Ｇ×Ｇ→Ｈとは、「ｅ（ｇ₁＊ｇ₂，ｈ）＝ｅ（ｇ₁，ｈ）＊ｅ（ｇ₂，ｈ）」および「ｅ（ｇ，ｈ₁＊ｈ₂）＝ｅ（ｇ，ｈ₁）＊ｅ（ｇ，ｈ₂）」の条件を満たす写像である。

つぎに、各求職者Ａ_i（クライアント端末Ｃｉ）は、鍵生成／アップデート処理を実行する（例えば、図１１参照）。また、各企業Ｂ_j（クライアント端末Ｃｊ）は、鍵生成／アップデート処理を実行する（例えば、図１１参照）。これにより、各求職者Ａ_iの鍵ｇ_iが生成され、鍵管理サーバ２０２に送信される。また、各企業Ｂ_jの鍵ｈ_jが生成され、鍵管理サーバ２０２に送信される。

ここで、各求職者Ａ_iは、複数の属性値Ｘ_iを有しており、各企業Ｂ_jは、複数の属性への興味、すなわち、複数の要件値Ｙ_jを有しているとする。ただし、属性値Ｘ_i，要件値Ｙ_jは、ＴＡＢＬＥによりエンコードされた値とする。また、各企業Ｂ_jは、求職者が満たして欲しい要件数として、閾値ｓ_jを事業者Ｃ（マッチング装置２０１）に送信するとする。

以下、求職者Ａ_iと企業Ｂ_jとのマッチングを行う場合の動作例について説明する。

まず、求職者Ａ_i（クライアント端末Ｃｉ）は、鍵ｇ_iを用いて、ＥＸ_i：＝Ｅｘｐ（ｇ_i，Ｘ_i）：＝｛ｇ_i ^m|ｍ∈Ｘ_i｝と属性値を暗号化し、事業者Ｃ（マッチング装置２０１）に送信する。また、企業Ｂ_j（クライアント端末Ｃｊ）は、ＦＹ_j：＝Ｅｘｐ^-1（ｈ_j，Ｙ_j）：＝｛ｈ_j＾（ｄ_n）|ｎ∈Ｙ_j｝と属性値を暗号化し、閾値ｓ_jとともに事業者Ｃ（マッチング装置２０１）に送信する。ただし、ｄ_n＝ｎ^(p-2)≡１／ｎ（ｍｏｄ ｐ）である。

さらに、鍵管理サーバ２０２は、事業者Ｃ（マッチング装置２０１）からのペアリング演算要求に応じて、ε_ij＝ｅ（ｇ_i，ｈ_j）を事業者Ｃ（マッチング装置２０１）に送信する。そして、事業者Ｃ（マッチング装置２０１）は、Ｉ（ε_ij，ＥＸ_i，ＦＹ_j）：＝＃｛（ａ，ｂ）∈ＥＸ_i×ＦＹ_j|ｅ（ａ，ｂ）＝ｅ（ｇ，ｈ）｝を計算する。

ここで、ｘ，ｙ∈｛０，…，ｐ－１｝に対し、ｄ_y＝ｙ^(p-2)≡１／ｙとしたとき、ｅ（ｇ^x，ｈ＾（ｄ_y））＝ｅ（ｇ，ｈ）とｘ＝ｙは同値である。その証明を行うと、ｅ：Ｇ×Ｇ→Ｈの双準同型性から、ｅ（ｇ^x，ｈ＾（ｄ_y））＝ｅ（ｇ，ｈ）＾（ｘｄ_y）である。Ｈの位数はｐであるから、ｅ（ｇ，ｈ）＾（ｘｄ_y）＝ｅ（ｇ，ｈ）とｘｄ_y≡１（ｍｏｄ ｐ）は同値であり、さらに、ｘｄ_y≡１（ｍｏｄ ｐ）とｘ＝ｙは同値である。これで証明が終わる。

これにより、Ｉ（ε_ij，ＥＸ_i，ＦＹ_j）は、求職者Ａ_iの提出した属性値Ｘ_iと、企業Ｂ_jの提出した要件値Ｙ_jとの一致数であるといえる。ここでは、この値が、閾値ｓ_j以上である場合、ｃ_ij＝１とし、閾値ｓ_j未満の場合ｃ_ij＝０とする。ｃ_ij＝１の場合、企業Ｂ_jの要件を求職者Ａ_iが満たすこと（マッチング成功）を意味する。

例えば、事業者Ｃ（マッチング装置２０１）は、ｃ_ij＝１の場合、求職者Ａ_i（クライアント端末Ｃｉ）に企業Ｂ_j（クライアント端末Ｃｊ）のことを、企業Ｂ_j（クライアント端末Ｃｊ）に求職者Ａ_i（クライアント端末Ｃｉ）のことを通知する。これにより、求職者Ａ_iと企業Ｂ_jとがマッチングされる。なお、ペアリングの逆像計算は困難なため、事業者Ｃが求職者Ａ_iの属性値Ｘ_iを特定することは難しいといえる。

また、各求職者Ａ_iに希望条件Ｚ_iとその条件を満たして欲しい数ｔ_iがあり、各企業Ｂ_jに情報Ｗ_jが存在するとする。この場合、Ａ_iとＢ_jの役割を入れ替え、Ｘ_iをＷ_j、Ｙ_jをＺ_i、ｓ_jをｔ_iに変更して、情報処理システム２００のマッチング処理を実行してもよい。求職者Ａ_iの希望する条件と企業Ｂ_jの提出した企業情報の一致数が、閾値ｔ_j以上である場合、ｄ_ij＝１とし、閾値ｔ_j未満の場合ｄ_ij＝０とする。ｄ_ij＝１の場合、求職者Ａ_iの希望条件を企業Ｂ_jが満たすことを意味する。ｃ_ij＊ｄ_ij＝１であれば、求職者Ａ_iと企業Ｂ_jは互いの要求を満たしたことを意味するため、事業者Ｃ（マッチング装置２０１）は、マッチング成功としてもよい。

また、求職者Ａ_i（クライアント端末Ｃｉ）は、求職者Ａ_iに属する属性値ｍに電子署名σが付与されている場合、電子署名σのＺＫＰを生成してもよい。ここでは、ＣＬ署名が付与されているケースを想定する。電子署名σのＺＫＰについては、例えば、下記非特許文献２を参照して生成することができる。

非特許文献２：Ｃａｍｅｎｉｓｃｈ， Ｊａｎ， ａｎｄ Ａｎｎａ Ｌｙｓｙａｎｓｋａｙａ． “Ａ ｓｉｇｎａｔｕｒｅ ｓｃｈｅｍｅ ｗｉｔｈ ｅｆｆｉｃｉｅｎｔ ｐｒｏｔｏｃｏｌｓ．” Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｓｅｃｕｒｉｔｙ ｉｎ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｎｅｔｗｏｒｋｓ． Ｓｐｒｉｎｇｅｒ， Ｂｅｒｌｉｎ ， Ｈｅｉｄｅｌｂｅｒｇ， ２００２．

まず、ＣＬ署名は、秘密鍵をｐ、公開鍵を（ｎ，ａ，ｂ，ｃ）とする。ここで、ｎ＝ｐｑはＲＳＡモジュラス、すなわち、同じビット数の素数ｐ，ｑとする。また、ａ，ｂ，ｃは、ｎを法とする平方剰余、すなわち、あるｘ，ｙ，ｚが存在してｘ²＝ａ，ｙ²＝ｂ，ｚ²＝ｃ（ｍｏｄ ｎ）を満たすものが存在するものとする。

さらに、平文ｍに対する電子署名σはσ＝（ｓ，ｅ，ｖ）である。ここで（ｓ，ｅ，ｖ）は、ｖ^e＝ａ^mｂ^sｃを満たす数の組である。求職者Ａ_i（クライアント端末Ｃｉ）は、電子署名σのＺＫＰを生成するために、ｎを法とした平方剰余ｈをとり、さらにｈの生成する剰余群Ｚ／ｎの部分巡回群＜ｈ＞の元ｇをとる。

そして、求職者Ａ_i（クライアント端末Ｃｉ）は、以下の情報（コミットメント等）を作成する。

乱数ｒ_mと、ｍのコミットメント Ｃ_m：＝ｇ^mｈ＾（ｒ_m）∈Ｚ／ｎ

乱数ｓ_mと、ｓのコミットメント Ｃ_s：＝ｇ^sｈ＾（ｒ_s）∈Ｚ／ｎ

乱数ｒ_eと、ｅのコミットメント Ｃ_e；＝ｇ^eｈ＾（ｒ_e）∈Ｚ／ｎ

乱数ｗと、ｖのマスク Ｃ_v：＝ｖｇ^w∈Ｚ／ｎ

乱数ｒ_wと、ｗのコミットメント Ｃ_w＝ｇ^wｈ＾（ｒ_w）∈Ｚ／ｎ

ｚ：＝ｅｗ∈Ｚ

乱数ｒ_zと、ｚのコミットメント Ｃ_z＝ｇ^zｈ＾（ｒ_z）∈Ｚ／ｎ

Ｃ：＝（Ｃ_v）^eｈ^r∈Ｚ／ｎ

属性値ｍの暗号文 ｍ’＝ｇ_i ^m

求職者Ａ_i（クライアント端末Ｃｉ）は、ｃ，Ｃ_m，Ｃ_s，Ｃ_e，Ｃ_v，Ｃ_w，Ｃ_z，Ｃ，ｍ’を事業者Ｃ（マッチング装置２０１）に公開した上で、以下の条件を満たすμ，σ，ε，ω，ζ，ρ_m，ρ_s，ρ_e，ρ_w，ρ_z，ρの知識をゼロ知識証明するゼロ知識証明文Πを生成する。

Ｃ＝Ｃ_vεｈρ
Ｃ_e＝ｇεｈ＾（ρ_e）
Ｃ／ｃ＝ａμｂσｇζｈρ
Ｃ_m＝ｇμｈ＾（ρ_m）
Ｃ_s＝ｇσｈ＾（ρ_s）
Ｃ_z＝ｇζｈ＾（ρ_z）
Ｃ_w＝ｇωｈ＾（ρ_w）
Ｃ_z＝Ｃ_wεｈ＾（ρ_z－ερ_w）
ｍ’＝ｇ_iμ

求職者Ａ_i（クライアント端末Ｃｉ）は、電子署名σのＺＫＰとして、ｃ，Ｃ_m，Ｃ_s，Ｃ_e，Ｃ_v，Ｃ_w，Ｃ_z，Ｃ，ｍ’，Πを、事業者Ｃ（マッチング装置２０１）に送信する。そして、事業者Ｃ（マッチング装置２０１）は、ｃ，Ｃ_m，Ｃ_s，Ｃ_e，Ｃ_v，Ｃ_w，Ｃ_z，Ｃ，ｍ’，Πを検証する。

なお、企業Ｂ_jが属性値を提出し、さらに、それにＣＬ署名が付与されている場合、同様にして、その署名のＺＫＰを企業側で生成することにしてもよい。

（実施の形態２）
つぎに、実施の形態２にかかる情報処理システム２００について説明する。実施の形態２では、ユーザ（属性情報提供者）の属性情報ｍ、ユーザ（要件情報提供者）の要件情報ｎの暗号化に、信頼できる第三者から提供される乱数を用いることで、属性情報ｍと要件情報ｎの安全性を高める。なお、実施の形態１の情報処理システム２００と同様の箇所については、同一符号を付して図示および説明を省略する。

ここで、図１９を用いて、実施の形態２にかかる情報処理システム２００の動作例について説明する。ここでは、求人マッチングにおいて、求職者Ａと企業Ｂとのマッチングを事業者Ｃが行う場合を例に挙げて説明する。また、求職者Ａ（クライアント端末Ｃｉ）は、鍵ｇを生成して、鍵管理サーバ２０２に登録済みとする。また、企業Ｂ（クライアント端末Ｃｊ）は、鍵ｈを生成して、鍵管理サーバ２０２に登録済みとする。

図１９は、実施の形態２にかかる情報処理システム２００の動作例を示す説明図である。図１９において、事業者Ｃは、マッチング事業者を表しており、マッチング装置２０１に対応する。求職者Ａは、ユーザ（属性情報提供者）を表しており、クライアント端末Ｃｉに対応する。企業Ｂは、ユーザ（要件情報提供者）を表しており、クライアント端末Ｃｊに対応する。なお、図１９では、電子署名σを「署名」と表記している。

まず、事業者Ｃ（マッチング装置２０１）は、求職者Ａと企業Ｂとをマッチングする際、鍵管理サーバ２０２に、その旨を示すリクエストを送信する。鍵管理サーバ２０２は、事業者Ｃ（マッチング装置２０１）からリクエストを受信すると、乱数ｒを生成して、求職者Ａ（クライアント端末Ｃｉ）と企業Ｂ（クライアント端末Ｃｊ）それぞれに乱数ｒを送信する。鍵管理サーバ２０２は、信頼できる第三者の一例である。乱数ｒは、例えば、鍵ｇ，ｈと同程度のビット長の乱数である。

求職者Ａ（クライアント端末Ｃｉ）は、鍵ｇを生成して、鍵管理サーバ２０２に登録する。また、企業Ｂ（クライアント端末Ｃｊ）は、鍵ｈを生成して、鍵管理サーバ２０２に登録する。鍵ｇ，ｈは、鍵管理サーバ２０２以外には公開されない。鍵管理サーバ２０２は、ペアリング写像を準備する。

求職者Ａ（クライアント端末Ｃｉ）は、鍵ｇおよび乱数ｒを用いて、属性値ｍ（ＴＡＢＬＥにより属性情報ｍをエンコードした値）をｇ^{m^r}に変換して、事業者Ｃ（マッチング装置２０１）に送付する。実施の形態１では、属性値ｍをｇ^mに変換したのに対して、ここでは、属性値ｍをｇ^{m^r}に変換する。

さらに、求職者Ａ（クライアント端末Ｃｉ）は、属性情報ｍに電子署名σが付与されている場合、その電子署名σが暗号化データｇ^{m^r}の平文ｍに対して有効であることのゼロ知識証明文Πを生成して、事業者Ｃ（マッチング装置２０１）に送付する。これにより、求職者Ａ（クライアント端末Ｃｉ）は、事業者Ｃに提出した暗号化データｇ^{m^r}の真正性を保証する。

一方、企業Ｂ（クライアント端末Ｃｊ）は、鍵ｈおよび乱数ｒを用いて、要件値ｎ（ＴＡＢＬＥにより要件情報ｎをエンコードした値）をｈ^{1/n^r}に変換して、事業者Ｃ（マッチング装置２０１）に送付する。実施の形態１では、要件値ｎをｈ^1/nに変換したのに対して、ここでは、要件値ｎをｈ^{1/n^r}に変換する。

事業者Ｃ（マッチング装置２０１）は、求職者Ａ（クライアント端末Ｃｉ）から、暗号化データｇ^{m^r}、ゼロ知識証明文Πを受け付ける。また、事業者Ｃ（マッチング装置２０１）は、企業Ｂ（クライアント端末Ｃｊ）から、暗号化データｈ^{1/n^r}を受け付ける。これにより、求職者Ａから属性情報ｍの暗号化データｇ^{m^r}、属性情報ｍに付与された電子署名σの正当性に関するゼロ知識証明文Πが事業者Ｃに与えられる。また、企業Ｂから要件情報ｎの暗号化データｈ^{1/n^r}が事業者Ｃに与えられる。

事業者Ｃ（マッチング装置２０１）は、鍵管理サーバ２０２から、求職者Ａや企業Ｂの鍵ｇ，ｈではなく、ペアリング演算に関する種々の情報（ペアリングｅ，演算結果ｅ（ｇ，ｈ））を受け取る。そして、事業者Ｃ（マッチング装置２０１）は、ゼロ知識証明文Πを用いて電子署名σの正当性が検証された場合（検証成功）、暗号化データから平文を復号することなく、ペアリングｅの双準同型性を利用してマッチングを行う。

具体的には、事業者Ｃ（マッチング装置２０１）は、暗号化データｇ^{m^r}、ゼロ知識証明文Π、暗号化データｈ^{1/n^r}、ペアリングｅ，演算結果ｅ（ｇ，ｈ）を用いて、ｅ（ｇ，ｈ）とｅ（ｇ^{m^r}，ｈ^{1/n^r}）とが一致するか否かを判定する。ここで、演算結果が一致した場合、事業者Ｃ（マッチング装置２０１）は、マッチング成功とする。

一方、演算結果が一致しない場合、事業者Ｃ（マッチング装置２０１）は、マッチング失敗とする。なお、電子署名σの正当性が検証されなかった場合（検証失敗）、事業者Ｃ（マッチング装置２０１）は、暗号化データｇ^{m^r}をリジェクトする。

以上説明したように、実施の形態２にかかる情報処理システム２００によれば、属性情報ｍおよび要件情報ｎの暗号化の際に乱数ｒを用いたマスクを施すことができる。これにより、実施の形態１で説明した情報処理システム２００に比べて、装置間の送信量は増加するものの、属性情報ｍと要件情報ｎの安全性をより高めることができる。例えば、ｍ，ｎをｒ乗することにより、ｍとｎとの比率（ｍ／ｎ）をわかりにくくさせて、安全性をより高めることができる。

これらのことから、本実施の形態にかかるマッチング装置２０１によれば、マッチング対象となるユーザのデータ（例えば、属性情報ｍ、要件情報ｎ）の内容をマッチング事業者に秘匿しつつ、データ（例えば、属性情報ｍ）の真正性を担保することで、安心で安全なマッチングシステムを提供することができる。

なお、本実施の形態で説明した情報処理方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本情報処理プログラムは、ハードディスク、フレキシブルディスク、ＣＤ－ＲＯＭ、ＤＶＤ、ＵＳＢメモリ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、本情報処理プログラムは、インターネット等のネットワークを介して配布してもよい。

また、本実施の形態で説明した情報処理装置１０１（マッチング装置２０１）は、スタンダードセルやストラクチャードＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）などの特定用途向けＩＣやＦＰＧＡなどのＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）によっても実現することができる。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）第１鍵を用いた指数化により第１データを暗号化した第１暗号化データと、前記第１データに付与された電子署名と、前記電子署名が前記第１暗号化データの元データの真正性を検証可能な情報であることを証明するための証明情報とを受け付け、
第２鍵を用いた指数化により第２データを暗号化した第２暗号化データを受け付け、
前記証明情報を用いて前記電子署名の正当性を検証し、
前記第１鍵および前記第２鍵を管理する管理装置から、所定の関数を用いて前記第１鍵および前記第２鍵から演算された第１演算結果を取得し、
取得した前記第１演算結果と、前記所定の関数を用いて前記第１暗号化データおよび前記第２暗号化データから演算される第２演算結果とを照合する、
処理をコンピュータに実行させることを特徴とする情報処理プログラム。

（付記２）前記照合する処理は、
前記電子署名の正当性が検証された場合に、前記第１演算結果と前記第２演算結果とを照合する、ことを特徴とする付記１に記載の情報処理プログラム。

（付記３）前記証明情報は、前記電子署名が署名者の公開鍵を用いて前記第１暗号化データの元データの真正性を検証可能な情報であることを証明するためのゼロ知識証明文を含み、
前記検証する処理は、
前記公開鍵と前記電子署名と前記第１暗号化データとを用いて、前記ゼロ知識証明文を証明することによって、前記電子署名の正当性を検証する、
ことを特徴とする付記１に記載の情報処理プログラム。

（付記４）前記所定の関数は、双準同型性のある演算を行うペアリング関数である、ことを特徴とする付記１に記載の情報処理プログラム。

（付記５）前記第１データは、第１ユーザの属性を示す属性情報であり、
前記第２データは、前記第１ユーザとは異なる第２ユーザが要求する属性に対する条件を示す要件情報である、
ことを特徴とする付記１に記載の情報処理プログラム。

（付記６）前記第１データは、第１ユーザのデータであり、
前記第２データは、前記第１ユーザとは異なる第２ユーザのデータであり、
前記第１暗号化データは、前記第１鍵と前記管理装置から前記第１ユーザに発行された乱数とを用いた指数化により前記第１データを暗号化したものであり、
前記第２暗号化データは、前記第２鍵と前記管理装置から前記第２ユーザに発行された前記乱数とを用いた指数化により前記第２データを暗号化したものである、
ことを特徴とする付記１に記載の情報処理プログラム。

（付記７）照合した照合結果を出力する、
処理を前記コンピュータに実行させることを特徴とする付記２に記載の情報処理プログラム。

（付記８）前記取得する処理は、
前記電子署名の正当性が検証された場合に、前記管理装置から前記第１演算結果を取得する、ことを特徴とする付記１に記載の情報処理プログラム。

（付記９）前記電子署名の正当性が検証されなかった場合、前記第１暗号化データの真正性の検証に失敗したことを示す検証結果を出力する、
処理を前記コンピュータに実行させることを特徴とする付記１に記載の情報処理プログラム。

（付記１０）第１鍵を用いた指数化により第１データを暗号化した第１暗号化データと、前記第１データに付与された電子署名と、前記電子署名が前記第１暗号化データの元データの真正性を検証可能な情報であることを証明するための証明情報とを受け付け、
第２鍵を用いた指数化により第２データを暗号化した第２暗号化データを受け付け、
前記証明情報を用いて前記電子署名の正当性を検証し、
前記第１鍵および前記第２鍵を管理する管理装置から、所定の関数を用いて前記第１鍵および前記第２鍵から演算された第１演算結果を取得し、
取得した前記第１演算結果と、前記所定の関数を用いて前記第１暗号化データおよび前記第２暗号化データから演算される第２演算結果とを照合する、
処理をコンピュータが実行することを特徴とする情報処理方法。

（付記１１）第１鍵を用いた指数化により第１データを暗号化した第１暗号化データと、前記第１データに付与された電子署名と、前記電子署名が前記第１暗号化データの元データの真正性を検証可能な情報であることを証明するための証明情報とを受け付け、
第２鍵を用いた指数化により第２データを暗号化した第２暗号化データを受け付け、
前記証明情報を用いて前記電子署名の正当性を検証し、
前記第１鍵および前記第２鍵を管理する管理装置から、所定の関数を用いて前記第１鍵および前記第２鍵から演算された第１演算結果を取得し、
取得した前記第１演算結果と、前記所定の関数を用いて前記第１暗号化データおよび前記第２暗号化データから演算される第２演算結果とを照合する、
制御部を有することを特徴とする情報処理装置。

１０１ 情報処理装置
１０２ 管理装置
１０３ 第１ユーザ
１０４ 第２ユーザ
１１０ 第１データ
１１１ 第１暗号化データ
１１２ 電子署名
１１３ 証明情報
１２０ 第２データ
１２１ 第２暗号化データ
１３０ 第１演算結果
１４０ 第２演算結果
２００ 情報処理システム
２０１ マッチング装置
２０２ 鍵管理サーバ
２１０ ネットワーク
２２０ 鍵保管ＤＢ
３００ バス
３０１ ＣＰＵ
３０２ メモリ
３０３ ディスクドライブ
３０４ ディスク
３０５ 通信Ｉ／Ｆ
３０６ 可搬型記録媒体Ｉ／Ｆ
３０７ 可搬型記録媒体
５０１ セットアップ処理部
５０２，７０１ 受付部
５０３ 登録部
５０４ ペアリング演算部
６０１ 鍵生成部
６０２ 暗号化部
６０３ 証明生成部
６０４ 通信部
７０２ 検証部
７０３ 取得部
７０４ 照合部
７０５ 出力部

Claims (9)

1. 第１鍵を用いた指数化により第１データを暗号化した第１暗号化データと、前記第１データに付与された電子署名と、前記電子署名が前記第１暗号化データの元データの真正性を検証可能な情報であることを証明するための証明情報とを受け付け、
   第２鍵を用いた指数化により第２データを暗号化した第２暗号化データを受け付け、
   前記証明情報を用いて前記電子署名の正当性を検証し、
   前記第１鍵および前記第２鍵を管理する管理装置から、所定の関数を用いて前記第１鍵および前記第２鍵から演算された第１演算結果を取得し、
   取得した前記第１演算結果と、前記所定の関数を用いて前記第１暗号化データおよび前記第２暗号化データから演算される第２演算結果とを照合する、
   処理をコンピュータに実行させることを特徴とする情報処理プログラム。
2. 前記照合する処理は、
   前記電子署名の正当性が検証された場合に、前記第１演算結果と前記第２演算結果とを照合する、ことを特徴とする請求項１に記載の情報処理プログラム。
3. 前記証明情報は、前記電子署名が署名者の公開鍵を用いて前記第１暗号化データの元データの真正性を検証可能な情報であることを証明するためのゼロ知識証明文を含み、
   前記検証する処理は、
   前記公開鍵と前記電子署名と前記第１暗号化データとを用いて、前記ゼロ知識証明文を証明することによって、前記電子署名の正当性を検証する、
   ことを特徴とする請求項１に記載の情報処理プログラム。
4. 前記所定の関数は、双準同型性のある演算を行うペアリング関数である、ことを特徴とする請求項１に記載の情報処理プログラム。
5. 前記第１データは、第１ユーザの属性を示す属性情報であり、
   前記第２データは、前記第１ユーザとは異なる第２ユーザが要求する属性に対する条件を示す要件情報である、
   ことを特徴とする請求項１に記載の情報処理プログラム。
6. 前記第１データは、第１ユーザのデータであり、
   前記第２データは、前記第１ユーザとは異なる第２ユーザのデータであり、
   前記第１暗号化データは、前記第１鍵と前記管理装置から前記第１ユーザに発行された乱数とを用いた指数化により前記第１データを暗号化したものであり、
   前記第２暗号化データは、前記第２鍵と前記管理装置から前記第２ユーザに発行された前記乱数とを用いた指数化により前記第２データを暗号化したものである、
   ことを特徴とする請求項１に記載の情報処理プログラム。
7. 照合した照合結果を出力する、
   処理を前記コンピュータに実行させることを特徴とする請求項２に記載の情報処理プログラム。
8. 第１鍵を用いた指数化により第１データを暗号化した第１暗号化データと、前記第１データに付与された電子署名と、前記電子署名が前記第１暗号化データの元データの真正性を検証可能な情報であることを証明するための証明情報とを受け付け、
   第２鍵を用いた指数化により第２データを暗号化した第２暗号化データを受け付け、
   前記証明情報を用いて前記電子署名の正当性を検証し、
   前記第１鍵および前記第２鍵を管理する管理装置から、所定の関数を用いて前記第１鍵および前記第２鍵から演算された第１演算結果を取得し、
   取得した前記第１演算結果と、前記所定の関数を用いて前記第１暗号化データおよび前記第２暗号化データから演算される第２演算結果とを照合する、
   処理をコンピュータが実行することを特徴とする情報処理方法。
9. 第１鍵を用いた指数化により第１データを暗号化した第１暗号化データと、前記第１データに付与された電子署名と、前記電子署名が前記第１暗号化データの元データの真正性を検証可能な情報であることを証明するための証明情報とを受け付け、
   第２鍵を用いた指数化により第２データを暗号化した第２暗号化データを受け付け、
   前記証明情報を用いて前記電子署名の正当性を検証し、
   前記第１鍵および前記第２鍵を管理する管理装置から、所定の関数を用いて前記第１鍵および前記第２鍵から演算された第１演算結果を取得し、
   取得した前記第１演算結果と、前記所定の関数を用いて前記第１暗号化データおよび前記第２暗号化データから演算される第２演算結果とを照合する、
   制御部を有することを特徴とする情報処理装置。

Images