本文へ移動
Financial Context Wiki

BLS署名

Boneh-Lynn-Shacham署名、集約方式、暗号スイート、rogue-key対策、Ethereumコンセンサスでの利用、実装リスクを検証の観点から解説します。

更新日

教育目的の参考情報であり、投資または暗号実装上の助言ではありません。署名の有効性だけでは、プロトコルの安全性、認可、可用性、ファイナリティを証明できません。

直接の答え

Boneh-Lynn-Shacham署名は、ペアリングに基づくデジタル署名です。一般的な向きの一つでは、秘密鍵 sk から公開鍵 PK = sk * G1 を生成し、メッセージ m を H(m) に写像します。この点は G2 上にあり、署名 sig = sk * H(m) を e(PK, H(m)) = e(G1, sig) で検証します。正確な群、エンコード、hash-to-curveスイート、ドメイン分離は暗号スイートの選択事項であり、相互に置き換えられる表記ではありません。

BLSには、妥当な署名を加算して固定サイズの群要素一つにできるという珍しい運用上の利点があります。署名は圧縮できますが、署名者リストを圧縮したり、クオーラムを証明したり、認可済みバリデーターを特定したり、二重投票を防いだり、コンセンサスをファイナライズしたりはしません。これらの性質は周囲のプロトコルが与えます。

仕組み

  1. プロトコル、暗号スイート、バージョンを固定します。曲線、公開鍵群と署名群、シリアライズ、hash-to-curve関数、ドメイン分離タグ、メッセージルート構築を確認します。BLSという名称だけから互換性を推測してはいけません。
  2. 指定された鍵生成手順で sk を生成し、PK を導出します。正確な KeyValidate とデシリアライズ規則に従い、ゼロ、無限遠点、不正形式、非正規、誤った部分群のエンコードを拒否します。
  3. 正確なメッセージバイトと署名ドメインを構築します。Ethereumコンセンサスでは、署名ルートはSSZオブジェクトルートを、操作種別とフォークデータから導くドメインに結び付けます。表示文字列が署名対象なのではありません。
  4. 選択した方式で署名し、個別検証します。Basic、message augmentation、proof of possessionの各変種はrogue-key対策が異なり、安易に混用できません。
  5. メッセージのパターンに応じて集約検証器を選びます。複数の検証済み公開鍵が、必要な所有証明の前提の下で同一メッセージに署名した場合に限り FastAggregateVerify を使います。方式が許す公開鍵とメッセージのリストには AggregateVerify を使います。
  6. 委員会データまたは参加者ビットリストから署名者集合を独立に再構築し、重複または未認可のインデックスを拒否し、ステークまたは閾値の重みを適用してから集約署名を検証します。妥当な集約は提示された集合を認証しますが、その集合が方針を満たすかは決定しません。
  7. 結果をフォーク選択、スラッシング条件、クオーラム、可用性、タイミング、ファイナリティと照合します。入力バイト、ドメイン、署名者インデックス、実装バージョン、テストベクトルを保存し、配備前に独立したライブラリー同士を比較します。

計算例

  • 圧縮してもメンバー情報は不要にならない。 Ethereumコンセンサスでは、BLS公開鍵を一つ 48 bytes、署名を一つ 96 bytes でエンコードします。同一メッセージへの署名が 512 個あれば、個別署名は 512 * 96 = 49,152 bytes を占めます。一つの集約署名と 512-bit = 64-byte の参加者ビットリストなら 96 + 64 = 160 bytes で、49,152 - 160 = 48,992 bytes、すなわち 99.6744791667% の削減です。バリデーター公開鍵と委員会の対応関係は別途利用できなければなりません。
  • 同一メッセージの集約。 登録済みバリデーター 17、24、91 が同じ署名ルート R に署名するとします。署名の集約は sigAgg = sig17 + sig24 + sig91 です。検証には、順序付きで検証済みの公開鍵集合 [PK17, PK24, PK91]、同じ R、FastAggregateVerify を使います。妥当な結果は、方式の下でこれらの鍵が R に署名したことを証明します。各鍵の重みと、3名がクオーラムを形成するかは別の規則で決まります。
  • 異なるメッセージには正しいAPIが必要。 公開鍵 PK1、PK2、PK3 が別々のメッセージ m1、m2、m3 に署名します。検証器は組 [PK1, m1]、[PK2, m2]、[PK3, m3] を維持し、該当する AggregateVerify を呼ぶ必要があります。入力を一つのメッセージに置き換えて FastAggregateVerify を使うと、別の主張を検証することになります。Basic方式では、メッセージ同士も異なっていなければなりません。
  • 集約は閾値署名ではない。 8 人のグループでメンバー [1, 2, 4, 6, 8] の通常署名を集約すると、署名一つと5名の署名者リストができます。単一のグループ公開鍵で検証する 5-of-8 閾値署名にはなりません。真のthreshold BLSには、分散鍵生成または信頼できるディーラーのモデル、シェアのインデックス、補間規則が必要であり、その信頼と障害の前提は別途監査しなければなりません。

リスク

  • プロトコルと異なる曲線、群の向き、暗号スイートを使うこと。
  • 同じ人間可読メッセージを表示しながら、別のシリアライズ済みバイトに署名すること。
  • フォーク、操作、アプリケーションのドメインを省き、文脈をまたぐリプレイを許すこと。
  • 期限切れのInternet-Draftを不変の最終標準として扱うこと。
  • 不正形式、非正規、無限遠点のエンコードを受け入れること。
  • 部分群検査を省き、無効曲線または小部分群の入力を許すこと。
  • 指定スイートとテストベクトルではなく、独自のhash-to-curveコードを使うこと。
  • 偏り、ゼロ、重複、漏えい、予測可能な導出がある秘密鍵を生成すること。
  • 所有証明とドメインの前提が異なるプロトコル間で同じ鍵を再利用すること。
  • 方式が要求するrogue-key対策なしに、未登録公開鍵を集約すること。
  • 異なるメッセージや不一致なルートに同一メッセージ用の高速検証を呼ぶこと。
  • 公開鍵とメッセージの対応を並べ替え、重複、欠落させること。
  • 委員会所属とインデックスの一意性を確認せず、参加者ビットリストを信用すること。
  • プロトコルが定めるステーク、重み、閾値ではなく署名数を数えること。
  • 一つの集約から、どの個別署名が無効か分かると考えること。
  • 通常の集約、マルチシグ、閾値署名を混同すること。
  • 署名の妥当性を、データ可用性、実行の正しさ、ファイナリティの証明とみなすこと。
  • 二重投票、スラッシング対象メッセージ、時間枠、フォーク選択の文脈を無視すること。
  • 単一ライブラリー、CPU機能、未検証のバッチ検証最適化に依存すること。
  • ペアリングコスト、DoS入力、サイドチャネル、鍵の保管、アップグレード、耐量子性の欠如を過小評価すること。

よくある誤解

  • 集約署名は全バリデーターの参加を証明する。
  • 所有証明の規則なしに、任意のBLS公開鍵と署名を安全に組み合わせられる。
  • 固定サイズ集約により、署名者のメンバー情報を送信または再構築する必要がなくなる。
  • BLS集約とthreshold BLSは同じ構成である。
  • 有効なBLS署名があれば、署名対象のブロック、ブリッジメッセージ、プロトコルは経済的に安全でファイナライズ済みである。

関連トピック

出典

ナビゲーション

Wiki を検索...