分散トレーサビリティを備えたグループ署名スキーム(または署名を公正に開く方法)

アンネ・ローア・デルバによる画像

この投稿では、グループ署名スキーム、特に分散トレーサビリティを備えたグループ署名について説明し、これらの署名の使用方法の例としてHelixコンセンサスプロトコルを使用して、これが分散システムにとって興味深い暗号化ツールである理由を示したいと思います。

ChaumとVan Heystによって導入されたグループ署名により、グループのメンバーはグループに代わって匿名で署名することができますが、特別な場合に署名者の身元を追跡する可能性を提供します。つまり、グループの参加者は、検証キーを使用して、グループ内の誰かが実際に署名を作成したことを確認できますが、だれからはわかることはできません。紛争または不正行為の場合、追跡機関はその追跡キーを使用して署名者を追跡します。

いくつかのユースケースでは、単一のトレース機関が機能します。ただし、他の多くの場合、匿名性を取り消すために誰もが信頼する単一の権限はないため、複数の権限の間で責任を分割する方が理にかなっています。この洞察は、ベンジュメアらを導きました。 「公正な追跡可能なマルチグループ署名」を設計する。それらのスキームでは、複数の公正機関が協力すれば署名を開くことが可能です。公正機関は、疑わしいユーザーの追跡キーを明らかにするために協力することもできます。このキーを使用して、他のユーザーの匿名性を無効にすることなく、メッセージが特定のユーザーによって署名されたかどうかを確認できます。

今日まで、Zhengらによる「しきい値トレーサビリティを備えた民主的なグループ署名」やBlomerらによる「分散トレーサビリティを備えた短期グループ署名」など、提供する機能に関してわずかに異なる分散トレーサビリティを備えたいくつかの署名スキームがあります。他、さらに詳しく説明します。

Helixの分散トレーサビリティを備えたグループ署名

Orbsでは、Helixを開発しています。Helixは、トランザクションが公正な方法で注文されるように特に設計された独自のコンセンサスプロトコルです。 Helixの重要な概念は、ネットワークノードが新しいブロックに含まれるトランザクションやその順序を操作できないことです。特に、特定のノードまたはユーザーを検閲することはできず、実質的な方法で独自のトランザクションを優先することはできません。 Helixの詳細については、このブログ投稿をご覧ください。

Helixの公平性に大きく貢献しているのは、ユーザーにトランザクションを暗号化し、ブロックチェーンに追加された後にのみ元のトランザクションを復号化させることです。トランザクションの暗号化には代償が伴います。特に、有効なトランザクションの代わりにネットワークにジャンクを送信しているユーザーとノードを罰する必要が生じます。このため、評判を落とすために、問題のあるトランザクションの原因となっているネットワークノードを明らかにするメカニズムが必要です。

これを行うには、各ネットワークノードをフェアネス機関として機能させ、シグネチャを開いてトレースするためのしきい値数の機関を必要とすることにより、分散トレーサビリティを持つグループシグネチャを使用します。

次に、Helixでトランザクションが行うフローと、分散トレーサビリティを備えたグループシグネチャの使用方法について説明します。この特定のフローにあまり興味がない場合は、先にスキップして、候補の署名スキームについて読んでください。このフローは、ユーザーがトランザクションを作成して暗号化し、関連付けられているネットワークノードに送信すると開始されます。次に、ネットワークノードは、公正な追跡可能なグループ署名スキームを使用してトランザクションに署名し、トランザクションをネットワークに中継します。トランザクションをブロックに含める前に、ブロック作成者はトランザクションに有効なグループ署名があることを確認します。ブロックがブロックチェーンに追加された後、ブロック内のトランザクションを復号化するプロセス(ノードのしきい値数が必要)を開始します。必要に応じて(たとえば、復号化されたトランザクションが無効であることが判明した場合)、しきい値の数のノードが協力して署名を開き、どのノードがこのトランザクションに署名したかを明らかにします。

フローの別の可能なオプションは、復号化プロセスと並行してデフォルトで署名を開くことです。デフォルトで署名を開くことの利点は、この方法では、障害のあるトランザクションのために特別なプロトコルを開始する必要がなく、通常のフローの一部としてこのプロセスが実行されることです。もう1つのオプションは、トレースキーを明らかにするプロセスを組み込むことです(特定の誤動作しているノードをトレースするために使用されます)。また、一部のグループ署名スキームには、署名者が署名をそれらに属していると主張できるクレーム機能もありますが、上記のフローでは使用していません。

フローから、求めるセキュリティ要件を推測します。

  • 匿名性:しきい値を超える数の公正機関が協力しない限り、グループ署名はそれを作成したメンバーの身元を明らかにしません。
  • 追跡可能性は匿名性を維持します:ノードがそれが署名の発信者であると主張する場合、またはそのアイデンティティが追跡アルゴリズムの一部として明らかにされた場合、これはそれが発行する残りの過去または将来のグループ署名のプライバシーを構成しません。
  • リンク不能:しきい値数の当局の協力なしに、同じ署名者によって生成されたものとして2つ以上の署名を関連付けることは不可能です。
  • 非フレーム化:グループおよびトレーシングマネージャーがグループの他のメンバーと共謀したとしても、正直なグループメンバーをフレーム化することはできません。ユーザーは2つの異なる方法でフレーム化できます:当局と他のユーザーは、無実のユーザーを開くか追跡する署名を作成するか(この要件は強力な除外性とも呼ばれます)、またはユーザーが生成した署名を彼ら自身。

他の重要な要件は、署名者とトレーサーの動的な変更をサポートし、信頼できるセットアップを必要としないことです。

候補署名スキーム

現在知られている最も効率的な署名スキームの1つは、Boneh、Boyen、およびShacham(BBS)によるもので、論文「Short group signatures」で紹介されています。第一に、グループ署名方式は分散トレーサビリティを提供しませんが、むしろ集中化されたトレース機関を必要とします。さらに、これらのスキームは、「トレーサビリティが匿名性を維持する」プロパティを満たしていません(これは、後で説明するCCA匿名性を提供しないためです)。さらに、キー生成プロセスには信頼できるディーラーが必要です。幸いなことに、最初の2つの問題を処理するフォローアップペーパーがあります。アイデアを組み合わせて、分散トレーサビリティを提供するCCA匿名署名スキームを実現できます。信頼できるディーラーを取り除くことは、このスキームを選択した場合に対処する必要がある問題です。

Blomer et。による論文で「分散トレーサビリティを備えた短いグループ署名」など、BBSのスキームは、分散トレーサビリティをサポートするように拡張されています。これは次の方法で達成されます。 BBSスキームでは、署名の一部は秘密鍵(の一部)の暗号化であり、この暗号文を解読するための量が開かれています。 Blomerの論文では、暗号化をしきい値暗号化に変更しています。署名を開くには2つのプロセスがあります。1つ目は署名からオープンな共有を作成し、2つ目はしきい値の共有を組み合わせて署名者のキーを復号化します。彼らが行う別の変更は、秘密鍵に追加要素を追加することです。秘密鍵は、ユーザーのみに知られ、公正機関には知られていません。これにより、公正当局が他のメンバーに代わって署名できないことが保証されます。

BBSによるスキームは、CPA匿名性を提供します。大まかに言うと、これは、攻撃者がトレース署名プロトコルを照会しない限り、署名が匿名であることを意味します。ただし、この仮定は、攻撃者が署名されたメッセージを生成してブロックチェーンに送信する可能性があるため、この設定では正当化されません。その後、通常のフローの一部として追跡されます。したがって、署名スキームはCCA匿名である必要があります。つまり、open \ tracingプロトコルにアクセスする攻撃者でさえ、しきい値の数の公正機関と協力しないと署名を追跡できません。 Fischlinの論文「オンライン抽出機能を使用したコミュニケーション効率の高い非対話型の知識証明」では、BBSによる署名スキームをCCAセキュアに変換する方法を紹介しています。これは、暗号化時に使用されるランダム値の非対話型ゼロ知識知識証明を生成する署名にコンポーネントを追加することにより機能します。非公式に、これにより、攻撃者は有効なメッセージに署名するために、最初に暗号化の生成に使用されるランダムな値を知る必要があったため、トレースプロトコルとの対話から多くを得ることはありません。

署名のサイズ

著者によって提案されたパラメータの下でのBBSグループ署名スキームの長さは1,533ビットです。これはRSA署名のサイズに匹敵します。RSA署名は、同様のセキュリティを持つ署名の場合、1,024または2,048ビット長です。分散トレーサビリティを追加しても署名は長くなりませんが、複雑さに関しては、共有を結合するためにラグランジュ多項式補間を計算する必要があります。

知識のゼロ知識証明に関しては、これは比較的サイズが大きく、計算にコストがかかります。論文で提案されているパラメータの場合、長さは3,520ビットであり、合計で5,053ビットの署名長になります。

署名共有のサイズは、共有あたり340ビットです。

この問題に関する有益な議論をしてくれたSteven Goldfederに感謝します。

*オーブのホワイトペーパーを読む:https://www.orbs.com/white-papers

Orbsコミュニティに参加:

  • 電報:https://t.me/orbs_network
  • Twitter:https://twitter.com/orbs_network
  • Reddit:https://www.reddit.com/r/ORBS_Network/
  • GitHub:https://github.com/orbs-network