Road to Devcon 4.0 〜 Security & Privacy https://ethereumjapan.connpass.com/event/143056/

1. 集約署名
光成滋生
2019/9/20
Road to Devcon 4.0 〜 Security & Privacy

2. • ペアリングの応用と実装研究
• https://github.com/herumi/bls ; BLS署名
• https://github.com/herumi/mcl ; ペアリング
• Linux/Windows/Mac/Android/iPhone/WebAssembly対応
• used by DFINITY, libsnark, Harmony.one, 0CHAIN, ChainSafe, spacemesh,
Prysmatic Labs Ethereum 2.0, AZTEC protocol, .etc.
• https://github.com/herumi/xbyak ; JITアセンブラ
• used by Intel MKL-DNN, etc.
• 『クラウドを支えるこれからの暗号技術』
@herumi
2 / 13

3. • あるメッセージ𝑚に対して自分しか知らない秘密鍵𝑠𝑘で署名𝜎を作る
• だれもが知ってる公開鍵𝑝𝑘を使って(𝑚, 𝜎)が改竄されていないことを検証できる
• 秘密鍵𝑠𝑘を知らない人は検証をパスする偽の署名(𝑚′
, 𝜎′
)を偽造できない
• 𝜎は𝑚の暗号文ではない（通常𝜎は定数サイズ, 𝑚は任意のサイズ）
• 署名アルゴリズム
• 鍵生成
• 安全性レベルを示すセキュリティパラメータを元に(𝑠𝑘, 𝑝𝑘)を生成
• 署名
• メッセージ𝑚と𝑠𝑘から署名𝜎を作成
• 𝜎 = 𝑆𝑖𝑔𝑛 𝑠𝑘, 𝑚
• 検証
• メッセージ𝑚と署名𝜎と𝑝𝑘を元にtrue/falseを返す
• 𝑉𝑒𝑟𝑖𝑓𝑦 𝑝𝑘, 𝑚, 𝜎 = true/false
電子署名
3 / 13

4. • 一つのメッセージ𝑚に対して複数人がそれぞれ署名する
• 𝜎1 = 𝑆𝑖𝑔𝑛 𝑠𝑘1, 𝑚 , 𝜎2 = 𝑆𝑖𝑔𝑛 𝑠𝑘2, 𝑚 , 𝜎3 = 𝑆𝑖𝑔𝑛 𝑠𝑘3, 𝑚
• それぞれの署名を一つずつ検証するのではなくまとめて検証したい
• Pragmatic signature aggregation with BLS
• https://ethresear.ch/t/pragmatic-signature-aggregation-with-bls/2105
• aggregate 𝜎1, 𝜎2, 𝜎3 → 𝜎?
• 署名サイズの削減(数千個)
• 検証時間の削減
• お父さん𝜎1、お母さん𝜎2、子ども𝜎3に対してどれか2個の署名があれば有効としたい
• 𝜎1, 𝜎3 → 𝜎?, 𝜎2, 𝜎3 → 𝜎?
• 𝑘-of-𝑛 ; 𝑛人のうち𝑘人が署名すれば全体として有効
マルチシグ(multi-signature)・集約可能署名
4 / 13

5. • 閾値署名
• 𝑛人による署名のうち𝑘個集めると
• (誰も知らないマスター秘密鍵に対する)署名を復元できる
• その署名は(誰もが知ってる)マスター公開鍵で検証できる
• 集約署名
• 𝑛個の署名を一つ一つ検証するのは手間と署名のスペースが必要
• それらをまとめて(できるだけ)小さい署名を作る
• それを(できるだけ効率よく)検証するだけで全部の署名を検証したのと同じ
閾値署名と集約署名
5 / 13

6. • 𝐺 : 「足し算」ができる𝑝個の点からなる集合
• とりあえず中身はブラックボックスでよい
• 0 ; 足し算におけるゼロを表す値（点）
• 𝑃 ; 0以外の特定の点（固定しておく）
• 𝐺 = 0, 𝑃, 2𝑃, 3𝑃, … , 𝑝 − 1 𝑃
• 𝑝𝑃 = 0 ; 𝑝倍したら0に戻る
• 一方向性
• 𝑃の整数𝑎倍を計算するのは容易 : 𝑃, 𝑎 ↦ 𝑎𝑃
• 𝑎𝑃と𝑃を知っていても𝑎を求めるのは困難：(𝑃, 𝑎𝑃) ↦ 𝑎
• 楕円離散対数問題(ECDLP)の困難性
• 𝑎が秘密鍵で𝑎𝑃が公開鍵のパターンが多い
• secp256k1という曲線がよく使われる
楕円曲線
6 / 13

7. • 楕円曲線を2個使う
• 𝐺1 = {0, 𝑃, 2𝑃, … , 𝑝 − 1 𝑃}, 𝐺2 = {0, 𝑄, 2𝑄, … , 𝑝 − 1 𝑄}
• 楕円曲線の2個の点からある集合𝐺 𝑇 = {𝑔, 𝑔2
, 𝑔3
, … , 𝑔 𝑝−1
}への写像で
𝑒 𝑎𝑃, 𝑏𝑄 = 𝑔 𝑎𝑏 for 𝑎, 𝑏 ∈ ℤ where 𝑔 = 𝑒 𝑃, 𝑄 を満たすもの
• BN254, BLS12-381という曲線がよく使われる
• BN254は100~110ビット安全性
• 従来128ビット安全と思われていたが攻撃改良により安全性が低下
• BLS12-381は128ビット安全なものとして設計される
• BLS12-381のBLS(Barreto-Lynn-Scott)と
BLS署名のBLS(Boneh–Lynn–Shacham)は別物なので注意
• 補足
• 𝐺1 = 𝐺2のペアリング(対称ペアリング)というのもあるがあまり速くない
ペアリング
7 / 13

8. • 集約のナイーブなアイデア
• 𝑠1, 𝑠2, … , 𝑠 𝑛 ; 各メンバー𝐴𝑖の秘密鍵
• 𝑠1 𝑃, 𝑠2 𝑃, … , 𝑠 𝑛 𝑃 ; 𝐴𝑖の公開鍵𝑝𝑘𝑖
• 公開鍵を足す
• 𝑝𝑘 ≔ 𝑝𝑘1 + 𝑝𝑘2 + ⋯ + 𝑝𝑘 𝑛 = 𝑠1 + ⋯ + 𝑠 𝑛 𝑃
• これに対応する秘密鍵𝑠 ≔ 𝑠1 + ⋯ + 𝑠 𝑛はお互い誰も知らない
• Rogue-key攻撃(𝐴 𝑛が攻撃者とする)
• 乱数𝑟を使って自分の公開鍵を𝑝𝑘 𝑛 ≔ 𝑟𝑃 − (𝑝𝑘1 + ⋯ + 𝑝𝑘 𝑛−1)とする
• 公開鍵を足すと𝑝𝑘 = 𝑝𝑘1 + ⋯ + 𝑝𝑘 𝑛 = 𝑟𝑃 ; 𝐴 𝑛は𝑟を知っている
• 対策例 : PoP/KoSK(Proof of possesion/Knowledge of secret key)
• 各𝑝𝑘𝑖を各自の𝑠𝑖で署名させる
• 𝐴 𝑛は𝑝𝑘 𝑛に対応する秘密鍵(𝑟 − 𝑠1 − 𝑠2 − ⋯ − 𝑠 𝑛−1)は知らないので署名できない
Rogue-key攻撃
8 / 13

9. • 楕円曲線ベース
• Schnorr署名の派生バージョン
• BCJ, MWLD, CoSi, MuSig1(MPSW18a),,...
• ペアリングベース
• BLS署名の派生バージョン
いろいろな方式
9 / 13

10. • https://eprint.iacr.org/2018/417
• 既存の楕円曲線ベースの方式に安全性の問題ありと指摘
• ペアリングベースで安全なものを提案
• Compact Multi-Signatures for Smaller Blockchains
• https://eprint.iacr.org/2018/483.pdf
On the Security of Two-Round Multi-Signatures
10 / 13

11. • 前述の論文Table 1
• 𝑛-out-of-𝑛 multisig wallets
• tx=1500, inp=3, n=3
• 今回はMSPを紹介
• 注 : ペアリングの計算は重たい(BLS12-381で0.75msec@core i7-8700)
• スカラー倍算の20倍弱
サイズ比較
11 / 13

12. • 𝐺1 = ⟨𝑃⟩, 𝐺2 = ⟨𝑄⟩, 𝑒: 𝐺1 × 𝐺2 → 𝐺 𝑇
• 𝐻1: 𝑠𝑡𝑟𝑖𝑛𝑔 → 𝐺1
• 鍵生成
• 𝑠 ; 秘密鍵, 𝑝𝑘 = 𝑠𝑄 ; 公開鍵
• 署名
• 𝑚 ; メッセージ, 𝜎 = Sign 𝑠, 𝑚 ≔ 𝑠𝐻1(𝑚)
• 検証
• Verify 𝑝𝑘, 𝑚, 𝜎 = true if 𝑒 𝜎, 𝑄 == 𝑒(𝐻1 𝑚 , 𝑝𝑘)
• ECDSA, Schnorr署名との違い
• 乱数がない決定的アルゴリズム
• 公開鍵と署名がどちらも「秘密鍵 x 楕円曲線の公開点」の形をしている
• Shamirの秘密分散を適用できる
BLS署名
12 / 13

13. • 鍵生成
• 𝑠𝑖 ; 𝐴𝑖の秘密鍵, 𝑠𝑖 𝑄 ; 𝐴𝑖の公開鍵
• 集約
• 𝑎𝑖 ≔ 𝐻 𝑠𝑖 𝑄, 𝑠1 𝑄, … , 𝑠 𝑛 𝑄 where 𝐻: 𝑠𝑡𝑟𝑖𝑛𝑔 → ℤ
• 𝑎𝑝𝑘 ≔ 𝑎1 𝑠1 𝑄 + ⋯ + 𝑎 𝑛 𝑠 𝑛 𝑄
• input : { 𝑠𝑖 𝑄, 𝜎𝑖 } ; メッセージ𝑚に対する𝐴𝑖の署名, 𝜎𝑖 ≔ 𝑠𝑖 𝐻1(𝑚)
• verify each (𝑠𝑖 𝑄, 𝜎𝑖)
• 𝜎 ≔ 𝑎1 𝜎1 + ⋯ + 𝑎 𝑛 𝜎 𝑛
• 検証
• Verify 𝑎𝑝𝑘, 𝑚, 𝜎 = true if 𝑒 𝜎, 𝑄 == 𝑒(𝐻1 𝑚 , 𝑎𝑝𝑘) ; original BLS署名の検証と同じ
• 𝜎 = σ𝑖 𝑎𝑖 𝑠𝑖 𝐻1(𝑚) = σ𝑖 𝑎𝑖 𝑠𝑖 𝐻1 𝑚
• LHS=𝑒 σ𝑖 𝑎𝑖 𝑠𝑖 𝐻1 𝑚 , 𝑄 = 𝑒 𝐻1 𝑚 , σ𝑖 𝑎𝑖 𝑠𝑖 𝑄 =RHS
Multi-Signatures from pairings (MSP)
13 / 13