JP4116971B2 - グループ署名のための暗号システム - Google Patents

Description

発明の詳細な説明

本発明は、サービスのセキュリティーに関し、より正確には、暗号を用いた電子メッセージ署名におけるセキュリティーについての技術分野に関するものである。

電子署名の仕組みは、いわゆる公開鍵暗号方式に基づいている。署名者は、秘密鍵と、この秘密鍵に関連する公開鍵とを有している。そして、自己の秘密鍵を用いて、メッセージに署名する。照合者は、署名の照合には、公開鍵さえあればよい。

より正確には、本発明は、電子グループ署名に関するものである。グループ署名により、グループのメンバは署名を作成できる。この署名では、照合者は、署名がグループ内のあるメンバによって作成されたものであることを、どのメンバが作成したのかを知ることなく認識できる。しかし、認証機関は、この匿名性をいつでも排除することができる。したがって、署名の個人情報を明らかにできる。この種の署名は、しばしば「非対応」と呼ばれる。この種の署名では、二つの署名が同一人物によって発行されたのか否かを決定できない。

従来の如何なるグループ署名の仕組みにおいても、グループには、一意のグループ公開鍵が割り当てられる。一方、グループの各メンバには、メンバ固有の識別子と秘密鍵とが割り当てられる。グループのメンバは、自己が選択したメッセージのためのグループ署名を作成するために、自己の秘密鍵を用いることができる。受信者は、誰であっても、グループの公開鍵を用いて、その署名を照合できる。この署名照合により、受信者は、この署名がグループ内のあるメンバにより作成されたものであるとわかる。しかし、どのメンバが署名をしたのかを識別するための情報を、何も得ることができない。一方、認証機関は、メンバの識別子を見出すことができるため、こういった匿名性をいつでも排除できる（このことを認証機関が署名を「開放する」と言う）追加の情報を有している。

グループ署名については、以下の２例を含み、多くの応用分野がある。

図１には、第１の適用分野である電子オークションが記述されている。この電子オークションは、オークションサーバ２、認証機関４、および顧客Ｃｌの３つの構成要素を有している。顧客の全ては、「顧客グループ」と呼ばれるグループＧを形成している。顧客グループＧに入会を希望するユーザは、認証機関４に連絡を取る。認証機関４は、連絡を取ったユーザに秘密鍵ＳＫを提供する。このようして、ユーザは、グループ署名を作成する権利を得る。この権利をもって、ユーザは、オークションのたびに匿名で署名できる。個々の商品を入札するときは、顧客グループの各メンバは、個々の競売商品と自己の入札額情報とを含んだメッセージに署名をする。これによって、入札額を増やすことができる。オークションサーバ２は、メンバがグループに所属しており、メンバの入札額は有効であることを、グループ署名を照合するだけで確認できる。勝者とは、受賞までの間に、もっとも高額で入札した人のことである。したがって、入札サーバが最後に受け付けたメッセージが、勝者のメッセージである。それからサーバは、このメッセージと対応するグループ署名とを、認証機関４宛てに送る。認証機関４は、単独でメンバの匿名性を排除できる。したがって、オークションにおいて商品を入札した買い手が、実際に誰であるかを決定できる。

入札はすばやく行なわれなければならない。顧客は非常に短時間の間に入札を行なう。その短時間の間に、ある価格で入札した最初の入札者が、入札の勝者となる良い機会を得る。なぜなら、他の顧客にとってあまりに高額すぎるレベルにまで達するからである。このような理由により、入札署名の仕組みには時間をかけるべきではない。

図２には、もう一つの適用分野である匿名電子決済が記述されている。この匿名電子決済は、顧客Ｃｌ、販売店６、銀行８、および認証機関４の４つの構成要素を有している。各顧客Ｃｌは、最初のトランザクション処理を実行する前に、システムに登録して、グループ署名の秘密鍵ＳＫを手に入れなければならない。支払いを行なうために、顧客は、電子マネーＰＥを銀行８から引き出す。ここで、電子マネーとは、銀行によりデジタル署名がなされたデータ（シリアル番号）である。顧客が引き出した電子マネーＰＥは、いわゆる非公開署名機構を用いているため、匿名である。

電子マネーＰＥは、以下のようにして販売店６に支払われる。顧客（この例ではＣｌ１）は、電子マネーＰＥに関連付けたグループ署名を生成する。そして、署名とＰＥとをセットにして販売店に送信する。この電子マネーが有効であり（銀行署名に基づき照合）、グループ署名が本物であれば、販売店は、このトランザクションを承諾する。その日の終わりに（または最も適した時間に）、販売店は、支払いのために受け取った電子マネーと署名とを、共に銀行へ送信して、銀行が電子マネーに見合う価格を支払うことができるようにする。

不正があった場合（例えば、同一の電子マネーがいくつかのトランザクションで使用されている場合）、銀行は、疑わしい電子マネーに出現しているグループ署名を認証機関４に送信して、不正な顧客を識別し、適切な処罰を適用する。

グループ署名の仕組みについて、数多くの論文が提唱されている。そのうちの２つの文献が、本件においてもっとも頻繁に言及されている。

文献１：Ｊ． Ｃａｍｅｎｉｓｃｈ， Ｍ． Ｓｔａｄｌｅｒ 著 「大規模グループにおける効率的グループ署名の仕組み」 Ｂ． Ｋａｌｉｓｋｉ 編 暗号学会；Ｅｕｒｏｃｒｙｐｔ‘９７， ｖｏｌ． １２９４ コンピュータサイエンス講演記録より、頁４１０―４２４． Ｓｐｒｉｎｇｅｒ Ｖｅｒｌａｇ 出版 １９９７年
文献２：Ｇ． Ａｔｅｎｉｅｓｅ， Ｊ． Ｃａｍｅｎｉｓｃｈ， Ｍ． Ｊｏｙｅ， Ｇ． Ｔｓｕｄｉｋ 著 「実用的で確実に安全な非一体グループ署名の仕組み」 Ｍ． Ｂｅｌｌａｒｅ 編 暗号学会− ＣＲＹＰＴＯ ２０００， ｖｏｌ． １８８０ コンピュータサイエンス講演記録より、頁２２５―２７０． Ｓｐｒｉｎｇｅｒ Ｖｅｒｌａｇ 出版
上記文献は、全て、以下のような同一の一般的概念に基づいている。

まず、上記文献は、例えばＲＳＡ（Ｒｉｖｅｓｔ，Ｓｈａｍｉｒ，Ａｄｌｅｍａｎ）アルゴリズムに従って、一般的な署名の仕組みについて考察する。このＲＳＡ方式は、確率的暗号方式であり、かつ強秘匿である。ここで、確率的暗号方式は、もし同じメッセージが２回暗号化されたら、対応する暗号文は異なるという考えに基づく。また、強秘匿とは、平文についてのいかなる情報も、暗号文からは得ることができないことを意味する。

グループＧを管轄する認証機関４は、暗号および署名鍵を生成する。次に、対応する公開鍵を、一般的にアクセス可能な場所、例えばディレクトリ内に置く。認証機関４は、関連付けられている秘密鍵ＳＫを秘密にしておく。

ある人がグループのメンバになることを希望する場合、その人は、識別子を決定し、メンバ証明書を取得するために認証機関４に連絡を取る。ここで、識別子とは、数値で表され、認証機関が、そのグループに所属しているその個人、または法人に関連付けできるものである。証明書は、実際に識別子の署名が認証機関の秘密署名鍵ＳＫを用いていることを証明する。

当該メンバは、グループの一員としてメッセージｍに署名するために、二つの処理を行なう。第１の処理では、メンバは、認証機関の公開暗号鍵（この部分は署名を開放するのに用いられる）を用いて、自己の識別子を暗号化する。第２の処理では、メンバは、暗号文（メンバが実際にそのグループの一員であることを証明する）に含まれた平文に関連付けられているメンバ証明書を自己が知っていることを証明する。

本件は、暗号文について考察する。より具体的には、グループ署名において要求されている特性を得るための知識の証明について考察する。

署名の照合は、上記知識、例えばゼロ知識型の証明の照合を含む。署名を開放するとは、単に識別子を解読することである。

この原理の主に不便な点は、計算量である。各署名は、暗号化（第１の処理）、および、特に多くの知識証明（第２の処理）を必要とする。これらの処理は、実際に、計算に非常に時間がかかる。なぜなら、これらの処理には、モジュール化された指数計算が多数、含まれているからである。（例えば、モジュール化された指数計算は、それぞれ、暗号プロセッサが組み込まれているスマートカード上で、約１秒かかる。）
上記を鑑みて、本発明の目的は、非常に高速で、言い換えれば、非常に小さなモジュール化された指数計算（例えば、通常、最高でも１または２の指数）を必要とする一方で、既存のグループ署名システムの特性（署名の容量が一定であり、仕組みが安全であり、新しいメンバが入ったときに公開鍵が不変である点等）を維持するグループ署名の仕組みを実現することにある。

産業的には、本発明は、スマートカードやこれと同様の携帯型通信装置のような、小容量の計算機を用いた場合でも、高速実行を実現する。

特に、本発明の第一の目的は、以下のようなグループ署名システムである。本発明のグループ署名システムでは、グループのメンバは、各人用のデータを、署名付きのメッセージを作成するために使用することができる。この署名は、照合者にとって、メッセージがグループのメンバにより作成されたことの証明となる。本発明のグループ署名システムは、個人用データが、電子ハードウェア支援機器に記録される形式を取っている点を特徴としている。

好適な一実施形態では、電子ハードウェア支援機器は、また、個人用の暗号化を、メッセージ署名以前に個人用データから始めるようにするための暗号化手段と、例えばメッセージを暗号文に連結するなどによって、メッセージに関連付けられ、署名され、かつ暗号化されたテキストにメッセージを結合させる手段と、メッセージに関連付けられた暗号の形の個人用データを含むメッセージに署名する手段とを備えている。

個人用データは、メンバおよび電子ハードウェア支援機器に固有の識別子であってよい。電子ハードウェア支援機器は、グループの全てのメンバに共通する暗号鍵を含んでいる。また、個人用データは、暗号鍵を用いて識別子を暗号化する暗号化手段であってもよい。

さらには、暗号化手段は、識別子および乱数を暗号化してもよい。

また他にも、個人用データは、各グループメンバに特有のさまざまな暗号鍵であってよいし、暗号鍵を用いて少なくとも一つのデータ、例えば乱数を用いて暗号文を作成する暗号化手段であってもよい。

暗号化手段は、秘密鍵を用いた暗号アルゴリズム、例えばＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）として知られているアルゴリズムなど、または、公開鍵暗号アルゴリズム、例えばＲＳＡ（Ｒｉｖｅｓｔ，Ｓｈａｍｉｒ，Ａｄｌｅｍａｎ）として知られているアルゴリズムなどを用いることが可能である。

さらに、署名手段は、秘密鍵署名アルゴリズム、例えばＲＳＡとして知られているアルゴリズムを用いることが可能である。このアルゴリズムは、いわゆる公開鍵暗号標準ＰＫＣＳ＃１を含んでいる。この標準は、特に、文献「ＲＳＡ暗号標準−ＲＳＡ研究所−草稿２−２００１年１月５日」において定義されている。

さらに、電子ハードウェア支援機器は、携帯型通信装置であり、特にスマートカードである。

第二の特徴によると、本発明はまた、メッセージを、このメッセージに関連するグループ署名と共に送信する方法に関するものである。この方法は、本システムの第一特徴を用いている点を特徴としている。すなわち、本方法は、グループメンバに共通する秘密鍵ＳＫによって作成され、電子ハードウェア支援機器によって作成された個人用データを含んでいるメッセージ署名を用いている点を特徴としている。

また、本方法は、グループに所属するメンバであるという証明、例えばメンバ証明書、または、そのような証明書の所有権証明などを照合者に提供する必要なく、署名されたメッセージを照合者に伝送することを含んでいる。

第三の側面によると、本発明は、メッセージのグループ署名と共に受信したメッセージを照合する方法に関するものである。ここで、本方法では、上記メッセージは、第二の側面による方法に従って送信され、上記照合は、秘密鍵に対応する公開鍵を用いてなされる点を特徴としている。

第四の側面によると、本発明は、第一の側面におけるシステムにより作成された署名を開放する方法に関するものである。本方法は、以下のステップを含むことを特徴としている。すなわち、本方法は、署名以前に入手可能なグループメンバの識別情報と、その個人用のデータとの間に通信データを作成するステップと、署名を開放するための電子ハードウェア支援機器から受信した個人用のデータを復号するステップと、復号された個人用のデータを該グループメンバの識別情報に対応させるステップとを含んでいる。

第五の側面によると、本発明は、第一の側面における、すなわちグループに受け入れられたメンバを個別化するシステム向け電子ハードウェア支援機器を備える方法に関するものである。本方法は、以下のステップを含むことを特徴としている。すなわち、本方法は、個人化された電子ハードウェア支援機器で使用するために、個人用データを生成するステップと、個人用データを秘密署名鍵によって支援機器に登録するステップとを含んでいる。

本発明および本発明の結果による有利な点は、添付されている図面を参照しながら、以下に記述されている好適な実施形態に目を通すことによって、より明らかになるであろう。なお、以下の実施形態は、本発明を限定しない純粋に例示的なものである。

図１は、オークションの状況におけるグループ暗号化の例を示す主要図である。

図２は、電子マネーによる購入の状況におけるグループ暗号化の例を示す主要図である。

図３は、本発明にしたがったメッセージの署名向けの、スマートカードを用いたトランザクションを表すために使用される図である。

図４は、本発明に係るグループ署名を作成するために使用可能なスマートカードにおける機能要素のブロック図である。

図５は、本発明に係るグループ署名を作成するための、スマートカードに含まれる機能要素を一般化して表したフローチャートである。

図６は、図５のフローチャートにおける特定要素についての、実施形態の第一例のフローチャートである。

図７は、第一の例とは異なる例のフローチャートである。

図８は、図５のフローチャートとは異なる特定要素についての、実施形態の第二例のフローチャートである。

本発明は、最新技術における上述した第１および第２の２つの処理を考察するより、むしろ、識別子が、個人や法人に直接に関連付けられているのではなく、グループに認証されたメンバに割り当てられている電子通信装置に組み込まれているという方法論に基づく。本実施形態では、上記装置は、スマートカード、またはスマートカードを内蔵した格納装置（例えば携帯電話端末）等のように、典型的に携帯可能なものである。さらに、同じ物理的アセンブリにおいて、電子データの形で記録されている個人用データ（識別子または多様化された暗号鍵）と、上記データを暗号化する手段と、送信すべきメッセージと暗号化された個人用データテキストの組み合わせにグループ署名を作成する手段とを含んでいる。

図３は、本発明の実施形態の一例を表す。この例では、グループＧのメンバＭは、個人用スマートカード２６を使用し、サービスプロバイダ（入札サーバ２および販売店６）によるトランザクション処理を実行する。メンバＭとサービスプロバイダとの間の通信は、既知の任意の手段によって確立されるものとする。例えば、メンバのパーソナルコンピュータ（ＰＣ）１０から、インターネット等の通信ネットワークを介して通信を確立してもよい。または、外付けスマートカードリーダ２７ａを備えている携帯電話２７により、サービスプロバイダ２，６とのデータ交換を確立し、次に、無線通信手段２９によって携帯電話のアンテナ２７ｂを介して通信を確立してもよい。

パーソナルコンピュータは、特に、システムユニット１４と、モデムカード１６またはネットワーク１２と間のその他の通信インターフェースと、表示画面１８と、ポインティングデバイス２２を備えたキーボード２０とを含んでいる。このパーソナルコンピュータは、また、スマートカードリーダ２４を含んでいる。スマートカード２６は、システムユニット１４およびネットワーク１２との通信が可能である。上記カードのチップ部分２６ａは、保護型のものが好ましい。

入札サーバ２および販売店６により提供されるサービスは、図１および２の説明でそれぞれ記述されたサービスと同一である。簡略化のため、再びは記述しない。販売店６に対する銀行８および認証機関４による処理の方法についても、ほぼ同様である。

本発明において、認証機関４は、認証機関によって承認された、グループＧのメンバＭに識別子ｚを発行する。このとき、認証機関４は、ハードウェア機器に直接、結局は保護チップ２６ａによって個別化されている個人用スマートカード２６の形で、識別子ｚを発行する。

個人データは、認証機関が管理している端末を用いて、データ変換プロトコルによってカードに登録されている。このとき、個人データは、識別子ｚ、またはＫｚで示される分散ド内に格納される。

認証機関４は、また、個人用データを、既存のスマートカードを用いて生成してもよい。この既存のカードは、発行後のデータをロードできる性質を有する。特に、本例では汎用性のあるカードであり、端末からダウンロードすることによっていつでも新しいアプリケーションを受け付けるように設計され、いくつかの異なったサービスや機能を同じ支援機器上に兼ね備えている。

したがって、認証機関は、個人に対して発行されている個人用カード２６を用いることによって、グループＧのメンバ（個人または法人で、一般に「個人」として示されている）を個人用データに関連付けている。したがって、個人は、個人用データを自分で記録する必要もなく、自分がそのデータを所有していることの暗号証明を提示する必要もない。

希望者がグループＧのメンバになるための条件を、通常の確認事項および事前の注意事項と共に満たすと、認証機関４によって、個人用カード２６が希望者に発行される。この方式は、従来の銀行においてカードが発行される方式と同様なものである。特に、認証機関は、発行されたカード２６に格納されている個人用データと、このカードを返却された個人の識別情報（たとえば名前）とにおける関連性を記録する。

その結果、セキュリティは、この場合、第一に保護チップ２６ａを含む装置に基づき、第二に鍵に基づく。この鍵は、個人用データが鍵によって暗号化されるべき識別子である場合に、グループＧの全てのメンバＭによって共有され、グループ署名を生成してもよい。または、鍵は、それ自身に個人用データを形成する場合、分散されたもの、換言するとメンバに特定のものであってもよい。以下の記述は、このような方法論の詳細な特徴を表す。

まず、本発明の実施形態では、通常の署名システムＳおよび確率的かつ記号論的暗号アルゴリズム（公開鍵アルゴリズムまたは秘密鍵アルゴリズム）を用いる。次に、グループＧを管轄している認証機関４は、署名鍵ＳＫまたはこれと同様の鍵を生成し、これと対応する公開鍵をディレクトリ内に置く。また、認証機関４は、個人の署名鍵を秘密にし、暗号アルゴリズムを使用するために必要な全ての情報を公表する。

メンバになるため、個人は、スマートカード２６を認証機関４から入手する。このスマートカードは、第一に、識別子ｚまたは分散鍵Ｋのいずれかを含んでいる（認証機関は、スマートカード，識別子ｚ、分散鍵Ｋ、および新規メンバＭとの間の関連性をメモリに記憶している）。そして、スマートカードは、第二に、秘密署名鍵ＳＫを含んでいる。したがって、秘密署名鍵ＳＫは、確かにグループＧの全てのメンバ間で共有されている。このカードは、また、認証機関により提供されたアルゴリズムを用いる、暗号処理のために必要な全ての情報を含む。スマートカード２６に組み込まれた要素組が与えられると、メンバＭは、グループＧの一員として、スマートカードを用いてメッセージｍに署名できる。そして、この署名Ｓは、必要になれば、認証機関によって（認証機関のみによって）開放されうる。

グループの一員としてメッセージｍに署名をするために、メンバは、自己のスマートカードを使用する。このスマートカードは、メッセージｍを入力として利用するものである。このスマートカードは、認証機関の暗号アルゴリズムを用いて、メンバに特有の暗号を作成することによって、動作する。さらに、少なくとも初期のメッセージｍと、あらかじめ取得され暗号化されたメッセージとを含んでいるメッセージに、署名する。この署名は、メモリに記憶された共有の秘密署名鍵を用いて生成される。出力時、スマートカード２６は、メッセージ、暗号文、および署名を、宛先２，６（照合者）に送信する。

署名の照合では、単に、共有する秘密鍵により作成された署名を、対応する公開鍵を用いて照合する。認証機関４による署名の開放では、個人用データを復号し、スマートカード２６の所有者の個人識別情報との一致を見出す。

これらは、カードにおいて非常に高速に行われる。署名Ｓの時点において、作成されるべき暗号および署名が一つしかないからである（したがって、指数は最高でも二つである）。

識別子とメッセージとの間の関連が、暗号化の仕組み（知っていることの証明）によってなされなければならないような、グループ署名に関する当業技術とは異なり、本発明は、有体物のセキュリティに基づくハードウェアのセキュリティ手法を用いてる。この手法は特に安全であり、スマートカード２６を用いている。

スマートカードに対する実施形態の動作の原理を、図５〜７におけるフローチャートを参照して、さらに詳細に記述する。まず、本発明に用いることができるスマートカードの一般的な設計思想を、図４を参照して記述する。

図４は、スマートカード２６の可能な一つの設計思想に従った、機能要素の単純なブロック図を表している。これらの要素として、以下のものが含まれている。まず、内部機能を管理し、カードのアプリケーションプログラムを実行するマイクロプロセッサ２８である。このマイクロプロセッサは、暗号処理計算用に最適化された「暗号プロセッサ」を含んでいてもよい。次に、書き込み可能なランダムアクセスメモリ（ＲＡＭ）３０である。このメモリは、一時的なデータ、例えばアルゴリズム計算の中間結果などを記憶することを含むいくつかの目的で利用される。さらに、電気的消去可能なプログラム可能読取専用メモリ（ＥＥＰＲＯＭ）技術を利用して作られた不揮発性メモリ３２である。このメモリは、特にカード製造後のデータ、例えばカードの中の個人用データや使用されるアルゴリズムに関連するソフトウェアコードなどの長期保存に用いられる。さらに、マスクを用いた製造工程において書き換え不可能なデータがプログラムされている「マスク」ＲＯＭ型の固定メモリ３４である。このメモリは、特に、カードの内部管理コードを格納しており、またグループのメンバに共通する暗号化データを格納できる。また、設計者は、データ記憶装置を、ＥＥＰＲＯＭメモリ３２とマスクＲＯＭメモリ３４との間でどのように分配するかを選ぶ。さらに、通信インターフェース３６である。このインターフェースを介して、カードは、カードリーダ２４または２７ａなどの外部環境との間においてデータを交換する。さらに、上述の各要素を接続する内部バス３８である。

カード２６における、メッセージに署名するための動作の一般的な原理を、図５に示す。この図は、一つの枠により構成されており、その枠の内側で、全ての要素（データまたは処理）がスマートカードの範囲内に配置されている。この枠を２６と称するのはこのためである。この図では、個人用データは識別子ｚの形をとっている。

グループの署名Ｓと共に転送されるべき各メッセージｍに対して、カード２６は、カードの識別子ｚ（ボックスＢ１）を暗号アルゴリズム（以下Ｅと称す）（ボックスＢ２）に送る。ボックスＢ１は、分散鍵Ｋｚを用いる場合は省略できるため、破線で示す。この処理は、特に、カードのメモリ、たとえばＥＥＰＲＯＭメモリ３２から内部に読み出された識別子ｚをパラメタとして挿入し、ＥＥＰＲＯＭ３２から（または必要があればマスクメモリＲＯＭ３４から）読み出されたアルゴリズムＥのコードを、マイクロプロセッサ２８に実行させるステップを含む。このアルゴリズムＥは、また、乱数および暗号鍵などの、少なくとも一つの別のパラメタを使用する。この例は後述する。識別子ｚにアルゴリズムＥを適用した結果、識別子Ｃ（すなわちＥ（ｚ））（ボックスＢ３）は暗号された形式となる。暗号文Ｃは、メモリ３２に、一時的かつ内部に保存される。

同時に、カードは、署名されるべきメッセージｍを、通信インターフェース３６において受信し、ＲＡＭメモリ３２（ボックスＢ４）に一時的に記憶する。

カードは、次に、メッセージｍと暗号文Ｃとの連結ｍ’（ボックスＢ５）を実行する。この結果、ｍ’＝ｍ｜｜Ｃとなる。この処理は、バイナリシーケンスを生成するステップを含む。このバイナリシーケンスは、暗号文Ｃのビットが後に続くか、先行するか、または後に続きかつ先行するメッセージｍにおけるビットのシーケンスを含んでいる。

連結ｍ’は、次に、もう一つのアルゴリズムに、パラメタとして引き渡される。このアルゴリズムは、署名アルゴリズム（以下Ｓｉｇと称す）（ボックスＢ６）と呼ばれ、秘密署名鍵ＳＫを用いてｍ’の署名を生成するものである。特に、この処理は、ＥＥＰＲＯＭ３２から（可能であればＲＯＭ３４から）読み出されたアルゴリズムＳｉｇのコードを、マイクロプロセッサ２８に実行させるステップを含む。このとき、カードのメモリ、たとえばＥＥＰＲＯＭメモリ３２から内部に読み出された署名鍵ＳＫの一部をパラメタとして挿入し、次にＲＡＭメモリ３０から読み出された連結ｍ’を挿入する。

アルゴリズムＳｉｇによってこのようにして生成される、メッセージｍの認証された署名Ｓは、カード２６の通信インターフェース３６に出力され、グループＧのトランザクションシステムの状況において使用される。特に、オペランドｍ’において秘密署名鍵ＳＫによって生成された署名、すなわちＳｉｇＳＫ（ｍ’）は、パーソナルコンピュータ１０または携帯電話２７からサービスプロバイダ２または６へ転送される、集合（ａ ｓｅｔ）を形成する。

「照合者」として処理を行なうこれらのプロバイダは、署名Ｓｉｇ_ＳＫ（ｍ’）から抽出されたメッセージｍが、確かに認証カード２６から生成されたものかどうかを、証明アルゴリズム（以下Ｖｅｒ_ＰＫ（ｍ’，Ｓ））、および、認証機関４により一般に提供されている公開鍵ＰＫを用いて決定することができる。このアルゴリズムは、二分法アルゴリズムであり、ｙｅｓまたはｎｏの値を返す。

認証機関４において、上記署名は、復号アルゴリズムＤを用いて、識別子ｚとスマートカード２６の所有者の個人識別情報との対応関係、すなわちｚ＝Ｄ（Ｃ）を見出すために開けられる。

表１に、上記概略全般に関わるさまざまな当事者によって用いられる、エンティティの要約を記す。

図５における一般的な実施形態に基づいて、図６〜８をそれぞれ参照しながら、２つの特定例を以下に記述する。これらの各図は、図５においる表記に基づくフローチャートである。図６〜８における要素（ボックス）は、図５におけるそれぞれに対応するが、個別の形態を取っている。図６〜８における要素（ボックス）は、図６においては、同じ参照記号に「’（プライム）」符号を、また図７においては、「”（ダブルプライム）」符号をつけて表す。図５と図６〜８とにおいて全く同一の要素については、同一の参照記号を用いる。図５を参照しながら、記述の図６〜８に共通の特徴については、簡略化のため、以下に繰り返し記述することはしない。

第１の例として、ＡＥＳ暗号アルゴリズムおよびＲＳＡ署名に基づく実施の形態を説明する。

この例（図６）では、選択した署名の仕組みがＲＳＡアルゴリズムである。モジュールはｎ、秘密鍵はＳＫで表され、この秘密鍵は、共有する鍵、すなわち公開鍵ＰＫに対応している。この例において選択する暗号アルゴリズムは、ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）である。この暗号アルゴリズムは、したがって、秘密鍵を用いたアルゴリズムである。関連付けられた鍵は、Ｋで表される。図示されている例では、この鍵はグループＧの全てのメンバＭの間において共有されている。認証機関は、ＰＫを公表し、その他の鍵を全て秘密にする。

第１の例に関して、ＡＥＳ暗号アルゴリズムＢ２’は、以下の入力パラメタ、（１）識別子ｚ（ボックスＢ１）、（２）グループＧにおいて承認されている全てのメンバＭ間において共有されており、ＥＥＰＲＯＭメモリ３２に格納されている秘密暗号鍵Ｋ（ボックスＢ８）、（３）乱数ｒ（ボックスＢ９）を受け取る。この乱数は、あらかじめ決められた固定長バイナリで、マイクロプロセッサ２８によって実行されるソフトウェアコードを用いて、カード２６の中で生成される。乱数ｒは、メッセージｍが署名されるたびに更新される。

ＡＥＳアルゴリズムは、次に、識別子、ＡＥＳによる乱数ｒ、および秘密鍵Ｋが暗号化された形態であるＣを生成する（ボックスＢ３’）。

この暗号化値Ｃは、次に、ｍ’＝ｍ｜｜Ｃに結び付けられ（ボックスＢ５）、次に、入力パラメタとしてＲＳＡ（Ｒｉｖｅｓｔ，Ｓｈａｍｉｒ，Ａｄｌｅｍａｎ）タイプの署名アルゴリズム（ボックスＢ６’）に引き渡される。このアルゴリズムは、秘密署名鍵ＳＫを入力データ（ボックスＢ７）として用いる。この秘密署名鍵ＳＫによって、上記アルゴリズムは、ＲＳＡ署名ｍ”、すなわちＳ＝ｍ”^ＳＫ ｍｏｄ ｎを生成する。ここでｍ”はｍ’におけるＰＫＣＳ＃１の結果である。ＰＫＣＳ＃１における「ｍｏｄ ｎ」とは、算術法（ａｒｉｔｈｍｅｔｉｃ ｍｏｄｕｌｏ）ｎのことである。また、ＰＫＣＳ＃１は、特に、「ＲＳＡ暗号標準−ＲＳＡ研究所−草稿２−２００１年１月５日」において定義された標準である。

表２は、第１の例に関連した、グループＧに関係する異なる部分によって用いられるエンティティを要約する。

追加のセキュリティは、認証機関を二つに分けるステップを含む。第一の部分は、秘密鍵ＳＫのみを保持している（かつ、メンバの識別子についての情報を有していない。）上記はグループ認証機関（グループの登録段階に含まれる）である。第二の部分は、鍵Ｋのみ、および、グループメンバの全ての識別子を保持している。上記は開放機関（署名開放段階に含まれる）。このように、一つの認証機関のみは、いずれも、一つのメンバの代わりとならない。このアプローチは、システムの全セキュリティについて、一つの機関のみを信用しない方が望ましいという原則に基づいている。

新規メンバがグループに入った場合、認証機関は、新しいスマートカードをそのメンバ用に作成し、ＳＫ，Ｋ，および値ｚ（メンバの識別子）を、メモリｎに格納する。ここで、値ｚは、認証期間のデータベースにおいて、新規メンバに関連付けられている。

メンバがメッセージに署名を行うことを望む場合、そのメンバは、自己のカードをリーダに差し込み、そのカードにメッセージｍに署名を行なうように指示する。スマートカードは、まず、Ｋ鍵，値ｚ，および乱数ｒを入力データとして用いるＡＥＳアルゴリズムを使用して（暗号化はこのように確率的である）、出力時に暗号文Ｃを得る。このカードは、次に、メッセージｍと、取得直後の暗号文Ｃとを結びつけることによって、メッセージｍ’を作成し、それから、例えばＰＫＣＳ＃１標準にしたがって、結果をメッセージｍ”へと変更する。最後に、カードは、Ｓ＝ｍ”^ＳＫ ｍｏｄ ｎを計算する。（Ｓ，Ｃ）の組み合わせは、メッセージｍのグループ署名である。

照合者は、署名が確かにグループのメンバにより行なわれたものであることを照合する際、ｎおよびＰＫのみ必要とする。照合者が行なうべきことの全ては、上記で定義されている標準にしたがって、Ｓ＝ｍ”^ＳＫ ｍｏｄ ｎを照合することである。さらに、照合者は、Ｃを復号することはできないため（Ｋ鍵を持っていないので）、どのメンバを取り扱っているのかを知ることはできない。

認証機関が署名の開放を希望する場合、ｚを取得するために、ＡＥＳアルゴリズムおよびＫ鍵を用い（復号のための乱数ｒを知る必要はない）、かつ、データベースを検索して、誰がｚに対応しているのかを見つければよい。

セキュリティレベルを向上させた別の例では、識別子にしたがった、分散暗号鍵Ｋｚを選択するステップ、または乱数ｒを暗号化するステップのみを含む。すなわち、異なる鍵ＫｚがグループＧの各メンバＭに割り当てられるステップを含む。

図７に示す別の例では、もはや識別子ｚは使用されない。カード２６の特定に不必要だからである。その代わり、個々の識別は、分散暗号Ｋｚ（ボックスＢ８）によって直接行なわれる。というのも、暗号Ｋｚは、個別のものだからである。

ハードウェアに関して言えば、上記別の例においても、第一の例と同様に用いられる。ただし、パラメタとしての乱数ｒのみを、暗号アルゴリズム（ここでもＡＥＳアルゴリズムであってよい）に入力することによって用いられる。また、乱数は、上述のようにロードされる（ボックスＢ９）。ボックスＢ１は、当然のことながら省略される。次に、暗号文Ｃの結果の算出は、同一の方法（ボックスＢ３’およびそれに続くボックス）において処理される。ここで、暗号文に組み込まれた乱数ｒは、署名からメッセージｍを分離させる機能と同じ働きをする。

このように、もしスマートカードが改変された場合でも、不正行為者は、カード上の分散鍵Ｋｚにアクセスすることができるのみである。そのため、カードに格納されている識別子とは異なる別の識別子を用いて、グループ署名を生成することはできない。開放段階は、したがって、正しい鍵が発見されるまで、存在する全ての鍵をテストするステップを含む。

第２の例として、ＲＳＡ暗号アルゴリズムおよびＲＳＡ署名に基づく実施の形態を説明する。

この例（図８）は第一の例（図６または図７）と類似する。そこで、第一の例とは異なる箇所のみを以下に記述する。

ここに選択された署名の仕組みは、再びＲＳＡアルゴリズムである。モジュールはｎで示され、秘密鍵はＳＫで共通鍵に対応している。公開鍵はＰＫである。上述の標準において記述されたような暗号システムＲＳＡであるため、ここでは、暗号アルゴリズムは非対称的である。モジュールは、以下にｎ’で表される。公開暗号鍵はｅであり、関連付けられた秘密鍵はｄである。

新規メンバがグループに入った場合、認証機関は、新しいスマートカード２６を生成するか、または、データを既存のカードにロードし、値ｚ（新規メンバの識別子）と共に、ｎ，ｎ’，ｅ，およびＳＫをメモリに配置する。ここで、認証期間のデータベースにおいて、値ｚは新規メンバに関連付けられている。

メンバがメッセージに署名を希望する場合、そのメンバは、自己のカード２６をリーダ２４または２７ａに差し込み、メッセージｍに署名を行なうよう指示する。上記カードは、まず、ＲＳＡ暗号システム（ボックスＢ２”）を用いて、識別子ｚを暗号化する。このことを達成するため、上記カードは、値ｚ’を取得するために、例えば上述の標準にしたがって値ｚを変更する（この変更では、ｚおよび乱数ｒが入力パラメタとして用いられている（ボックスＢ９））。上記カードは、次に、Ｃ＝ｚ’^ｅ ｍｏｄ ｎ’を生成する。この値は、公開鍵ｅ（ボックスＢ１１）に基づいた、識別子の暗号化値である。上記カードは、次に、メッセージｍと、取得したばかりのＣを連結させる（ボックスＢ５）ことによって、メッセージｍ’を作成し、それから、例えば上述のＰＫＣＳ＃１標準を用いて、結果をメッセージｍ”へと変更する。最後に、上記カードは、Ｓ＝ｍ”ＳＫ ｍｏｄ ｎ（ボックスＢ６”）を、秘密署名鍵ＳＫに基づき計算する。（Ｓ，Ｃ）の組み合わせは、メッセージｍのグループ署名である。

表３に、第一の例にしたがって、グループＧにおいて、さまざまな当事者によって用いられるエンティティの要約を示す。

照合者２、６は、署名が確かにグループのメンバにより行なわれたものであることを照合するために、値ｎおよびＰＫのみを必要とする。照合者は、ｍ”＝Ｓ^ＰＫ ｍｏｄ ｎ（上述のＰＫＣＳ＃１標準を参照）を照合しさえすればよい。さらに、照合者は、Ｃを復号することはできないので（鍵Ｋを持っていないので）、どのメンバを取り扱っているを知ることはできない。

認証機関４が署名を開放したい場合、ｚ’、次にｚを見出すために、Ｃ^ｄ ｍｏｄ ｐを計算する（ｚとｚ’との間の変換には、乱数ｒの知識は不要であり、上述の標準によって全て記述されている。）
明らかに、第二の例もまた、第一の例において記述されたように、認証機関を２つに分けることが可能である。同様に、第二の例においても、分散鍵を個人データとして利用することができる。また、実施例１の変形として（図７参照）、識別子ｚを省略するために分散鍵を利用することができる。

以上から理解されるように、本発明は、計算のコストに関して注目すべき有利な点を有している。というのも、カード２６において必要なものは、暗号アルゴリズムおよび署名アルゴリズムのみであり、それらは共に、たった２つのモジュール化された指数しか要求しないからである。

本発明は、ハードウェア、暗号ソフトウェア、当事者間の通信、および応用分野に応じて、多様な変形が可能である。

メッセージは、適用された如何なるデバイスによって署名されてもよい。また、スマートカード技術を利用する必要は必ずしもなく、例えば、特定の携帯装置、個人用通信端末、携帯電話リソースなどでもよい。

さらに、本例において挙げられたアルゴリズムシステム（ＡＥＳおよびＲＳＡ）以外の、他のアルゴリズムシステムを想定することも可能である。

あるメンバＭおよびサービスプロバイダは、また、ローカル線、有線、無線、赤外線、またはその他の接続を介して通信を行なうことができる。

最後に、本例に挙げられた応用分野（電子マネーによるショッピング、販売行為）は、その他に可能な多数の応用分野の中の、単なる一例にすぎない。

オークションの状況におけるグループ暗号化の例を示す主要図である。 電子マネーによる購入の状況におけるグループ暗号化の例を示す主要図である。 本発明にしたがったメッセージの署名向けの、スマートカードを用いたトランザクションを表すために使用される図である。 本発明に係るグループ署名を作成するために使用可能なスマートカードにおける機能要素のブロック図である。 本発明に係るグループ署名を作成するための、スマートカードに含まれる機能要素を一般化して表したフローチャートである。 図５のフローチャートにおける特定要素についての、実施形態の第一例のフローチャートである。 第一の例とは異なる例のフローチャートである。 図５のフローチャートとは異なる特定要素についての、実施形態の第二例のフローチャートである。

Claims (17)

1. グループ（Ｇ）に所属するメンバ（Ｍ）によって作成されたメッセージ（ｍ）に署名するグループ署名ハードウェア支援機器（２６）であって、
   上記グループ署名ハードウェア支援機器（２６）は、少なくとも、
   上記メンバ（Ｍ）を識別する上記個人用データ（ｚ；Ｋｚ）を記憶する記憶手段と、
   上記個人用データ（ｚ；Ｋｚ）および認証機関（４）のみが有する復号鍵に対応する暗号鍵を用いて、上記認証機関（４）によってのみ復号可能な暗号文（Ｃ）を生成する暗号化手段（Ｂ３）と、
   上記グループのメンバすべてに共通の秘密鍵（ＳＫ）を用いて、上記メッセージ（ｍ）および上記暗号文（Ｃ）を含む組のグループ署名（Ｓ）を生成する署名手段（Ｂ６）と備えていることを特徴とするグループ署名ハードウェア支援機器（２６）。
2. 上記暗号化手段（Ｂ３）によって生成された暗号文（Ｃ）と、上記メッセージ（ｍ）とを連結して連結メッセージ（ｍ’）を生成する連結手段（Ｂ５）を備え、
   上記署名手段によって用いられる上記組は、上記連結メッセージ（ｍ’）であることを特徴とする請求項１に記載のグループ署名ハードウェア支援機器（２６）。
3. 上記個人用データが、上記メンバ（Ｍ）に特有の識別子（ｚ）であり、
   上記暗号鍵（Ｋ）は、上記グループ（Ｇ）のメンバすべてに共通であって、上記記憶手段に格納されており、
   上記暗号化手段（Ｂ３）は、上記認証機関によってのみ復号可能な暗号文（Ｃ）を生成するための上記暗号鍵（Ｋ）を用いて上記識別子（ｚ）を暗号化することを特徴とする請求項１または２に記載のグループ署名ハードウェア支援機器（２６）。
4. 上記暗号化手段（Ｂ３）は、上記個人用データ（ｚ；Ｋｚ）および乱数（ｒ）を用いて暗号文（Ｃ）を作成することを特徴とする請求項１または２に記載のグループ署名ハードウェア支援機器（２６）。
5. 上記個人用データが、グループ（Ｇ）の各メンバ（Ｍ）に特有の分散暗号鍵（Ｋｚ）であり、
   上記暗号化手段（Ｂ３）は、上記分散暗号鍵（Ｋｚ）を暗号鍵として用いることにより乱数（ｒ）を暗号化して、上記暗号文（Ｃ）を作成することを特徴とする請求項１または２に記載のグループ署名ハードウェア支援機器（２６）。
6. 上記暗号化手段（Ｂ３）が、秘密鍵暗号アルゴリズム、例えば、ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）として知られているアルゴリズムを用いることを特徴とする請求項１から５のいずれか１つに記載のグループ署名ハードウェア支援機器（２６）。
7. 上記暗号化手段（Ｂ３）が、公開鍵暗号アルゴリズム、例えば、ＲＳＡ（Ｒｉｖｅｓｔ，Ｓｈａｍｉｒ，Ａｄｌｅｍａｎ）として知られているアルゴリズムを用いることを特徴とする請求項１から５のいずれか１つに記載のグループ署名ハードウェア支援機器（２６）。
8. 上記署名手段（Ｂ６）が、秘密鍵署名アルゴリズム、例えば、ＲＳＡ（Ｒｉｖｅｓｔ，Ｓｈａｍｉｒ，Ａｄｌｅｍａｎ）として知られているアルゴリズムを用いることを特徴とする請求項１から７のいずれか１つに記載のグループ署名ハードウェア支援機器（２６）。
9. 上記署名アルゴリズムが、文献「ＲＳＡ暗号標準−ＲＳＡ研究所−草稿２−２００１年１月５日」において定義されているＰＫＣＳ＃１標準を含むＲＳＡ型であることを特徴とする請求項８に記載のグループ署名ハードウェア支援機器（２６）。
10. 当該グループ署名ハードウェア支援機器（２６）が、携帯可能な通信装置（２６）により構成されていることを特徴とする請求項１から９のいずれか１つに記載のグループ署名ハードウェア支援機器（２６）。
11. 当該グループ署名ハードウェア支援機器（２６）が、スマートカード（２６）により構成されていることを特徴とする請求項１０に記載のグループ署名ハードウェア支援機器（２６）。
12. グループ（Ｇ）に所属するメンバ（Ｍ）によって作成されたメッセージ（ｍ）にグループ署名をするための、請求項１から１１のいずれか１つに記載のグループ署名ハードウェア支援機器（２６）と、
    上記グループ署名ハードウェア支援機器（２６）から、少なくとも上記メッセージ（ｍ）および上記グループ署名（Ｓ）を受信し、上記グループ署名ハードウェア支援機器の上記署名手段によって上記グループ署名をするために用いられる秘密鍵であって、グループのメンバすべてに共通である該秘密鍵に対応する公開鍵を用いて、上記メンバ（Ｍ）を特定し得ることなく、上記グループ署名（Ｓ）から上記グループ（Ｇ）を識別する照合装置（２）とを少なくとも含むことを特徴とするグループ署名システム。
13. 上記暗号文（Ｃ）を作成するための上記グループ署名ハードウェア支援機器が備える上記暗号化手段によって用いられる暗号鍵に対応する復号鍵を所有し、上記グループ（Ｇ）の上記メンバ（Ｍ）を特定することが可能な認証機関（４）をさらに含むことを特徴とする請求項１２に記載のグループ署名システム。
14. グループ（Ｇ）署名（Ｓ）付きのメッセージ（ｍ）を送信する方法であって、
    請求項１２または１３に記載のグループ署名システムにおける上記グループ署名ハードウェア支援機器（２６）が、
    上記グループ署名ハードウェア支援機器（２６）の上記記憶手段に記憶された上記個人用データ（ｚ；Ｋｚ）を含めて、上記メッセージ（ｍ）の署名を、上記グループ（Ｇ）のメンバ（Ｍ）に共通する秘密鍵（ＳＫ）を用いて生成するステップと、
    メンバ証明書、またはそのような証明書を所有する証明などの、メンバ（Ｍ）が上記グループ（Ｇ）に所属している証明を、上記照合装置（２、６）に提示することなく、上記生成するステップにて生成された署名付きのメッセージ（ｍ）を上記照合装置（２、６）に転送するステップとを含むことを特徴とする、メッセージ（ｍ）を送信する方法。
15. メッセージのグループ署名と共に受信されたメッセージ（ｍ）を照合する方法であって、
    上記メッセージは、請求項１４に係る方法によって上記グループ署名ハードウェア支援機器（２６）から送信されたものであり、
    上記照合は、上記秘密鍵（ＳＫ）に対応する公開鍵を用いて、上記グループ署名システムの上記照合装置によってなされることを特徴とする、メッセージ（ｍ）を照合する方法。
16. 請求項１３に記載のグループ署名システムにおける上記グループ署名ハードウェア支援機器（２６）によって生成された署名（Ｓ）を開放する方法であって、
    上記認証機関（４）が、
    署名の前に、上記グループ（Ｇ）のメンバ（Ｍ）の個人情報と、メンバの入手可能な個人用データとの対応データを作成するステップと、
    署名が開放されるべきグループ署名ハードウェア支援機器（２６）から受信した上記個人用データを上記認証機関が所有する復号鍵を用いることによって復号するステップと、
    上記グループ（Ｇ）の上記メンバ（Ｍ）の個人情報に対応される復号された個人用データを作成するステップとを含むことを特徴とする、署名（Ｓ）を開放する方法。
17. 請求項１３に記載のグループ署名システムにおいて、グループに承認されたメンバ（Ｍ）に固有のグループ署名ハードウェア支援機器（２６）を準備する方法であって、
    上記認証機関（４）が、上記グループ署名ハードウェア支援機器（２６）を個別化するために用いられる個人用データ（ｚ；Ｋｚ）を生成し、上記個人用データを秘密署名鍵（ＳＫ）とともに上記グループ署名ハードウェア支援機器（２６）に登録するステップを含むことを特徴とする、グループ署名ハードウェア支援機器（２６）を準備する方法。

Images