ユニバーサル匿名署名: 匿名認証の過去、現在、未来の橋渡し

最近、論文「匿名署名の基礎: 正式な定義、簡素化された要件、および一般仮定に基づく構築」が、金融暗号化カンファレンスの 2024 年版である FC'24 に受理されました。この文書では、**ユニバーサル匿名署名 (UAS)**について説明します。

UAS は、匿名認証の領域におけるいくつかのサブフィールドの橋渡しをするだけでなく、自己主権アイデンティティ (の一部) の将来になる可能性があると私たちが信じているもの、そして私たちが確実に統合を推進するものへの道を設定するものであるため、私たちはこれに本当に興奮しています。アタラのお供え物。

しかし、紹介としては十分です。 UAS とは何ですか?

ちょっとした歴史

1985 年に、David Chaum は、人々が実際に自分の身元を漏らすことなく使用でき、しかもサービス プロバイダーに正規の人物と通信しているという保証を与える暗号資格情報を初めて考えました。多くの亜種が提案されており、通常は認証済み属性の概念を活用しています。これは、認証情報の所有者が公開するかどうかを選択できるものです。これは、匿名認証情報 (AC) スキームとして知られています。

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

AC スキームと GS スキームはどちらも、認証または署名に必要な資格情報を発行する当局に依存しています。このようなエンティティは、Rivest、Shamir、Tauman がリング署名 (RS) スキームを考案した 2001 年に削除されました。RS スキームは、匿名化が不可能で発行者を必要としない、一種のグループ署名とみなすことができます。

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

UAS は何を解決しますか?

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

しかし、どういうわけか、これまでAC、GS、RSなどが個別に研究されてきました。さらに、GS などの具体的な部門内には、「Foundation of Group Signatures」の業務系統のような参照セキュリティ モデルが存在しますが、常にそうであるとは限りません。参照対象モデルがあっても、これらのセキュリティ モデルは通常**、プライバシーとユーティリティの具体的なトレードオフ**に関連付けられています。

実際の例

資格情報の提示時に任意の属性を選択的に開示できる AC スキームがあるとします。ただし、同じユーザーからのプレゼンテーションをリンクする必要があるシナリオでそれを再利用したいとします (おそらく、このユーザーに忠実度ポイントを与えたい、またはこのユーザーがあなたにスパムを送っているのでブロックしたいと考えています)。 。要するに、ある種の監査可能性を追加したいということです。この先験的な単純な変更には、新しいセキュリティ モデルが必要です。確かに、その方法を知っていれば、以前のものを拡張することができ、運が良ければ、以前の構造を簡単に更新することもできます。しかし、この種のことを実装したことがあるなら、これは通常あまりにも期待が大きすぎることをすでに知っているでしょう。

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

具体的なプライバシーとユーティリティのトレードオフごとに 1 つのセキュリティ モデルを要求することは、明らかに理想的ではありません。このような、似ているが異なる要件は実際には非常に一般的であるため、これはまさに私たちが修正したかったものです。そこで私たちが行ったのは、必要なプライバシーとユーティリティのトレードオフの観点から、ユースケースのニーズに適応できるように、随所で調整できる汎用セキュリティ モデルである UAS を考案することです。 。もう少し詳しく見てみると、このタイプの匿名認証スキームを適応させる必要があるポイントが 3 つあります。

  • 発行時: ユーザーが資格情報を要求すると、特性 A または B を満たす以前に取得した承認資格情報の提供が求められる場合があります。あるいは、資格情報の提供がまったく要求されない場合もあります。
  • 署名時: ユーザーが匿名署名を作成する (または資格情報を提示する) 場合、検証者は資格情報の属性が特定の基準を満たしていることを学習する必要がある場合があります。
  • 監査時: 監査者は、署名の作成後に一部の情報を抽出できるように要求する場合があります。監査人がまったくいない場合もあります。

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

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

公正な質問です!私たちは、私たちが主張する一般モデルが実際に一般的であることを確認したかったのです。では、どうやってそれを実現したのでしょうか?そうですね、発行、署名、監査時に具体的な機能を与えることで、汎用的な構造が GS、AC、または RS スキームとして動作できることを証明しました。より具体的には、このような構築の変形が、よく知られているセキュリティ モデルに基づく安全な GS、AC、または RS スキームであることを証明します。

もちろん、論文は有限であるため、基本的な GS、AC、および RS が UAS の一般的な構造から構築できることを証明するだけです。また、メッセージ依存の開始、マルチモーダルプライベート署名、取り消し可能な匿名資格情報を備えた GS など、より高度な亜種の証明もスケッチします。他にも多くのバリエーションがあることは容易に想像できます。たとえば、拡張された監査機能を備えた匿名認証情報や、学術分野ではまだ考慮されていないプライバシーとユーティリティのトレードオフを備えた匿名署名スキームなどです。

次に何が起こるのか(あるいはそうなる可能性があるのか​​)

最初にお気づきかもしれませんが、これはかなり理論的な研究です。紙の上ではすべて問題なく見えても、コーディング中に問題が発生する可能性があります。当然の懸念は、多くの異なるユースケースに適合できる構造を持つことで、効率の観点からどのようなペナルティが支払われるかということです。これは非常に当然の懸念です。結局のところ、単一の目的を念頭に置いて設計されたスキームは、より効率的になる傾向があります。これをより良く評価するために、私たちはプロトタイプの開発に取り組んでいます。最初に、内部の詳細を抽象化して、開発者が関心のある具体的な機能プレースホルダーの実装に集中できるライブラリを用意したいと考えています。次に、(現時点では唯一の) 汎用的な構造から結果がどの程度効率的であるかをテストします。 。これはおそらく一部のアプリケーションには十分ですが、すべてではありません。

この論文では、BBS+、暗号化、および一般的な (非対話型) ZK 証明に基づいた一般的な構造を示しています。これは、達成したいことが選択的開示タイプのクレームである場合にはほぼ間違いなく問題ありませんが、たとえば、より表現力豊かな述語を証明したい場合には適さない可能性があります。したがって、次のステップは、より表現力豊かな要件に適した代替の汎用構造を考えることです。

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

UAS を Atala にどのように統合する予定ですか?

述べたように、私たちは BBS+、暗号化 (ElGamal)、および ZK 証明 (基本的なシグマ プロトコル) からの一般的な構築に基づいた実装に取り​​組んでいます。これが出発点となり、Atala が提供する SSI スタックでこの新しいテクノロジーをテストできるようになります。 Atala の Open Enterprise Agent スタック内に UAS を統合することで、Atala に含まれるすべてのツールを活用し、本番環境 (SSI 固有のエージェント、ノード、通信プロトコルなど) で UAS がどのように動作するかテストを開始できるようになります。市場やエンジニアリング チームのニーズに合わせて調整します。

今後のアップデートにも注目してください!