ユニバーサル匿名署名：匿名認証の過去、現在、未来のブリッジング

最近、論文"Foundations of Anonymous Signatures: Formal Definitions、Simplified Requirements、and a Construction Based on General Assumptions（匿名署名の基礎：正式な定義、簡素化された要件、および一般的な前提に基づく構造）"が2024年版Financial Cryptography（金融暗号）会議（FC'24）に掲載されました。この論文は、汎用匿名署名（UAS）について紹介しています。

UASは、匿名認証のドメイン内のいくつかのサブフィールドを繋ぐことに加えて、自己主権アイデンティティの将来を形成する可能性があると信じるものに向けた道筋を設定し、Atalaの中で確実に統合を推進します。

しかし、まず必要なのはこの問いでしょう。UASとは何なのでしょうか。

ちょっとした歴史

1985年、David Chaumはまず、人々が実際に身元を漏らすことなく、それでもサービスプロバイダーには正当な人と話しているという保証を与えられるような、暗号クレデンシャルについて検討しました。多くのバリアントが提案されましたが、通常は、所有者がどのクレデンシャルを公開するかを選択できる、証明された属性の概念を利用していました。これは、匿名クレデンシャル（AC）スキームと呼ばれます。

1991年、Chaumとvan Heystは、グループ署名（GS）を提案しました。これは、メンバーシップクレデンシャルを持つグループのメンバーがACと同様のことを行うことを可能にするものです。このメンバーシップクレデンシャルには通常属性はありませんが、GSスキームによって生成された署名は、匿名署名者の識別子を抽出できる、信頼できるエンティティによって処理されます。

ACおよびGS方式はどちらも、認証または署名に必要なクレデンシャルを発行する機関に依存しています。このようなエンティティは2001年、Rivest、Shamir、Taumanがリング署名（RS）スキームを概念化した際に排除されました。このスキームは、匿名を解除できず発行者を必要としないある種のグループ署名と見ることができます。

こうして、わずか16年の間に、暗号コミュニティは、ユーザーが匿名で自分自身を認証できるようにするための3つの異なるが類似の方法を見つけました。2001年以降、さらに多くのバリアントが提案されました。時には中間点が見つかることもあります。これには、リンク署名を許可するRSスキーム、もしくはユーザーのみが自分の署名にリンク可能なグループ署名などが挙げられます。

UASが解決する問題

実は、AC、GS、RSスキーム（およびその多くのバリアント）は共通点を持つだけではありません。その存在意義が密接に関連しています。ユーザーが匿名で認証できるようにする一方で、サービスプロバイダーは抽出可能な情報をある程度制御できます。理論的な観点からは、これはセキュリティモデルが一般的に非常に似ているという事実に反映されています。たとえば、署名から何が学べるかを捉える匿名性の特性について常に考える必要があります。そして、トレーサビリティと非フレーム化可能性のバリアントを持つ偽造不可能性プロパティについては、どのような種類の偽造不可能性保証を検証者（サービスプロバイダー）とユーザーがそれぞれ期待できるかを正確に述べています。また、非常によく似た構成要素からこれらのスキームを構築する方法があります。

しかし今までのところ、なぜかAC、GS、RS、その他は別個に研究されています。さらに、GSのようないくつかの具体的なブランチ内には、「グループ署名の基礎」のような参照セキュリティモデルが存在しますが、これは必ずしも当てはまるわけではありません。参照モデルを持つ場合でも、これらのセキュリティモデルは通常、具体的なプライバシーとユーティリティのトレードオフに縛られています。

実際的な例

クレデンシャルを提示するときに、任意の属性を選択して開示できるACスキームがあるとします。しかし、同じユーザーから提示されたものをリンクさせる必要がある場合など、これを再利用したくなるケースもあります（このユーザーにポイントを与えたい場合や、このユーザーがスパムを送信していてブロックしたい場合など）。つまり、ある種の監査可能性を追加することが望ましいのです。この先験的な単純な変更は、新しいセキュリティモデルを必要とします。そのやり方がわかっていれば、前モデルを拡張できますし、運が良ければ、それまでの構造も簡単に更新することができます。しかし、この種の実装を経験したことがあれば、そんなことは通常期待するだけ無駄であることがわかるでしょう。

匿名認証におけるプライバシーとユーティリティのトレードオフの動的モデル

具体的なプライバシーとユーティリティのトレードオフごとにセキュリティモデルを必要とすることは、明らかに理想から外れています。そしてこれこそ私たちが修正したい点です。というのも、このように近いながらも異なる要件は実際には非常に一般的であるためです。そこで、汎用セキュリティモデルであるUASを考え出しました。これは、ちょこちょこ調整できるため、必要なプライバシーとユーティリティのトレードオフの観点から、ユースケースのニーズに適応できます。もう少し詳しく見てみましょう。この種の匿名認証方式を採用する場合、次の3つの点が考えられます。

• 発行時：ユーザーがクレデンシャルを要求した場合、プロパティAまたはプロパティBを満たす、事前に取得した裏書クレデンシャルの提供を要求されることがある。 または、資格情報を提供する必要がまったくない場合もある。
• 署名時：ユーザーが匿名署名を作成する（またはクレデンシャルを提示する）場合、検証者はクレデンシャル属性が特定の基準を満たしていることを知ることを必要とする場合もある。
• 監査時：監査担当者は、署名の作成後に一部の情報を抽出することを要求する場合がある。監査役がいない場合も考えられる。

このさまざまなトレードオフは、上記の匿名性偽造不可能性テンプレートに基本的に従ったセキュリティフレームワーク内に埋め込まれている「関数型プレースホルダー」（プログラマーはこれを抽象関数と考えることができます）を介してキャプチャーします。エンジニアにとって最も重要なことは、私たちのモデルで安全であることが証明されている構造を考えると、発行、署名、監査の各ステップで必要な具体的な関数を指定するだけでよいということです。セキュリティは主となる構造のセキュリティに準じます。

これとGS、AC、RSとはどのような関係があるのですか

もっともな質問です。私たちが汎用モデルと主張するものが、実際に汎用であることを確認したかったのです。ではどのように行ったのか。私たちは、発行、署名、監査時に具体的な関数を与えることで、ジェネリック構造がGS、AC、またはRSスキームとして動作できることを証明しました。より具体的には、この構造のそのようなバリアントが、よく知られているセキュリティモデルの下で、安全なGS、AC、またはRSスキームであることを証明しました。

もちろん、論文は有限であるため、基本的なGS、AC、RSがUASの汎用構造から構築できることを証明しただけです。また、メッセージ依存オープニング（message-dependent-opening）付きGS、マルチモデルプライベート署名（Multimodal Private Signatures）、取り消し可能な匿名クレデンシャル（Revocable Anonymous Credentials）など、より高度なバリアントの証明もスケッチしています。他の多くのバリアントを想像するのは簡単です。たとえば、拡張監査機能を備えた匿名クレデンシャル、または学術分野ではまだ考慮されていないプライバシーとユーティリティのトレードオフを伴う匿名署名スキームなどです。

次に来るのは何ですか（または何が可能ですか）

まず、これがかなり理論上の産物であることがわかるでしょう。紙の上ではすべて正常に見えますが、コーディング中に問題が発生する可能性があります。無理もない懸念は、さまざまなユースケースに合わせて調整できる構造を持つことから、効率の観点からどのようなペナルティが支払われるかです。この懸念は極めて理にかなっています。結局のところ、1つの目的を念頭に置いて設計されたスキームは、より効率的になる傾向があります。これをより良く評価するために、プロトタイプを作成しています。最初は、内部の詳細を抽象化できるライブラリーを用意し、開発者が興味のある具体的な関数型プレースホルダーの実装に集中できるようにしたいと考えています。 次に、（現在のみの）汎用構造から、結果がどれほど効率的になるかをテストします。これはアプリケーションによっては十分でしょうが、すべてに当てはまることはないでしょう。

この論文では、BBS+、暗号化、および一般的な（非対話的）ZK証明に基づく汎用構造を提供しています。選択的開示型の請求を達成したい場合は、これで間違いなく問題ありませんが、たとえば、より表現的な述語を証明したい場合には適していない可能性があります。ですから、次のステップは、より表現的な要求に適した代替の汎用構造を考えることです。

また、理論的な観点からは、将来に向けた多くのアイデアがあります。たとえば、発行者や監査人が関数を変更できるようにするなどです。現在、多くの発行者や監査人が共存できますが、それぞれが関数にコミットしています。または、完全な動的設定などにモデルを適応させることもできます。

UASをAtalaに統合する方法とは

前述のように、BBS+、暗号化（ElGamal）、ZK証明（基本的なSigmaプロトコル）からの汎用構造に基づいて実装に取り組んでいます。これが私たちの出発点であり、Atalaが提供するSSIスタックでこの新しい技術をテストすることができます。UASをAtalaのOpen Enterprise Agentスタックに統合することで、Atalaに含まれるすべてのツールを活用し、SSI固有のエージェント、ノード、通信プロトコルなどを使用した実稼働環境でのUASの動作テストを開始し、市場およびエンジニアリングチームのニーズに適応させることができます。

今後の更新情報に注目してください。