JP2008512060A - 仮署名スキーム - Google Patents

Abstract

【課題】仮署名スキームの一部を実現する方法及び装置が開示されている。
【解決手段】一実施形態において、前記方法は、メッセージ上でオペレーションを行うことにより仮署名を生成する工程と、前記仮署名を完了してメッセージ上の最終署名を生成する工程とを含む。そのようなスキームは、サーバアシスト型署名スキーム、指定確認者署名スキーム、及び、ブラインド署名スキームに用いられてもよい。

Description

本願は、「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｐｒｏｖｉｓｉｏｎａｌ Ｓｉｇｎａｔｕｒｅ Ｓｃｈｅｍｅｓ， Ｉｎｃｌｕｄｉｎｇ Ｓｅｒｖｅｒ-Ａｓｓｉｓｔｅｄ， Ｄｅｓｉｇｎａｔｅｄ Ｃｏｎｆｏｒｍｅｒ， ａｎｄ Ｂｌｉｎｄ Ｓｉｇｎａｔｕｒｅ Ｓｃｈｅｍｅｓ」と題され、２００４年８月２７日に出願された、対応する米国仮特許出願第６０/６０５,２０６号に基づく優先権を主張する。

本発明は、暗号技術の分野に関する。特に、本発明は、サーバアシスト型デジタル署名を構築するための仮署名、指定確認者署名、及びブラインド署名スキームを含む仮署名スキームに関する。

一般的なデジタル署名の分野で最も普及している署名スキームは、ＲＳＡ及び楕円曲線上のＵＳデジタル署名アルゴリズム（ＥＣＤＳＡ）である。適当なパラメータを有するＲＳＡアルゴリズムは、非常に高速で検証することができるが、署名を生成するのは遅い。また、ＲＳＡにおける署名は、少なくとも１キロバイトの大きさであるため、ＳＩＭカードや製品登録用としては不向きとなっている。

「オンライン／オフライン」のデジタル署名用のスキームが、Ｓｈａｍｉｒ及びＴａｕｍａｎによって提案されている（非特許文献１参照）。彼らのスキームは、カメレオンハッシュ関数を利用し、仮署名を効率的に生成するために用いることができる「ハッシュ-署名-切り換え」パラダイムを導入している。しかしながら、彼らは、彼らのスキームを、サーバアシスト方式で処理を行う場合に応用することについて考えなかった。
Ｓｈａｍｉｒ及びＴａｕｍａｎ著、「Ｉｍｐｒｏｖｅｄ Ｏｎｌｉｎｅ-Ｏｆｆｌｉｎｅ Ｓｉｇｎａｔｕｒｅ Ｓｃｈｅｍｅ」、ＣＲＹＰＴＯ２００１ Ｐ. Ｎｇｕｙｅｎ及びＪ. Ｓｔｅｒｎ著、「Ｔｈｅ Ｂｅｇｕｉｎ-Ｑｕｉｓｑｕａｔｅｒ Ｓｅｒｖｅｒ-Ａｉｄｅｄ ＲＳＡ Ｐｒｏｔｏｃｏｌ ｆｒｏｍ Ｃｒｙｐｔ’９５ ｉｓ ｎｏｔ ｓｅｃｕｒｅ」、Ａｓｉａｃｒｙｐｔ ９５、 Ｐ. Ｂｅｇｕｉｎ及びＪ. Ｊ. Ｑｕｉｓｑｕａｔｅｒ著、「Ｆａｓｔ ｓｅｒｖｅｒ-ａｉｄｅｄ ＲＳＡ ｓｉｇｎａｔｕｒｅｓ ｓｅｃｕｒｅ ａｇａｉｎｓｔ ａｃｔｉｖｅ ａｔｔａｃｋｓ」、ＣＲＹＰＴ １９９５ Ｍ. Ｊａｋｏｂｓｓｏｎ及びＳ. Ｗｅｔｚｅｌ著、「Ｓｅｃｕｒｅ Ｓｅｒｖｅｒ-Ａｉｄｅｄ Ｓｉｇｎａｔｕｒｅ Ｇｅｎｅｒａｔｉｏｎ」、Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｗｏｒｋｓｈｏｐ ｏｎ Ｐｒａｃｔｉｃｅ ａｎｄ Ｔｈｅｏｒｙ ｉｎ Ｐｕｂｌｉｃ Ｋｅｙ Ｃｒｙｐｔｏｇｒａｐｈｙ、２００１年 Ｂｉｃａｃｋｉ及びＢａｙａｌ著、「Ｓｅｒｖｅｒ Ａｓｓｉｓｔｅｄ Ｓｉｇｎａｔｕｒｅｓ Ｒｅｖｉｓｉｔｅｄ」、ＲＳＡ Ｃｒｙｐｔｏｇｒａｐｈｅｒｓ’ Ｔｒａｃｋ ２００３ Ｖ. Ｇｏｙａｌ著、「Ｍｏｒｅ Ｅｆｆｉｃｉｅｎｔ Ｓｅｒｖｅｒ Ａｓｓｉｓｔｅｄ Ｓｉｇｎａｔｕｒｅｓ」、Ｃｒｙｐｔｏｇｒａｐｈｙ Ｅｐｒｉｎｔ Ａｒｃｈｉｖｅ、２００４年 Ｓ. Ｇｏｌｄｗａｓｓｅｒ及びＥ. Ｗａｉｓｂａｒｄ著、「Ｄｉｇｉｔａｌ Ｓｉｇｎａｔｕｒｅ Ｓｃｈｅｍｅ ｉｎｔｏ Ｄｅｓｉｇｎａｔｅｄ Ｃｏｎｆｉｒｍｅｒ Ｓｉｇｎａｔｕｒｅ Ｓｃｈｅｍｅｓ」、２００４年

サーバアシスト型のデジタル署名では、別のサーバを利用して署名に要求される計算処理及び通信のオーバーヘッドを減らすことが望ましい。これは、サーバアシスト型署名（ＳＡＳ：Ｓｅｒｖｅｒ Ａｓｓｉｓｔｅｄ Ｓｉｇｎａｔｕｒｅｓ）として公知である。もちろん、効率的なデジタル署名が望まれ、第三者が利用可能であるいくつかのシナリオが想定可能である。署名者の通信及び計算を減らすという問題は、最も現実的な関心事である。なぜならば、それによって、より効率的なエネルギー利用が可能となり、移動通信機器の寿命が延びるからである。先行して提案されたＳＡＳの多くは、安全でないことが分かっているし、署名ごとに大容量データの通信が署名者に要求されたり、クライアントごとに大容量の状況を記憶することがサーバに要求されたりするものもある。

ＳＡＳの応用例に、製品登録がある。署名者は、認証鍵をソフトウェアや新規に購入した電話機に配布したいと希望しているかもしれない。検証者は、サーバに対して接続性を有すると考えられるソフトウェア自体を含む。認証鍵は、ソフトウェア自体の署名及びシリアル番号によって構成されている。さらに、デジタル署名は、ソフトウェアと共に出荷される用紙又はラベル上にタイプされる。

ＳＡＳの応用の他の例として、ＵＩＭカードがある。ＵＩＭカードは、プロセッサ及び小容量のストレージを含むスマートカードである。ＵＩＭカードは、電話から電話へ又は電話からパソコンへ等というように機器から機器へ移動する際に、ユーザに、単一のアイデンティティを保持させることができる。また、ＵＩＭカードは、ＲＳＡを使用してユーザをウェブサイトに対して認証する「ＦｉｒｓｔＰａｓｓ ＳＳＬのクライアント認証」において用いられている。現在のＵＩＭカードには、ＲＳＡデジタル署名を実行するための特殊用途プロセッサが必要であり、署名ごとに１/２秒程かかる。さらに、ＲＳＡ秘密鍵は、ＵＩＭカード上に１キロバイトの容量をとり、そのため、カード上の鍵の数は、５つに制限される。

サーバアシスト型署名の問題に対する従来の解決策には、いくつかの欠点があった。Ｂｅｇｕｉｎ及びＱｕｉｓｑｕａｔｅｒによるスキームは、Ｎｇｕｙｅｎ及びＳｔｅｒｎによって安全でないことが示されている。そのため、実用向きとは考えられない（詳細については、非特許文献２及び非特許文献３参照）。Ｊａｋｏｂｓｓｏｎ及びＷｅｔｚｅｌによる方法は安全そうであるが、その使用は、ＤＳＡ及びＥＣＤＳＡのみに限定されている。なぜならば、署名は、少なくとも３２０ビットの大きさがあるからである（非特許文献４参照）。Ｂｉｃａｃｋｉ及びＢａｙａｌによるスキームでは、サーバは、署名ごとの署名者当たり、５キロバイトを記憶するように要求される（非特許文献５参照）。例えば、署名者当たり、１日に１０個の署名を生成する８０００万人の署名者がいたとすると、これには、大まかに見積もって、一日当たり、３．７テラバイトを記憶しなければならない。Ｇｏｙａｌのスキームは、この問題に取り組んでおり、署名当たり、４８０バイトのサーバストレージを必要としている（非特許文献６参照）。８０００万人の署名者で、１日当たり１０個の署名があれば、このスキームでは、１日に、大まかに見積もっても、３５７ギガバイトが必要である。

さらに悪いことに、両方のスキームにおいて、サーバが記憶しなければならないデータ量は、限界なく増加する。これは、サーバが、不正行為を働いたとして、ある署名者から告訴された場合に備えて、データが保持されているからである。そのため、サーバが告訴される可能性がないと確信できるまで、実際に、何カ月も、又は、何年も、データを保持しなければならない。「時効」を1年間と仮定すると、Ｇｏｙａｌのスキームでは、１２７テラバイトのサーバストレージが必要となる。何れかのデータが欠けていたり、署名に不備があったりした場合、サーバは、自らが正しく行動したことを証明できなくなってしまう。

Ｇｏｙａｌ及びＢｉｃａｃｋｉ-Ｂａｙａｌのスキーム双方における他の欠点は、署名者が、１つ１つのメッセージごとに、１回限りの署名に対する公開鍵をサーバに送信しなければならないことである。Ｇｏｙａｌの論文で提案された実施形態では、署名ごとの通信に２６キロバイトが要求される。この容量の大きい通信は、製品登録への応用を不可能なものにしている。

署名の他の種類として、「指定確認者署名（ｄｅｓｉｇｎａｔｅｄ ｃｏｎｆｉｒｍｅｒ ｓｉｇｎａｔｕｒｅ）がある。指定確認者デジタル署名では、メッセージ上の署名について、特別な「指定確認者」の支援なしで検証することはできない。署名者は、署名が生成されると、指定確認者を選択する。指定確認者は、署名をとり、署名が本物であるかを確認、又は、署名者によって実際に生成されたものでない署名を否認するが、かかる指定確認者は、新規の署名を生成できない。また、かかる指定確認者は、署名を、誰もが検証できる通常の署名に変換することもできる。

指定確認者を使用する応用例に、電子契約の署名がある。求職者及び雇用主になる可能性のある者が、雇用契約の交渉を物理的に同じ部屋に居合わせることなく行うことができる。雇用主は、従業員に他の雇用主候補との取引材料として契約書を使って欲しくないと考えるだろう。そのため、雇用主は、指定確認者の署名を用いて署名することができ、裁判所を、かかる指定確認者として指定することができる。争議が生じた場合、そのようにして署名を検証することができるが、その一方で、他の雇用主が署名を検証することはできない。

指定確認者を利用する応用例には、ソフトウェアパッチの検証がある。ソフトウェアのベンダーは、ソフトウェアパッチの使用を、ソフトウェアを正規に購入したユーザだけに制限したいと考えている。この制限を実現する１つの方法として、指定確認者署名スキームでパッチに署名し、登録ユーザだけに確認したことを知らせる方法がある。未登録のユーザは、署名を検証することができず、危殆化したソフトウェアパッチをインストールするリスクを負うことになる。

最近では、指定確認者デジタル署名を実装するには、ＲＳＡ等のアルゴリズムの特殊用途プロパティを用いる。これらの特定のアルゴリズムが安全でないと分かった場合、これらのスキームも安全ではない。Ｇｏｌｄｗａｓｓｅｒ及びＷａｉｓｂａｒｄは、いくつかの既存の署名スキームを、指定確認者署名スキームに変換する方法を開示している（非特許文献７参照）。

他の署名の種類として、「ブラインド署名（ｂｌｉｎｄ ｓｉｇｎａｔｕｒｅ）」がある。ブラインド署名では、署名者は、メッセージＭの「ブラインドされた」バージョンＸに署名する。ブラインドされたバージョンＸは、ブラインド要素ｒを用いて生成される。「ブラインダ（ｂｌｉｎｄｅｒ）」は、メッセージＭを署名者に明らかにすることなく、Ｍ上の署名を取得したいと考えている。これは、署名者に対して、ＭのブラインドされたバージョンであるメッセージＸに署名するようにブラインドした状態で依頼することで、実現できる。署名後、署名は、ブラインド要素を使ってＭ上の署名を取得するために「ブラインドをはずす」ことができる。ブラインド要素なしでは、ブラインドされたメッセージＸ上の署名をブラインドされていないメッセージＭとリンクさせることは不可能である。Ｘ上の署名から、ブラインダは、Ｍ上の署名を回復することができる。Ｘ上の署名は、「仮署名」であり、また、Ｍ上の署名は、「最終署名」である。

ブラインド署名の応用例として、リンクができない電子キャッシュトークンがある。銀行でさえ異なる取引を追跡できないことを保証することで、ユーザのプライバシーを強化することが目的である。ユーザは、ある額面に対してトークンを生成し、そのトークンをブラインドする。銀行は、ブランドされたトークンに署名し、それをユーザに戻す。そして、ユーザは、ブラインドをはずし、トークン上の銀行の署名を取得する。トークンと、トークン上の銀行の署名により、ユーザは、金融取引に参加することができる。なぜならば、第三者が銀行の署名を確認することができるからである。一方、銀行は、ブラインドされたトークンに署名したため、トークンをユーザまで追跡することはできず、ユーザに匿名性を与える。不正行為を行うユーザを防ぐために、ユーザが、１００以上の同じ額面のトークンを生成し、銀行が、最後のトークンに署名する前に、１００のトークンのうちランダムに選択した９９のトークンを見せてもらうように依頼する「切断選択法（ｃｕｔ-ａｎｄ-ｃｈｏｏｓｅ）」を用いてもよい。

仮署名スキームの一部を実現する方法及び装置が開示されている。一実施形態において、かかる方法は、メッセージ上でオペレーションを行うことにより仮署名を生成する工程と、仮署名を完了してメッセージ上の最終署名を生成する工程とを有する。そのようなスキームは、サーバアシスト型署名スキーム、指定確認者署名スキーム、及びブラインド署名スキームに用いられてもよい。

本発明は、以下に詳細な説明及び本発明の様々な実施形態の添付図からより完全に理解できるであろう。しかし、それらは、本発明を特定の実施形態に限定するためのものあると考えられるべきでなく、説明と理解のためだけのものであると考えられるべきである。

仮署名スキームを説明する。特に、署名者は、第三者のサーバによって「最終署名」に変換される「仮署名」を生成する。これらの最終署名は、検証者によって検証することができる。一実施形態では、第三者のサーバが、危殆化している、又は、不具合を起こしている可能性を相殺するために、サーバ自体は、文書に署名できず、署名者によって生成された仮署名を変換できるだけである。一実施形態では、サーバは、ほとんど計算を行わず、大勢の署名者を取り扱うことができるように、署名ごとに小さい容量のデータだけを記憶する。

仮署名スキームには、サーバアシスト型署名スキーム、指定確認者署名スキーム、及びブラインド要素スキームが含まれる。一実施形態では、サーバアシスト型署名スキームは、製品登録や装置の計算負荷軽減用に使用されている。一実施形態では、指定確認者署名スキームは、デジタル契約の公正な取引に使用されている。一実施形態では、ブラインド署名スキームは、匿名の電子キャッシュを生成するために使用されている。

本発明の複数の実施形態には、署名者やサーバや検証者の計算要件、及び、これらが通信するチャネルの帯域要件の点で、効率的で安全なサーバアシスト型署名用スキームが含まれる。本発明の一実施形態では、かかるスキームが、署名ごとに１６０バイトだけという署名者の通信の複雑度を有する。かかる通信の複雑度は、以前のＳＡＳスキームより大幅に改善された水準である
一実施形態において、本明細書においてＵＩＭカードを使用するとして説明されているＳＡＳ法では、秘密鍵ごとに必要なスペースは、１２８ビットだけであるため、特殊用途の共同プロセッサを使用しなくても高速署名が可能となっている。

以下の説明において、本発明をより完全に説明するために、多くの詳細を記載する。しかしながら、当業者においては、本発明は、これらの特定の詳細なしで実施することが可能であることが自明であろう。また、公知の構造及び装置については、本発明が不明瞭になることを避けるために、詳細を示すのではなくブロック図の形式で示した。

以下に続く詳細な説明のいくつかの箇所は、アルゴリズムやコンピュータメモリ内のデータビットにおけるオペレーションの記号による表現で表されている。これらのアルゴリズム的な説明及び表現方法は、データ処理技術の分野の技術者によって利用される手段であり、彼らの仕事内容を他の技術者に最も効果的に伝えるものである。ここでのアルゴリズムは、一般的に、所望する結果へ導く自己無撞着一連のステップであると考えられている。これらのステップには、物理量の物理的な操作が必要である。通常、必ず必要であるという訳ではないが、これらの量は、記憶、転送、結合、比較が可能、又は、その他の操作が可能な電気的、又は、磁気的信号の形式をとる。主に共同利用のために、これらの信号をビット、値、エレメント、シンボル、特徴、用語、数などとして参照することが時々便利であると証明されている。

しかしながら、これら全ての又は同様の用語が、適当な物理量に関連付けられ、これらの物理量に適用した便利なラベルに過ぎないことを留意する必要がある。以下の議論から明らかなように、特別に言及しない限り、明細書を通して、「処理する（ｐｒｏｃｅｓｓｉｎｇ）」、「計算する（ｃｏｍｐｕｔｉｎｇ）」、「計算する（ｃａｌｃｕｌａｔｉｎｇ）」、「決定する（ｄｅｔｅｒｍｉｎｇ）」、「表示する（ｄｉｓｐｌａｙｉｎｇ）」等の用語を利用する議論では、コンピュータシステムのレジストリやメモリ内の物理的（電気的）量として表されるデータを操作し、コンピュータシステムメモリ、レジストリ、他の情報ストレージ、或いは、通信又は表示装置内の物理量として同様に表される他のデータに変換するコンピュータシステムのアクションやプロセス、又は、同様の電子計算装置を意味すると考えられる。

本発明は、本明細書においてオペレーションを実行する装置にも関する。この装置は、要求される目的のために特別に構成されてもよいし、コンピュータに記憶されたコンピュータプログラムによって選択的に稼働させたり、又は、再構築されたりした汎用コンピュータによって構成してもよい。限定される訳ではないが、フロッピィディスク、光学ディスク、ＣＤ−ＲＯＭ、及び光磁気ディスクなどのコンピュータで読み取り可能な記憶媒体、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気、又は、光学カード、又は、電気的命令を記憶するのに適している全ての種類の媒体、及びコンピュータシステムバスに連結されたそれぞれに、そのようなコンピュータプログラムを記憶してもよい。

本明細書に表すアルゴリズムや表示は、本質的に、特定のコンピュータ、又は、その他の装置に関するものではない。様々な汎用コンピュータシステムは、本明細書の教示に従ってプログラムを使って使用しても、又は、必要な方法のステップを実行するためにより特定した装置を構成することが都合よいことを証明してもよい。様々なこれらのシステムの必要な構造は以下の説明から明らかとなる。また、本発明の説明に特定のプログラム言語を参照することはしないが、様々なプログラム言語を、本明細書に説明したように、本発明の教示を実施するために使用してもよいことが理解されよう。

機械で読み取り可能な媒体には、情報を機械（例えば、コンピュータ）で読み取り可能な形式で記憶したり、送信したりする、どのメカニズムも含まれる。例えば、機械で読み取り可能な媒体には、読み取り専用メモリ（「ＲＯＭ」）、ランダムアクセスメモリ（「ＲＡＭ」）、磁気ディスクストレージ媒体、光学ストレージ媒体、フラッシュメモリ装置、電気的、光学的、音響的、又は、他の形式の伝搬シグナル（例えば、キャリアウェーブ、赤外信号、デジタル信号等）等が含まれる。

＜定義及び仮定＞
本明細書の目的にとって、関数ｆ（ｎ）は、多項式関数ｑ（ｎ）に対して、全てのｎ＞ｎ_０に対してｆ（ｎ）＜１/ｑ（ｎ）となるような値ｎ_０が存在する場合、無視してもよい。そのような無視可能な関数の例としては、ｆ（ｎ）＝１/２^ｎがある。

ａ及びｂが、ａ≦ｂである２つの整数である場合、［ａ，ｂ］は、ａ以上ｂ以下の間の整数の集合を表す。すなわち、［ａ，ｂ］＝｛ｃ∈Ｚ｜ａ≦ｃ≦ｂ｝である。

Ｓが、エレメントｓの集合であり、Ｄが、Ｓにおけるサンプル可能な確率分布である場合、分布Ｄに従って、Ｓからエレメントｓを取るプロセスは、

で表される。

多くの暗号技術の安全性が、ある計算処理が難しくなるような仮定を作ることに依拠することは、当業者には公知である。例えば、特定の番号を素因数に効率的に分解することが難しい限り、暗号システムが安全であることを証明しようとすることができる。「計算による（ｃｏｍｐｕｔａｔｉｏｎａｌ）」という用語を、暗号技術のこのクラスを確認するために用いられることがよくある。一実施形態において、本明細書に説明した本発明の実施形態の安全性を証明することに関する仮定の集合を以下に説明する。

＜離散対数の仮定＞
群Ｇにおける離散対数の仮定は、群のジェネレータｇが与えられており、値ｙ＝ｇ^ｘが与えられており、計算によって、ｘを得ることが困難であることを示している。我々は、楕円曲線の有理点の群に特別な関心を寄せている。離散対数問題を定義する標準的な数学的群を構成する。そのような楕円曲線群の位数ｑに対して、離散対数を見つけるための公知の最良の手法では、時間

が必要とされる。

＜カメレオンハッシュ関数＞
カメレオンハッシュ関数は、公開鍵ＰＫ_ｃｈ及び確率的多項式の時間アルゴリズムＧ（１^ｋ）によって生成される秘密鍵ＳＫ_ｃｈによって定義される関数ＣＨ（ｍ，ｒ）である。公開鍵ＰＫ_ｃｈが与えられているので、ＣＨ（ｍ，ｒ）を評価することは容易である。秘密鍵無しでは、ＣＨ（ｍ，ｒ）＝ＣＨ（ｍ’，ｒ’）となるようなタプル（ｍ，ｍ’，ｒ，ｒ’）を見つけることは困難である。一方、秘密鍵が有れば、ｍ，ｍ’及びｒが与えられているので、ＣＨ（ｍ，ｒ）＝ＣＨ（ｍ’，ｒ’）となるようなｒ’を見つけることは容易である。

カメレオンハッシュ関数の特定のファミリは、離散対数の仮定が以下のように保持する位数ｑの群Ｇに対して、定義されている。秘密鍵ＳＫ_ｃｈは、

における均一なランダム値ｘであるが、公開鍵は、値ｈ＝ｇ^ｘである。ＣＨ（ｍ，ｒ）が、ＣＨ（ｍ，ｒ）＝ｇ^ｘｈ^ｒとなるように定義されている。特定群の事例について、Ｇは、適切に選択された楕円曲線上の点の群である。パラメータを適切に選択することによって、出力の長さが１６０ビットのカメレオンハッシュを取得する。本明細書に説明した本発明の実施形態には、このカメレオンハッシュ関数を利用することが含まれるが、他のカメレオンハッシュ関数を用いてもよいことが、当業者には明らかであろう。

＜疑似ランダムジェネレータ＞
疑似ランダムジェネレータＧは、入力としてビットの短いランダムシードを取り、ｋビットの文字列を出力する。ここで、ｋ＞ｓとする。出力文字列は、ランダム文字列から区別することができないという意味において疑似ランダムである。

＜ビットコミットメントスキーム＞
ビットコミットメントスキームＣ（Ｍ，ｒ）は、統計学的に隠れており、計算により結合しているというプロパティを満たす。「統計学的に隠す」とは、無視できる確率を除いて、ｒを知らなければ、Ｃ（Ｍ，ｒ）からＭを回復することができる敵は、たとえ、どんなに強い敵であっても、いないということである。「計算により結合している」とは、コミットメントＣ（Ｍ，ｒ）は、確率的な多項式の時間アルゴリズムによって、値Ｍ’≠Ｍに開くことはできないということである。

＜概要＞
図１は、仮署名プロセスの一実施形態の流れ図である。ハードウェア（例えば、回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、その両方の組み合わせを含んでもよい処理ロジックによって、このプロセスを実行してもよい。

図１を参照すると、メッセージ上のオペレーションを実行して仮署名を生成する処理ロジックによって始まる（処理ブロック１０１）。次に、処理ロジックは、仮署名を完成させ、メッセージ上に最終署名を生成する（処理ブロック１０２）。処理ブロック１０１及び処理ブロック１０２は、共に、１つ又は２つの秘密鍵を使用して実行される。最終署名が完了してから、処理ロジックは、最終署名を検証する（処理ブロック１０３）。

図２は、検証者プロセスの一実施形態の流れ図である。図２を参照すると、本明細書に説明する仮署名プロセスを利用することで生成された署名は、かかる署名、メッセージｍ及び公開鍵を検証者に入力し、かかる署名が有効かどうかの表示（例えば、Ｙｅｓ/Ｎｏ）を受け取ることによって検証される。

本明細書に説明する仮署名は、サーバアシスト型署名スキーム、指定確認者署名スキーム、及びブラインド署名スキームに適用されてもよい。これらのスキームの実施形態を以下に説明する。

＜サーバアシスト型署名のためのシステム例＞
一実施形態において、署名者と検証者とサーバとの間でデータを通信するシステムは、サーバアシスト型の署名を提供する。署名者は、仮署名を生成し、生成した仮署名を通信ネットワーク上で検証者に送信する。検証者は、仮署名を通信ネットワーク上でサーバに送信する。その後、検証者は、サーバから最終署名を受信し、結果としての最終署名を検証する。サーバは、仮署名を最終署名に変換し、その最終署名を通信ネットワーク上で検証者に送信する。

署名者、検証者及びサーバのそれぞれには、ハードウェア（例えば、回路、専用ロジック等）、ソフトウェア装置（例えば、汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、その両方の組み合わせを含んでもよい処理ロジックを有するコンポーネントが含まれている。図３は、そのようなコンポーネントの一実施形態を図示している。図３を参照すると、コンポーネント３００には、プロセッサ３０１、メモリ３０２、ネットワークインターフェイス３０３が含まれている。プロセッサ３０１は、メモリ３０２及びネットワークインターフェイス３０３に連結される。

署名者は、処理ロジックを有するプロセッサロジック３０１を含む。これにより、署名者は、外部ネットワークインターフェイス３０３を通してメッセージを受け取り、仮署名を生成する方法を適用し、その結果、メッセージ上の仮署名を取得する。

検証者は、処理ロジックを有するプロセッサ３０１を含む。これにより、署名者は、外部ネットワークインターフェイス３０３を通してメッセージ及び最終署名を受信し、署名を検証する方法を適用し、その結果、表示された署名者にそのメッセージが由来しているという確信を得る。

サーバは、処理ロジックを有するプロセッサ３０１を含む。これにより、サーバは、ネットワークリクエストの一部としての入力として、外部ネットワークインターフェイス３０３を通して仮署名を受信する。そして、サーバは、仮署名を最終署名に変換する方法によって与えられた出力をネットワーク３０４に送信する。

図５は、サーバアシスト型デジタル署名技術用の鍵生成プロセスの一実施形態の流れ図である。プロセスは、ハードウェア（例えば、回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、その両方の組み合わせを含んでもよい処理ロジックによって実施されてもよい。

図５を参照すると、プロセスは、セキュリティパラメータｋ及びいくつかの署名Ｓ（処理ブロック５０１）を特定する処理ロジックにより開始される。次に、処理ロジックは、ランダムな１６０ビットの楕円曲線を、ジェネレータ点ｇと共に生成する（処理ブロック５０２）。ジェネレータを選択する標準的な技術がある。例えば、１つの手法としては、ランダムエレメントをとり、偶然にも有効なジェネレータでないかどうかを確認する。一実施形態において、この曲線及びジェネレータは、システムにおける全てのエンティティに対して使用する。本明細書の目的として、及び、慣習との決別として、楕円曲線上の点の群は、乗法的な群として表記されている。そのような表記を、どのように標準付加表記へ変換するのかについては、当業者には明らかであろう。なお、他の楕円曲線を用いることもできることに留意されたい（例えば、１６１ビットの楕円曲線、１０２４ビットの有限フィールド）。一般的には、スキームは、離散対数が難しい、どの代数群も用いることができ、ジェネレータｇは、その群に由来しなければならない。

曲線及びジェネレータが生成された後、処理ブロックは、ランダムに、２つのシードｓ１及びシードｓ２を均一に選択する（処理ブロック５０３）。次に、処理ロジックは、１≦ｉ≦Ｓである場合、ランダムシードｓ_１でシードされるＰＲＧの連続出力として、値ｘ_ｉの数列を生成し（処理ブロック５０４）、１≦ｉ≦Ｓとである場合、ランダムシードｓ_２でシードされるＰＲＧの連続出力として、値ｃ_ｉの数列を生成する（処理ブロック５０５）。一旦、２つの数列が生成されると、処理ロジックは、１≦ｉ≦Ｓである場合、値ｈ_ｉ＝ｇ^ｘｉの数列を計算する（処理ブロック５０６）。そして、処理ロジックは、標準署名スキーム用の鍵のペア（ＳＫ，ＰＫ）を計算する（処理ブロック５０７）。秘密鍵ＳＫは、Ｓ個の署名

の数列を生成するために用いられる。

一旦計算が終了すると、処理ロジックは、シードｓ_１及びシードｓ_２を署名者に送信し（処理ブロック５０８）、値ｈ_ｉ及び値Ｓｉｇ_ｉをサーバに送信する（処理ブロック５０９）。また、処理ロジックは、署名者の公開鍵として、公開鍵ＰＫを、ｇ及びサーバのアドレスと共に発行する。

図６は、サーバアシスト型署名スキームに用いられる仮署名生成プロセスの一実施形態の流れ図である。プロセスは、ハードウェア（例えば、回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、その両方の組み合わせを含んでもよい処理ロジックを含んでもよい処理ロジックによって実行されてもよい。一実施形態において、処理ロジックは、署名者の一部である。

図６を参照すると、かかるプロセスは、秘密シードｓ１を用いて値ｘ_ｉを生成する処理ロジックによって始まり（処理ブロック６０１）、秘密シードｓ２を用いて値ｃ_ｉを生成する（処理ブロック６０２）。次に、処理ロジックは、

となるようなｒ_ｉを見つけ（処理ブロック６０３）、ｒ_ｉをメッセージｍ_ｉの仮署名として出力する（処理ブロック６０４）。

図７は、サーバアシスト型署名スキームの仮署名終了プロセスの一実施形態の流れ図である。プロセスは、ハードウェア（例えば、回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステムで走っているようなもの、又は、専用マシーン等）、又は、その組み合わせを含んでもよい処理ロジックにより実行されてもよい。一実施形態において、処理ロジックは、サーバの一部である。

図７を参照すると、プロセスは、仮署名ｒ_ｉのインデックスｉを受信する処理ロジックにより開始される（処理ブロック７０１）。次に、処理ロジックは、署名

及びｈ_ｉに対応する数列の値を調べて戻し（処理ブロック７０２）、最終署名

を出力する（処理ブロック７０３）。

図８は、サーバアシスト型署名スキーム用の最終署名の検証プロセスの一実施形態の流れ図である。プロセスは、ハードウェア（例えば、回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、その両方の組み合わせを含んでもよい処理ロジックによって開始されてもよい。一実施形態において、処理ロジックは、検証者の一部である。

図８を参照すると、プロセスは、

を計算する処理ロジックにより開始され（処理ブロック８０１）、Ｖ_ＰＫ（Ｓｉｎｇ（ｇ_ｉｈ_ｉ））＝１を確認することで署名を検証する（処理ブロック８０２）。次に、処理ロジックは、かかる確認が取れた場合、及び、かかる確認が取れた場合のみに有効であるとして署名を受け付ける（処理ブロック８０３）。

或いは、サーバアシスト型署名スキームは、「ハッシュ-署名-切り換え」パラダイムを用いて選ばれたメッセージ攻撃下に存在する偽造に対して安全な基礎となる署名スキームを変換する、サーバアシスト型の１回だけの署名スキームと見なすこともできる。既存の署名スキーム（Ｇｅｎ，Ｓｉｇ，Ｖｅｒ）は、適応性のある選ばれたメッセージの攻撃下に存在する偽造に対して安全であり、合計Ｓ個の署名が署名されると考えられている。

１．鍵生成： まず、基礎となる署名スキームに対して、鍵ペアＰＫ_ｓｉｇ及びＳＫ_ｓｉｇを生成する。そして、シードｓ_１を有するＰＲＧを用いて、ｉに対して１からＳまでのカメレオンハッシュ鍵ペア

の数列を生成する。最後に、シードｓ_２及びシードｓ_３を用いて、疑似ランダム値ｖ_１、・・・、ｖ_ｓ、及び、疑似ランダム値ｗ_１、・・・、ｗ_ｓを生成する。変数ｃ_ｉは、ｃ_ｉ＝ＣＨ_ｉ（ｗ_ｉ，ｖ_ｉ）、すなわち、カメレオンハッシュ鍵

下の（ｗ_ｉ，ｖ_ｉ）のカメレオンハッシュとなるように定義されている。ＳＫ_ｐｒｏｖは、シードｓ_１及びシードｓ_２からなり、一方、ＳＫ_ｃｏｍｐ値は、

からなる。公開鍵ＰＫは、ＰＫ_ｓｉｇ及びサーバのアドレスからなる。

２．ＰｒｏｖＳｉｇｎ： 次の値ｉのために、（Ｍ，ｉ）を入力し、ｓ_１を用いて、

を計算し、ｓ_２を用いて、ｖ_ｉを計算し、ｓ_３を用いて、ｗ_ｉを計算する。そして、ＣＨ_ｉ（Ｍ_ｉ，ｒ_ｉ）＝ＣＨ_i（ｖ_i,ｗ_i）となるようなｒ_ｉを計算する。ｒ_ｉを、Ｍ上の仮署名として戻す。値ｉを使用済みとして印を付ける。

３．完了： 入力（±，ｉ）において、

を戻す。そして、最終署名は、

である。

４．検証：

を入力し、

の場合のみ、署名を有効として受け付ける。

終了オペレーションであるＳＫ_ｃｏｍｐ用の「秘密鍵」全体を、敵に最終署名を偽造させることなく明らかにすることができることに留意されたい。従って、このサーバアシスト型署名スキームにおけるサーバは、攻撃的に複製されてもよい。さらに、サーバは、計算を実行せず、単に、静的な読み取り専用値ＰＫ_ｃｈ及びＳｉｇ（ｃ，ＰＫ_ｃｈ）を戻すだけである。

一実施形態において、署名者と検証者とサーバアシスト型デジタル署名を行うサーバとの間でデータ通信を行うためのシステムには、仮署名を生成可能なクライアントコンポーネント、仮署名を終了して最終署名を生成することが可能なサーバコンポーネント、及び、最終署名を検証可能な検証コンポーネントが含まれる。

一実施形態において、サーバアシスト型署名スキームを実行する署名者、検証者及びサーバのそれぞれは、ハードウェア装置（例えば、回路、専用ロジック等）、ソフトウェア装置（汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、処理ロジックを実行可能な、その両方の組み合わせであってもよい。これらのコンポーネントのそれぞれは、図３に示すコンポーネントとして実装されてもよい。サーバアシスト型の署名者は、仮署名のリクエストを受信するために外部ネットワークインターフェイスと、仮署名を生成して外部ネットワークを介して仮署名を依頼者に戻すために外部ネットワークインターフェイス及びメモリに連結されているプロセッサとを用いる。サーバアシスト型の署名検証者コンポーネントは、外部ネットワークインターフェイスを使って最終署名を受信する。サーバアシスト型署名サーバコンポーネントは、仮署名を受信するために外部ネットワークインターフェイスと、サーバアシスト型署名スキームの完了した最終署名をネットワークに送信するために外部ネットワークインターフェイス及びメモリに連結されているプロセッサとを用いる。

サーバアシスト型署名スキームの一実施形態におけるカメレオン関数は、ＣＨ（ｍ，ｒ）＝ｇ^ｘｈ^ｒである。そのような場合、署名者ストレージは、以下の説明に用いる変数「ｉ」を表すために、１２８ビットの長さのシードｓ及び２０ビットの長さのカウンタのみを記憶する必要がある。よって、署名者ストレージの合計は、署名の数に関係なく１４８ビットである。ＲＳＡのような最新の公開鍵署名スキームでは、もっと大きいサイズの秘密鍵が要求されることに留意されたい。署名者の計算に関しては、署名者は、ＰＲＧを一定の回数評価し、ｘ_ｉを取得し、そして、Ｏ（ｌｏｇ^２ｑ）オペレーションを実行し、仮署名ｒ_ｉを計算する。ここで、ｑは、群Ｇの位数である。署名者は、１６０ビットであるｒ_ｉを通信するだけでよい。サーバには、署名ごとに、ｈ_ｉ及びＳｉｇ_ｉを記憶するストレージが含まれている。本実施形態では、値ｈ_ｉは、１６０ビットであり、一方、適当に短い署名スキームを用いることで、Ｓｉｇ_ｉも、３２０ビット以下に低減することができる。サーバは、オンラインの計算を行わない。その代わりに、サーバは、ペア（ｈ_ｉ，Ｓｉｇ_ｉ）を単に検索し、それを検証者に戻す。検証者の計算に関する限り、検証者は、１つの楕円曲線の点の乗法及び１つの通常の署名の検証を行わなければならない。

＜指定確認者スキームの例＞
仮署名を生成して仮署名を完了するプロセスを、指定確認者スキームに用いてもよい。そのようなスキームの例を、以下に説明する。

図９は、指定確認者署名スキームにおいて用いられる鍵生成プロセスの一実施形態の流れ図である。プロセスは、ハードウェア（例えば、回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、その両方の組み合わせを含んでもよい処理ロジックによって実行されてもよい。

図９を参照すると、プロセスは、標準的で安全なデジタル署名スキーム用の鍵ペアＰＫ_ＳとＳＫ_Ｓを生成し（処理ロジック９０１）、強秘匿公開鍵暗号スキーム用の鍵ペアＰＫ_ｄｃ及びＳＫ_ｄｃを生成する（処理ブロック９０２）処理ロジックによって開始される。これは、当技術分野において公知であるやり方で行われる。

図１０は、指定確認者署名スキームに用いられる仮署名生成プロセスの一実施形態の流れ図である。プロセスは、ハードウェア（例えば、回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、その両方の組み合わせを含んでもよい処理ロジックによって実行されてもよい。一実施形態において、処理ロジックは、署名者の一部である。

図１０を参照すると、プロセスは、メッセージＭに対して、コミットメントＣ（Ｍ，ｒ）を生成し（処理ブロック１００１）、コミットメントＳ＝Ｓｉｇ（Ｃ（Ｍ，ｒ））に署名する（処理ブロック１００２）処理ロジックによって開始される。次に、処理ロジックは、仮署名（Ｍ，Ｓ，Ｅ_ＰＫ（ｒ））を出力する（処理ブロック１００３）。ここで、Ｅは、強秘匿公開鍵暗号スキームである。

図１１は、指定確認者署名スキームにおける仮署名確認プロセスの一実施形態の流れ図である。プロセスは、ハードウェア（例えば、回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、その両方の組み合わせを含んでもよい処理ロジックによって実行されてもよい。一実施形態において、処理ロジックは、指定確認者の一部である。

図１１を参照すると、プロセスは、ｃｏｍｍ＝Ｃ（Ｍ，ｒ）となるような値ｒの知識についてのゼロ知識証明を実行する処理ロジックによって始まる（処理ブロック１１０１）。ここで、ｃｏｍｍは、仮署名に対応するコミットメントに対応する変数であり、Ｍは、署名者が署名したとされるメッセージである。

図１２は、指定確認者署名スキーム用の仮署名否認プロセスの一実施形態の流れ図である。プロセスは、ハードウェア（例えば、回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、その両方の組み合わせを含んでもよい処理ロジックによって実行されてもよい。一実施形態において、処理ロジックは、指定確認者の一部である。

図１２を参照すると、プロセスは、（Ｍ，Ｓ，Ｅ_ＰＫｄｃ（ｒ））として署名と考えられているものを構文解析することにより開始される（処理ブロック１２０１）。そして、処理ロジックは、（Ｍ，Ｓ，Ｅ_ＰＫｄｃ（ｒ））を解読し、ｒを回復する（処理ブロック１２０２）。最後に、処理ロジックは、Ｖｅｒ（Ｓ）＝１、Ｃ（Ｍ’，ｒ）＝Ｓ、Ｄ_ｃｈ（Ｅ_ｃｈ（ｒ））＝ｒ）及びＭ’≠Ｍとなるようなｒ及びＭ’の知識についてのゼロ知識証明を実行する（処理ブロック１２０３）。

他の実施形態において、処理ロジックは、追加の情報を検証者に送信する。これにより、処理ロジックは、請求されたメッセージ確認者が、ｃｏｍｍ＝Ｃ（Ｍ，ｒ）となるように、ｃｏｍｍ、Ｓ、及び、ｒの知識についてのゼロ知識証明を送信することを、（ゼロ知識において）検証者に確信させる。ここで、Ｍは、署名者が署名したとされるメッセージである。検証者は、Ｍが署名されたことを検証するために、ゼロ知識証明を確認し、Ｓが、ｃｏｍｍ上の有効な署名であることを確認する。

図１３は、指定確認者署名スキームにおける仮署名完了プロセスの一実施形態の流れ図である。プロセスは、ハードウェア（例えば、回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、その両方の組み合わせを含んでもよい処理ロジックによって実行されてもよい。一実施形態において、処理ロジックは、指定確認者の一部である。

図１３を参照すると、プロセスは、Ｅ_ＰＫ（ｒ）を解読してｒを取得する処理ロジックによって開始される（処理ブロック１３０１）。次に、処理ロジックは、Ｍ上の最終署名として（Ｍ，ｒ，Ｓ）を出力する（処理ブロック１３０２）。

図１４は、指定確認者署名スキームにおける最終署名検証プロセスの一実施形態の流れ図である。プロセスは、ハードウェア（例えば、回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、その両方の組み合わせを含んでもよい処理ロジックによって実行されてもよい。一実施形態において、処理ロジックは、検証者の一部である。

図１４を参照すると、プロセスは、Ｃ（Ｍ，ｒ）と等しい変数ｃｏｍｍを計算する処理ロジックによって開始され（処理ブロック１４０１）、ＰＫ_Ｓの下で有効な署名であるかを確認する（処理ブロック１４０２）。ここで、Ｓは、署名スキームの公開鍵である。そして、処理ロジックは、かかる確認が取れた場合のみに受け付けを行う（処理ブロック１４０３）。

一実施形態において、署名者と検証者とサーバとの間において、指定確認者デジタル署名を実行するためのデータ通信システムには、仮署名を生成可能なクライアントコンポーネント、仮署名を終了し最終署名を得ることが可能なサーバコンポーネント、及び、最終署名を検証可能な検証コンポーネントが含まれる。

一実施形態において、指定確認者署名スキームを実施する一実施形態における署名者、検証者、及びサーバのそれぞれは、ハードウェア装置（例えば、回路、専用ロジック等）、ソフトウェア装置（汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、処理ロジックを実行可能な、その両方の組み合わせであってもよい。これらのコンポーネントのそれぞれは、図３に示したコンポーネントのように実装されてもよい。指定確認者の署名者は、仮署名のリクエストを受信するために外部ネットワークインターフェイスと、仮署名を生成し外部ネットワークを介して仮署名を依頼者に戻すために外部ネットワークインターフェイス及びメモリに連結されているプロセッサとを用いる。指定確認者署名の検証者コンポーネントは、外部ネットワークインターフェイスを使って最終署名を受信する。指定確認者署名サーバコンポーネントは、仮署名を受信するために外部ネットワークインターフェイスと、指定確認者署名スキームの完了した最終署名をネットワークに送信するために外部ネットワークインターフェイス及びメモリに連結されているプロセッサとを用いる。

＜効率的変換の実現＞
本明細書に記載の変換を使用して効率的に実施するのがおそらく最も困難なステップは、否認プロトコル及び結果として生じるゼロ知識証明である。なぜならば、「この指定確認者署名は、無効である」ということが、ゼロ知識において証明することが可能なＮＰ-ステートメントであるという事実に基づいているだけだからである。

興味深いことに、指定確認者署名に含まれている暗号文がうまく形成されない可能性は、基礎となる暗号スキームについてのいくつかの仮定によって削除することができる。例えば、ビット文字列の無視可能な端数を除いた場合、その出力が密な暗号文である（ｃｉｐｈｅｒｔｅｘｔ-ｄｅｎｓｅ）暗号システムは、有効な暗号文である。否認プロトコルが、密な暗号文の暗号システムで作動する場合、ビット文字列は、無効な暗号文であり、それを証明する必要はない。

一実施形態において、密な暗号文の公開鍵暗号スキームは、以下のようにトラップドア順列から構成されている。公開鍵を、ｆ：｛０，１｝^ｋ→｛０，１｝^ｋとし、秘密鍵を、逆数ｆ^-１とする。単一ビットｂを暗号化するためには、ｘ_ｉｒ←_Ｒ｛０，１｝^ｋが用いられる。そして、暗号文は、

である。ここで、ＧＬは、「Ｇｏｌｄｒｅｉｃｈ-Ｌｅｖｉｎ ｐｒｅｄｉｃａｔｅ」である。スキームの強秘匿性を破る敵が、「Ｇｏｌｄｒｅｉｃｈ-Ｌｅｖｉｎ ｐｒｅｄｉｃａｔｅ」を予測しており、ｆの一方向性に矛盾することが容易に分かる。さらに、記号「，」は、連結を意味し、２ｋ＋１ビットの各文字列は、有効な暗号文である。或いは、ランダムな回復を提供する暗号スキームを用いることができる。つまり、ランダムｒを用いた暗号Ｅ_ＰＫ（ｍ）が与えられているので、復号には、ランダムｒ及びｍが含まれる。

＜Ｎ次剰余仮定に基づく効率的インスタンシエーション＞
基本的に、当技術分野において公知であるペリエ暗号は、以下のように行われる。受取人は、因子分解法が秘密にする合成係数Ｎを選択する。受取人は、また、Ｎ^２を法とする「十分に大きな」群、例えば、位数Ｎφ（Ｎ）/２の群、を生成する数字ｇ∈Ｚ/Ｎ^２Ｚを発行する。０≦ｍ≦Ｎを満たすｍを暗号化するためには、送信者は、ランダムなｒ∈Ｚ/Ｎ^２Ｚを選択し、暗号文ｃ＝ｒ^Ｎｇ^ｍ（ｍｏｄ Ｎ^２）を設定する。解読するためには、受取人は、基本的に、ｍ＝ｌｏｇ_ｇｃ（ｍｏｄ Ｎ）を計算する。ペリエ暗号では、決定的なＮ次剰余仮定の問題は難しいと仮定して強秘匿である。

一実施形態において、効率的な指定確認者署名スキームは、基本となる署名スキームを、強秘匿であるペリエ暗号とともに用いて、以下のように構築することができる。

１）鍵生成： 署名者は、標準的で安全なデジタル署名スキームに対して、鍵ペア（ＰＫ_Ｓ；ＳＫ_Ｓ）を生成する。指定確認者は、ペリエ係数Ｎ及びＮ^２を法とする適当なジェネレータｇを生成する。また、Ｎは、正しい形式であることを証明する証明書も生成する。最後に、指定確認者は、第２の群Ｇ_２及び位数Nをもつジェネレータｇ_２∈Ｇ_２の説明を提供してもよい。

２）ＰｒｏｖＳｉｇｎ（Ｍ）：
ａ）署名者は、

を計算するランダムｈ_２∈Ｇ_２及びランダムｒ∈Ｚ／ＮＺを生成して、メッセージｍに対してコミットメントを生成する。

ｂ）署名者は、Ｓ＝Ｓｉｇ（ｃ，ｈ_２）を生成する。

ｃ）署名者は、ｒ＝ｒ＋ａＮを設定し、Ｅ_Ｎ（ｒ）＝ｇ^ｒ’（ｍｏｄ Ｎ^２）を設定するランダムａ∈Ｚ／ＮＺを生成して、ｒ∈Ｚ／ＮＺのペリエ暗号を生成する。

ｄ）仮署名は、（ｍ，Ｓ，ｃ，ｈ_２，Ｅ_Ｎ（ｒ））である。

３）署名者によって確認： 署名者は、その指定確認者署名が正しく構築されたことを、Ｅ_Ｎ（ｒ）＝ｇ^ｒ（ｇ^Ｎ）^２（ｍｏｄ Ｎ^２）、及び、

となるようなr及びａの知識についてのゼロ知識証明を実行することにより証明する。これは、標準的な技術を用いて実施することもできる。指定確認者は、ペリエ暗号を通してｒ’（ｍｏｄ Ｎ）を回復することができ、ｒ’（ｍｏｄ Ｎ）は、

を完全に明らかにするので（Ｇ_２が位数Ｎを持つため）、検証者は、指定確認者が慣習的な署名（ｍ，Ｓ，ｈ２，ｒ）を指定確認者署名から「取り出す」ことができるという知識についてのゼロ知識証明によって確信させられる。知識の証明は、非常に効率的に実施することができることに留意されたい。

４）指定確認者による確認： 確認するために、指定確認者は、仮署名、及び、

の知識についてのゼロ知識証明だけを提供する。ペリエ暗号から容易にｒ回復することができる。

５）否認： 指定確認者署名が、悪く形成されている場合、Ｓは、（検証するのが非常に簡単である）（ｃ，ｈ_２）の有効な署名でなければ、

でもない。つまり、

を設定した場合、ｌｏｇ_ｇ２ｃ’≠ｌｏｇ（Ｅ_Ｎ（ｒ））（ｍｏｄ Ｎ）でなければならない。この不等式が成り立つことを証明するためには、指定確認者は、まず、ペリエ暗号を用いて、ｄ＝ｌｏｇ_ｇ（Ｅ_Ｎ（ｒ））（ｍｏｄ Ｎ）を回復する。ｘ＝φ（Ｎ）及びｙ＝ｄφ（Ｎ）の場合、Ｂ_Ｎ（ｒ）^ｘ＝ｇ^ｙ（ｍｏｄ Ｎ^２）であるが、

である。指定確認者は、とても標準的な技術を用いて、これらｘ及びｙの知識についてのゼロ知識証明を提供することができる。特に、１）確認者に、値
ｕ，ｖ∈Ｚ/ＮＺを選択させ、

を送信し、２）検証者に、ランダムにｂ∈{０，１}を選ばせ、３）ｂ＝０の場合、

となり、ｂ＝１の場合、

となるような値ｕ’，ｖ’∈Ｚ/ＮＺを確認者に送り返させることによって、通常の３ラウンドのゼロ知識証明を構築することができる。最後のステップにおいて、確認者は、ランダムな０≠ｋ∈Ｚ/ＮＺを生成し、ｕ’＝ｕ＋ｂｋｘ（ｍｏｄ Ｎ）及びｖ’＝ｖ‐ｂｋｙ（ｍｏｄ Ｎ）を設定することによって、そのような（ｕ’，ｖ’）を生成することができる。

指定確認者は、ｒの値を解読するので、指定確認者署名を誰もが検証可能な「通常の」署名に変換する。この通常の署名は、（ｍ，Ｓ，ｈ_２，ｒ）からなり、検証者は、Ｓが、

に対する（ｃ，ｈ_２）上の有効な署名であることを確認する。しかしながら、確認者の安全性を証明するために、すなわち、指定確認者と対話する悪質な敵は、結局、確認者の役割を侵害することができず、指定確認者署名を誰もが検証できる署名に変換する能力を得ることができない。ペリエ暗号の強秘匿なバージョンは、十分ではないと言えそうである。

しかしながら、上記の強秘匿なバージョンを、Ｃａｍｅｎｉｓｃｈ及びＳｈｏｕｐが説明したペリエ暗号のＩＮＤ−ＣＣＡ２安全バージョンと入れ換えることは、比較的単純な問題である。ゼロ知識証明は、基本的に同じである。主な違いは、暗号スキームが、ＩＮＤ−ＣＣＡ２なので、確認者は、悪質な敵が選択した暗号文の復号を確実に明らかにすることができ、そのため、上述したように通常の署名を、指定確認者署名から安全に取り出すことができる。

＜ブラインド署名スキームの例＞
図１５は、ブラインド署名スキーム用の鍵生成プロセスの一実施形態の流れ図である。プロセスは、ハードウェア（例えば、回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、その両方の組み合わせを含んでもよい処理ロジックによって実行されてもよい。一実施形態において、処理ロジックは、署名者の一部である。

図１５を参照すると、標準的で安全なデジタル署名スキーム用の鍵ペアＰＫ_Ｓ及びＳＫ_Ｓを生成する処理ロジックによって開始される（処理ブロック１５０１）。

図１６は、ブラインド署名スキーム用の仮署名生成プロセスの一実施形態の流れ図である。プロセスは、ハードウェア（例えば、回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、その両方の組み合わせを含んでもよい処理ロジックによって実行されてもよい。一実施形態において、処理ロジックは、ブラインダ、又は、署名者の一部である。

図１６を参照すると、ランダムな値ｒをとる処理ロジックによって開始され、Ｘ＝Ｃ（Ｍ，ｒ）を計算する（処理ブロック１６０１）。次に、処理ロジックは、Ｘを署名者に送信し、Ｘ＝Ｃ（Ｍ，ｒ）となるようなｒ及びＭの知識についてのゼロ知識証明を実行する（処理ブロック１６０２）。かかる証明が成功した場合にのみ、処理ロジックは、Ｘに署名し、Ｓｉｇ（Ｘ）を戻し（処理ブロック１６０３）、Ｍ上の仮署名を、Ｓｉｇ（Ｘ）＝Ｓｉｇ（Ｃ（Ｍ，ｒ））として出力する（処理ブロック１６０４）。

図１７は、ブラインド署名スキームの仮署名完了プロセスの一実施形態の流れ図である。プロセスは、ハードウェア（例えば、回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、その両方の組み合わせを含んでもよい処理ロジックによって実行されてもよい。一実施形態において、処理ロジックは、ブラインダの一部である。

図１７を参照すると、プロセスは、新規のランダム値ｒ’を生成する処理ロジックによって開始される（処理ブロック１７０１）。次に、処理ブロックは、Ｍ上の最終署名を（Ｃ（Ｓｉｇ（Ｃ（Ｍ，ｒ）），ｒ’））として計算する処理ロジックによって開始される（処理ブロック１７０２）。

図１８は、ブラインド署名スキーム用の最終署名検証プロセスの一実施形態の流れ図である。プロセスは、ハードウェア（例えば、回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、その両方の組み合わせを含んでもよい処理ロジックによって実行されてもよい。一実施形態において、処理ロジックは、ブラインダ、又は、署名者の一部である。

図１８を参照すると、プロセスは、Ｓが、値Ｓｉｇ（Ｃ（Ｍ，ｒ）、Ｖｅｒ（Ｓｉｇ（Ｃ（Ｍ，ｒ）））＝１とコミットせず、Ｃ（Ｍ，ｒ）が、Ｍとコミットしないようなｒ及びｒ’の検証者に対して、知識のＺＫ証明を行う処理ロジックによって開始される（処理ブロック１８０１）。

上述の対話型署名は、「Ｆａｓｔ-Ｓｈａｍｉｒ-ｈｅｕｒｉｓｔｉｃ」を通して、ランダムなオラクルを使用して非対話型として表すことができる。

図１９は、カメレオンハッシュ関数の検証用に予め計算した値を生成するプロセスの一実施形態の流れ図である。プロセスは、ハードウェア（例えば、回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、その組み合わせを含んでもよい処理ロジックによって実行されてもよい。一実施形態において、処理ロジックは、ブラインダ、又は、署名者の一部である。

問題は、Ｇが、位数ｑの群であり、ｇ，ｙ∈Ｇ及びｘ∈［１，ｑ］であるとすると、（Ｇ，ｇ，ｙ，ｘ）が与えられているので、Ｇにおいて、ｇ^ｘ＝ｙであることを証明して説明してもよい。

便宜上、ｃ_ｍａｘをチャレンジｃがとることができる最大値、ｋを上述した整数のパラメータとする、整数ｄに対するｄｌｏｇｑ（ｃ_ｍａｘ＋１）e＝ｋｄであるとする。

図１９を参照すると、プロセスは、定められたｋに対して、Ｘ＝｛ａｂ：ａ＝２^ｋｄ’，０≦ｄ’＜ｄ，１≦ｂ＜２^ｋ｝とする値ｘ_ｉ∈Ｘを見つける処理ロジックによって開始される（処理ブロック１９０１）。その後、処理ロジックは、（ｘ_ｉ，ｇ^ｘｉ）として定義されている予め計算された値を定義する（処理ブロック１９０２）。

図２０は、カメレオンハッシュ関数の検証用の予め計算された値を証明するプロセスの一実施形態の流れ図である。プロセスは、ハードウェア（例えば、回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、その両方の組み合わせを含んでもよい処理ロジックによって実行されてもよい。

図２０を参照すると、プロセスは、値（ｘ_ｉ，ｇ^ｘｉ）上のメルクルツリー（Ｍｅｋｌｅ ｔｒｅｅ）を計算することにより開始される（処理ブロック２００１）。次に、処理ロジックは、ルートとしてｈ_０を持つ、メルクルツリーのノードに対応する値ｈ_ｉによって構成される出力を出力する（処理ブロック２００２）。

図２１は、カメレオンハッシュ関数の検証用の予め計算された値を検証するプロセスの一実施形態の流れ図である。プロセスは、ハードウェア（例えば、回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、その両方の組み合わせを含んでもよい処理ロジックによって実行されてもよい。一実施形態において、処理ロジックは、ブラインダ、又は、署名者である。

図２１を参照すると、処理ロジックは、値

を与え、（ｘ，ｇ^ｘ）に対する有効な認証パスをｈ_ｉが形成していることを確認する（処理ブロック２１０１）。

図２２は、カメレオンハッシュ関数の検証用の予め計算された値を用いるカメレオンハッシュを確認するプロセスの一実施形態の流れ図である。プロセスは、ハードウェア（例えば、回路、専用ロジック等）、ソフトウェア（汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、その両方の組み合わせを含んでもよい処理ロジックによって実行されてもよい。

図２２を参照すると、プロセスは、値ごとの認証パス及び請求された（ｘ，ｇ^ｘ）を有する、予め計算された値

を与える処理ロジックにより開始され、予め計算された値を検証する（処理ブロック２２０１）。次に、処理ロジックは、Σｙ_１＝ｘを確認する（処理ブロック２２０２）。その後、

を確認する（処理ブロック２２０３）。処理ロジックは、全ての確認がとれた場合のみ、カメレオンハッシュ関数を受け付ける（処理ブロック２２０４）。

一実施形態において、署名者と検証者とサーバとの間のデータ通信を行うためのシステムには、仮署名を生成可能なクライアントコンポーネント、仮署名を終了し最終署名を得ることが可能なサーバコンポーネント、及び最終署名を検証可能な検証コンポーネントが含まれる。

一実施形態において、ブラインド署名スキームを実施する、署名者、検証者、及びサーバのそれぞれは、ハードウェア装置（例えば、回路、専用ロジック等）、ソフトウェア装置（汎用コンピュータシステムや専用マシーン上で作動するもの等）、又は、処理ロジックを実行可能な、その両方の組み合わせであってもよい。これらのコンポーネントのそれぞれは、図３に示したコンポーネントのように実装されてもよい。指定確認者の署名者は、仮署名のリクエストを受信するために外部ネットワークインターフェイスと、仮署名を生成し外部ネットワークを介して仮署名を依頼者に戻すために外部ネットワークインターフェイス及びメモリに連結されているプロセッサとを用いる。ブラインド署名の検証者コンポーネントは、外部ネットワークインターフェイスを使って最終署名を受信する。ブラインド署名サーバコンポーネントは、仮署名を受信するために外部ネットワークインターフェイスと、ブラインド署名の完了した最終署名をネットワークに送信するために外部ネットワークインターフェイス及びメモリに連結されているプロセッサとを用いる。

＜コンピュータシステムの例＞
図４は、本明細書に説明した１つ以上のオペレーションを実行するコンピュータシステムの一例を示すブロック図である。図４を参照すると、コンピュータシステムは、典型的なクライアント、又は、サーバコンピュータシステムを含んでもよい。コンピュータシステムは、通信メカニズム、又は、情報を通信するバス、及び情報を処理するためのバスに連結されたプロセッサを含んでいる。プロセッサには、マイクロプロセッサに限定されるわけではないが、例えば、Ｐｅｎｔｉｕｍ(登録商標)、ＰｏｗｅｒＰＣ、Ａｌｐｈａ等のマイクロプロセッサが含まれる。

システムには、更に、ランダムアクセスメモリ（ＲＡＭ）、又は、情報及びプロセッサにより実行される命令を記憶するバスに連結された他のダイナミックストレージ装置（メインメモリと呼ぶ）を含む。メインメモリを、プロセッサが命令を実行している間に、一時的な変数、又は、他の中間的な情報を記憶するために用いてもよい。

コンピュータシステムには、読み取り専用メモリ（ＲＯＭ）、及び／又は、静的な情報及びプロセッサ用の命令を記憶するバスに連結された他の静的ストレージ装置、及び磁気ディスク、又は、光学ディスク、及び、その対応するディスクドライブなどのデータ記憶装置も含まれる。データストレージ装置は、情報及び命令を記憶するバスに連結されている。

コンピュータシステムは、更に、コンピュータのユーザに情報を表示するバスに連結されたブラウン管（ＣＲＴ）、又は、液晶ディスプレイ（ＬＣＤ）等の表示装置に連結されていてもよい。英数字及び他のキーを含む英数字入力装置も、情報及びコマンドの選択をプロセッサに対して通信するバスに連結されていてもよい。追加的なユーザ入力装置は、指示情報やコマンドの選択をプロセッサに通信し、ディスプレイ上でのカーソルの動きを制御するためのバスに連結されたマウス、トラックボール、トラックパッド、スティラス、又は、カーソル指示キーなどのカーソル制御である。

バスに連結された他の装置は、命令、データ、又は他の情報を、紙、フィルム、又は、同様の種類の媒体などの媒体上に印刷するために使用してもよいハードコピー装置である。さらに、オプションとして、スピーカー及び／又はマイクなどの音声録音再生装置は、コンピュータシステムと音的にインターフェイスするバスに連結させることもできる。バスに連結されてもよい他の装置は、電話、又は、手のひらサイズの装置と通信する有線／無線通信能力である。

本発明において、システム及び関連するハードウェアのコンポーネントのどれでも、全てを使用してもよいことに留意されたい。一方で、コンピュータシステムの他の構成は、装置のいくらか、又は、全てを含んでよいことを理解することができる。上記の説明により、本発明の多くの変更及び修正が当業者には明らかとなることは疑いがなく、図により示し説明した特定の実施形態のどれも、本発明を制限しようとするものではないことが分かる。

上述の説明により、本発明の多くの変更及び修正が当業者には明らかとなることは疑いがなく、図により示し説明した特定の実施形態のどれも、本発明を制限しようとするものではないことが分かる。よって、様々な実施形態の詳細に対する参考文献が、本発明にとって必要不可欠であると見なされる特徴だけを述べた請求項の範囲を制限しようとしたものではない。

仮署名プロセスの一実施形態の流れ図である。 検証者プロセスの一実施形態の流れ図である。 署名者、サーバ、又は、検証者のコンポーネントの一実施形態を示す。 コンピュータシステムの一例を示す。 サーバアシスト型鍵生成プロセスの一実施形態の流れ図である。 サーバアシスト型鍵生成スキームにおける仮署名プロセスの一実施形態の流れ図である。 サーバアシスト型署名スキームにおける仮署名終了プロセスの一実施形態の流れ図である。 サーバアシスト型署名スキームにおける最終署名の検証プロセスの一実施形態の流れ図である。 指定確認者署名スキーム用の鍵生成プロセスの一実施形態の流れ図である。 指定確認者署名スキーム用の鍵生成プロセスの一実施形態の流れ図である。 指定確認者署名スキームの確認プロセスの一実施形態の流れ図である。 指定確認者署名スキームの否認プロセスの一実施形態の流れ図である。 指定確認者署名スキームのためのプロセスの一実施形態の流れ図である。 指定確認者署名スキームの用の最終署名検証プロセスの一実施形態の流れ図である。 ブラインド署名スキーム用の鍵生成プロセスの一実施形態の流れ図である。 ブラインド署名スキーム用の仮生成プロセスの一実施形態の流れ図である。 ブラインド署名の検証プロセスの一実施形態の流れ図である。 ブラインド署名の検証プロセスの一実施形態の流れ図である。 カメレオンハッシュ関数を予め計算するプロセスの一実施形態の流れ図である。 カメレオンハッシュ関数の検証のための予め計算された値を証明するプロセスの一実施形態の流れ図である。 カメレオンハッシュ関数の検証のための予め計算された値を証明するプロセスの一実施形態の流れ図である。 カメレオンハッシュ関数の検証のための予め計算された値を使ってカメレオンハッシュを確認するプロセスの一実施形態の流れ図である。

Claims (11)

1. メッセージ上でオペレーションを実行して仮署名を生成する工程と、
   前記仮署名を完了して前記メッセージ上で最終署名を生成する工程とを含む方法であって、
   前記仮署名を生成する工程は、
   第１の秘密シードを用いて第１の値ｘ_ｉを生成する工程と、
   第２の秘密シードを用いて第２の値ｃ_ｉを生成する工程と、
   ｍ_ｉが、前記メッセージである場合に、
   

   

   を満たす第３の値ｒ_ｉを特定する工程と、
   前記第３の値ｒ_ｉを前記仮署名として出力する工程とを含むことを特徴とする方法。
2. 前記仮署名を完了する工程は、
   前記仮署名のインデックスｉを受け取る工程と、
   前記インデックスｉに応じて、対応する値
   

   

   及びｈ_ｉを取得する工程と、
   前記最終署名
   

   

   （ｍ_ｉは、前記メッセージであり、ｒ_ｉは、前記仮署名である。）を出力する工程とを含むことを特徴とする請求項１に記載の方法。
3. 前記最終署名を検証する工程を更に含むことを特徴とする請求項１に記載の方法。
4. 前記最終署名を検証する工程は、
   

   

   を計算する工程と、
   

   

   であることを確認する工程と、
   前記確認が取れた場合にのみ、前記最終署名を受け付ける工程とを含むことを特徴とする請求項３に記載の方法。
5. メッセージ上でオペレーションを実行して仮署名を生成する工程と、
   前記仮署名を完了して前記メッセージ上に最終署名を生成する工程とを含む方法であって、
   前記仮署名を生成する工程は、
   Ｍが、前記メッセージであり、ｒが、ランダム文字列である場合に、コミットメントＣ（Ｍ，ｒ）を、前記メッセージに対して生成する工程と、
   Ｓｉｇ（Ｃ（Ｍ，ｒ））が、前記コミットメントＣ（Ｍ，ｒ）の署名を表す場合に、Ｓ＝Ｓｉｇ（Ｃ（Ｍ，ｒ））を生成する工程と、
   Ｅが、強秘匿公開鍵暗号スキームである場合に、前記仮署名として、（Ｍ，Ｓ，Ｅ_ＰＫ，（ｒ））を出力する工程とを含むことを特徴とする方法。
6. 前記仮署名を確認する工程を更に含むことを特徴とする請求項５に記載の方法。
7. 前記仮署名を確認する工程は、
   Ｍが、前記メッセージであり、ｒが、ランダム文字列であり、Ｓが、前記コミットメントＣ（Ｍ，ｒ）に署名することを表す場合に、Ｖｅｒ（Ｓ）が１に等しく、コミットメントＳｉｇ（Ｃ（Ｍ，ｒ））がＳに等しくなるような値ｒの知識についてのゼロ知識証明を実行する工程を含むことを特徴とする請求項６に記載の方法。
8. 前記仮署名を否認する工程を更に含むことを特徴とする請求項５に記載の方法。
9. 前記仮署名を否認する工程は、
   Ｖｅｒ（Ｓ）が１に等しく、コミットメントＣ（Ｍ’，ｒ）がＳに等しく、Ｄ_ｃｈ（Ｅ_ｃｈ（ｒ））がｒに等しく、Ｍ’≠Ｍとなるようなｒ及びＭ’の知識についてのゼロ知識証明を実行する工程を含むことを特徴とする請求項８に記載の方法。
10. メッセージ上でオペレーションを実行して仮署名を生成する工程と、
    前記仮署名を完了して前記メッセージ上に最終署名を生成する工程とを含む方法であって、
    前記仮署名をメッセージ上でオペレーションを実行して生成する工程は、
    ランダム値ｒを選択する工程と、
    Ｍが、前記メッセージである場合に、コミットメントＣ（Ｍ，ｒ）と等しい値Ｘを計算する工程と、
    前記値Ｘを署名者に送信する工程と、
    前記値Ｘが前記コミットメントＣ（Ｍ，ｒ）に等しくなるような前記ランダム値ｒ及び前記メッセージＭの知識についてのゼロ知識証明を実行する工程と、
    前記証明が成功した場合にのみ、前記値Ｘに署名して、Ｓｉｇ（Ｘ）を戻す工程と、
    Ｓｉｇ（Ｘ）＝Ｓｉｇ（Ｃ（Ｍ，ｒ））である場合に、Ｍ上の前記仮署名を出力する工程とを含むことを特徴とする方法。
11. 前記仮署名を完了し、前記メッセージ上に最終署名を生成することには、
    第２のランダム値ｒ’を生成し、
    前記メッセージＭ上の前記最終署名を（Ｃ（Ｓｉｇ（Ｃ（Ｍ，ｒ）），ｒ’））として出力することを含む、請求項１０に記載の方法。

Images