---
title: "しきい値署名"
description: "しきい値署名では、秘密鍵素材を分散したまま、定足数の参加者が通常の検証可能な署名を生成します。M-of-N、DKG、署名、復旧、運用リスクを解説します。"
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# しきい値署名
> 教育目的のみであり、投資またはセキュリティの助言ではありません。しきい値設計が特定の鍵リスクを軽減するには、プロトコル、実装、参加者、復旧手順を独立して保護する必要があります。
## 直接の回答
しきい値署名方式では、N 人中少なくとも M 人が協力し、単一の公開鍵に対する署名を生成します。M 未満の有効なシェアでは、署名の生成も署名鍵の開示もできないことが要件です。適切な方式なら、通常の署名時に完全な秘密鍵を復元しません。
検証者は通常、その署名形式の標準的な検証アルゴリズムを使います。オンチェーンの署名者一覧ではなく、単一の ECDSA、EdDSA、Schnorr 署名が見える場合があります。互換性が得られる一方、しきい値、参加者、管理の独立性はチェーンから分からないことがあります。
しきい値署名は安全なマルチパーティ計算（MPC）の用途の一つで、同義語ではありません。MPC ウォレットはしきい値署名を利用できますが、MPC には署名以外の計算も含まれます。利用前に秘密を復元するシードの分割も、しきい値署名ではありません。
安全性は、具体的なプロトコル、攻撃者モデル、認証済み通信、乱数、シェア保管、参加者の独立性、ソフトウェア供給網、ポリシーエンジン、復旧設計に依存します。「M-of-N」だけでは安全性評価になりません。
## 仕組み
1. **方式と脅威モデルを選ぶ。** 署名アルゴリズム、M-of-N、参加者、侵害とネットワークの仮定、必要な安全性を固定します。静的侵害に強くても、時間をかけて異なる参加者を侵害する攻撃には弱い場合があります。
2. **鍵素材を分散して作る。** 信頼できるディーラーが秘密を分割する方法と、完全な秘密鍵を組み立てずに分散鍵生成（DKG）でシェアと公開鍵を作る方法があります。DKG はディーラーを除く代わりに、ラウンド、証明、異議処理、障害条件を増やします。
3. **正確なメッセージを承認する。** 各参加者は、チェーン、口座、金額、宛先、手数料、nonce、ポリシーを個別に確認します。暗号学的定足数は取引審査の代わりではありません。
4. **署名プロトコルを実行する。** 選ばれた定足数がコミットメント、証明、署名シェアを交換します。方式固有の nonce は一意に保護し、再利用や偏りを避けます。前処理が必要な方式もあり、FROST は二ラウンドの Schnorr しきい値プロトコルです。
5. **検証し維持する。** 配信前にグループ公開鍵で結果を検証します。その後、必要な記録、障害監視、正式な手順によるシェア更新や鍵ローテーション、しきい値を弱めない復旧テストを行います。
| 設計 | 検証者に見えるもの | しきい値の実施場所 | 主なレビュー範囲 |
| --- | --- | --- | --- |
| しきい値署名 | 一つの署名と公開鍵 | オフチェーン暗号プロトコル | プロトコル、クライアント、シェア、調整役、ポリシー、復旧 |
| オンチェーン・マルチシグ | 複数の承認またはコントラクト状態 | チェーンまたはスマートコントラクト | コントラクト、署名者、しきい値、モジュール、更新権限 |
| 分割バックアップ | 復元後の通常鍵 | 復旧手順 | シェア保管、復元環境、復元後の処理 |
署名方式と安全性モデルごとにプロトコルは異なります。Schnorr 系は線形性により比較的構成しやすいものの、具体的方式が重要です。ECDSA は同じ意味で線形ではないため、しきい値 ECDSA には追加の多者間技術が必要です。集約署名、マルチシグ、しきい値署名は似た出力でも参加条件と安全性主張が異なります。
## 例
取引チーム、独立したリスクチーム、復旧事業者がシェアを持つ 2-of-3 カストディを考えます。通常の出金は取引とリスクの両チームが処理し、一つが使えなくても残りの承認済み組合せで可用性を維持できます。
数だけでは独立性を証明できません。最初の 2 シェアが同じクラウドアカウントで動く、同じ認証トークンを受け入れる、または侵害済みの一つのサービスから判断を受けるなら、一度の事故で定足数が支配されます。脅威モデルに従い、端末、管理者、資格情報、ネットワーク、地域、業者、承認証拠を分離します。
導入前に少なくとも次を試験します。
- 承認済みの各 2 者の組合せが意図したメッセージに署名できる。
- 1 者だけでは署名、鍵復元、参加者差替えができない。
- 重複、順序変更、中止、遅延したセッションで nonce を再利用しない。
- 侵害された調整役がメッセージを変更したり参加者障害を隠したりできない。
- バックアップ復元、シェア更新、参加者交代、完全な鍵ローテーション後も文書化した承認方針が保たれる。
各手順で生成した公開鍵とソフトウェア版を記録します。暗号的に動いても現在の承認方針を迂回する復元シェアは、復旧成功とはいえません。
## リスク
- **相関した侵害：** 別々に見えるシェアが同じ管理者、クラウド、依存関係、署名イメージ、ポリシーサービスに依存します。
- **悪意または侵害された定足数：** M 人の承認参加者が悪意あるメッセージを承認すれば、有効な署名になります。
- **Nonce と乱数の障害：** 再利用、偏り、漏えい、ロールバック、危険な前処理がシェアや実質的な秘密鍵を露出します。
- **プロトコルと実装の不一致：** 一つの方式、群、侵害モデル、セッション仮定の証明は別実装を自動で保証しません。
- **調整役とネットワークの悪用：** 単独署名できなくても、検閲、矛盾送信、メタデータ収集、再送、選択的中止が可能です。
- **可用性障害：** オンラインで互換性があり方針承認済みの参加者が M 未満なら署名できず、窃取しきい値未満でもサービス妨害になります。
- **危険な更新や復旧：** 古いバックアップ、交代、緊急復元がしきい値を下げ、失効シェアを復活させ、全鍵を露出させます。
- **見えないガバナンス：** 鍵ローテーション、許可リスト、更新、復旧管理者は、チェーンに通常署名しか見えなくても強い権限を持ちます。
- **誤った同一視：** BLS 集約、N-of-N マルチシグ、分割シード、M-of-N しきい値署名は、寄与を組み合わせるだけで互換にはなりません。
## よくある誤解
- **「秘密鍵は一度も存在しない。」** 通常運用で組み立てなくても、設定、取込み、バックアップ、移行、緊急復旧では事情が変わります。全ライフサイクルを確認します。
- **「2-of-3 なら単一障害点はすべてなくなる。」** 本当に独立したシェアとサービスの障害だけが対象で、共通基盤や方針は単一障害点を戻します。
- **「チェーン上の署名が一つなら承認者も一人だ。」** 出力は通常、参加人数や承認したオフチェーン方針を示しません。
- **「しきい値署名は不正取引を防ぐ。」** 暗号学的定足数を強制するだけです。共謀または欺かれた定足数は窃取を承認できます。
- **「どの MPC／しきい値ライブラリも全チェーンで使える。」** 署名形式、曲線、ハッシュ、鍵導出、取引符号化、仮定、検証対応を一致させる必要があります。
## 関連トピック
- [MPC ウォレット](/ja/crypto/mpc-wallet/)
- [マルチシグウォレット](/ja/crypto/multisig-wallet/)
- [秘密鍵管理](/ja/crypto/private-key-management/)
- [BLS 署名](/ja/crypto/bls-signature/)
- [Nonce](/ja/crypto/nonce-crypto/)
## 出典
- [NIST First Call for Multi-Party Threshold Schemes](https://csrc.nist.gov/pubs/ir/8214/c/final) - NIST（参照日: 2026-08-21）
- [Threshold Schemes for Cryptographic Primitives](https://doi.org/10.6028/NIST.IR.8214) - NIST（参照日: 2026-08-21）
- [RFC 9591: The FROST Protocol](https://www.rfc-editor.org/rfc/rfc9591.html) - IETF（参照日: 2026-08-21）
- [Digital Signature Standard (DSS)](https://doi.org/10.6028/NIST.FIPS.186-5) - NIST（参照日: 2026-08-21）
- [Fast Multiparty Threshold ECDSA with Fast Trustless Setup](https://doi.org/10.1145/3243734.3243859) - ACM（参照日: 2026-08-21）
Source: https://wiki.fcontext.com/ja/crypto/threshold-signature/index.mdx