ECDSA（楕円曲線デジタル署名アルゴリズム）

ECDSAとは？

ECDSAは、Elliptic Curve Digital Signature Algorithm（楕円曲線デジタル署名アルゴリズム）の略です。

楕円曲線の数学を用いてデジタル署名を作成・検証する公開鍵暗号アルゴリズムです。

暗号資産ウォレットはECDSAを使い、特定の秘密鍵の保有者がトランザクションを承認したことを証明します。

署名は秘密鍵で作成し、対応する公開鍵を使ってブロックチェーンノードが検証します。

検証の際に秘密鍵を明かす必要はありません。

有効なECDSA署名は、署名作成後に署名対象のトランザクションデータが変更されていないことも示します。

現行のNISTデジタル署名標準では、対象となる連邦政府の暗号アプリケーションで使用する承認済みデジタル署名方式としてECDSAが含まれています。

ECDSAはアルゴリズムであり、ブロックチェーン、ウォレット、暗号資産、暗号化方式、楕円曲線そのものではありません。

完全な実装には、使用する曲線、ドメインパラメーター、ハッシュ関数、秘密鍵生成方式、署名エンコード、メッセージ形式のルールも必要です。

暗号資産でECDSAが使われる理由

分散型暗号資産ネットワークでは、単一の中央アカウントデータベースに依存せず、支出を承認する権限を検証する必要があります。

ECDSAを使うと、ユーザーは秘密鍵を通じてアカウントや使用可能なアウトプットを管理できます。

ユーザーが暗号資産を送るとき、ウォレットはトランザクションを作成し、必要なトランザクションデータに署名します。

ほかのネットワーク参加者は、公開鍵とプロトコルの検証ルールを使って署名を検証します。

現在の古典コンピューティングに関する前提のもと、正しく生成された署名を秘密鍵なしに偽造することは極めて困難です。

これにより、ブロックチェーンノードは不正な送金を拒否しながら、有効なトランザクションを公開ネットワーク上で処理できます。

同程度の古典的セキュリティ強度を持つ古い公開鍵方式と比べて、ECDSAは比較的コンパクトな鍵と署名を生成します。

バイトが増えるたびにネットワーク帯域、ブロックチェーンのストレージ、トランザクションコストが増える可能性があるため、署名の小ささは重要です。

ECDSAは署名アルゴリズムであり、暗号化ではない

ECDSAは承認とメッセージの完全性を証明しますが、署名対象データを隠すものではありません。

ECDSA署名が付いていても、公開暗号資産のトランザクションの多くはブロックチェーン参加者から閲覧できます。

署名によって、送信先アドレス、送金額、トランザクション手数料、スマートコントラクトへの指示が暗号化されることはありません。

暗号化では、読み取れる情報を、復号鍵がなければ読めない暗号文に変換します。

これに対しECDSAは、秘密鍵が特定のメッセージを承認したことを示す数学的な証拠を生成します。

プライバシーを確保するには、別の暗号技術、プロトコル設計、またはアプリケーション上の管理が必要です。

楕円曲線の基礎

ECDSAは、有限体上の楕円曲線の点が形成する数学的群を利用します。

一般的な曲線の形式は

と表され、すべての座標計算を剰余演算で行います。

曲線のドメインパラメーターは、有限体、曲線係数、生成点、生成点の位数、余因子を定義します。

生成点は通常

で表されます。

生成点の位数は通常

で表されます。

安全な実装では、1つのアプリケーションのために新しい曲線を独自に作るのではなく、標準化され、慎重に分析されたパラメーターを使います。

NISTの楕円曲線ドメインパラメーターに関する推奨には、同標準の対象となるアプリケーションで承認された曲線が記載されています。

秘密鍵と公開鍵

ECDSAの秘密鍵は、通常

で表される秘密の整数です。

値は1から

までの有効な範囲から選ぶ必要があります。

公開鍵は、楕円曲線上のスカラー倍算によって求めます。

この関係は通常、

と表されます。

とからを計算することは効率的です。

一方、安全な曲線と適切に生成された鍵を使う場合、

からを復元することは、計算上実行不可能と考えられています。

この一方向性は、楕円曲線離散対数問題の困難さに基づいています。

秘密鍵を入手した人は有効な署名を作成でき、通常は関連する暗号資産を管理できます。

secp256k1とは？

secp256k1は、暗号資産分野でECDSAに最も強く関連付けられている楕円曲線です。

従来型のBitcoinトランザクション署名と、Ethereumの外部所有アカウント署名に使われています。

曲線の方程式は、大きな素数体上の

です。

この曲線の有限体サイズと群の位数は、いずれも256ビットに近い値です。

古典的な汎用離散対数攻撃に対する推定セキュリティ強度は、一般に約128ビットとされています。

secp256k1とNIST P-256は、どちらも一般に256ビットの楕円曲線と呼ばれますが、別の曲線です。

一方の曲線用に作成された鍵や署名を、もう一方の曲線でそのまま検証することはできません。

保守されているlibsecp256k1プロジェクトは、secp256k1向けのECDSA署名、検証、鍵生成、解析、公開鍵復元機能を最適化して提供しています。

ECDSA署名の作成方法

署名処理は、秘密鍵、メッセージ、暗号学的ハッシュ関数、選択した曲線パラメーターを使って行います。

メッセージは、暗号資産プロトコルで定められた正確なシリアライズ規則に従って処理されます。

シリアライズされたメッセージをハッシュ化し、通常

で表されるダイジェストを生成します。

署名者は、一般にノンスと呼ばれ

で表される、署名ごとの秘密値を選びます。

ノンスは、曲線の位数より小さい有効な非ゼロ整数でなければなりません。

署名者は曲線上の点

を計算します。

最初の署名値

は、のx座標から導出し、を法として剰余を求めます。

がゼロの場合、署名者は別のノンスを選ぶ必要があります。

2つ目の署名値は、

として計算します。

がゼロの場合も、別のノンスを選ぶ必要があります。

生成されるECDSA署名は

の組ですが、暗号資産によってはエンコード情報や復元情報が追加されます。

ECDSA署名の検証方法

検証者は、メッセージ、署名、公開鍵、曲線パラメーター、必要なハッシュ規則を使って検証を開始します。

またはが有効範囲外の場合、署名は拒否されます。

検証者は

を計算します。

次に、

およびを計算します。

検証者は曲線上の点

を求めます。

が無限遠点の場合、署名は無効です。

のx座標をを法として剰余計算した値がと一致すると、署名は有効です。

署名の式がメッセージダイジェスト、ノンス、秘密鍵、公開鍵を結び付けるため、この関係が成立します。

検証によって秘密鍵や署名ノンスが明らかになることはありません。

ECDSA署名が証明すること

有効なECDSA署名は、対応する秘密鍵を管理する人が指定されたデータに署名したことを証明します。

また、署名対象のメッセージが変更された場合に検知できます。

署名だけで署名者の法的身元を証明することはできません。

公開鍵と個人または組織との結び付きは、追加の証拠、登録、通信、取引履歴などによってのみ示されます。

盗まれた秘密鍵で作られた署名は、数学的には元の所有者が作成した署名と区別できません。

ブロックチェーンノードが検証するのは暗号技術であり、署名者が自発的に操作したかどうかではありません。

ユーザーが悪意のあるトランザクションに署名した場合でも、その署名は有効です。

ECDSAノンスの重要な役割

署名ノンス

は、ECDSAの中でも特にセキュリティ上重要な要素です。

同じ秘密鍵で異なるメッセージに署名する際、ノンスを再利用してはいけません。

2つの署名で同じノンスを使うと、署名の式に関連情報が十分に含まれるため、ノンスを計算して秘密鍵を復元できる可能性があります。

この場合、攻撃者が楕円曲線離散対数問題を解く必要はありません。

予測可能、一方向に偏っている、または漏えいしたノンスも、十分な数の署名が観測されると鍵の漏えいにつながる場合があります。

選択した楕円曲線が数学的に安全でも、ノンスの不具合によって実際に暗号鍵が侵害された事例があります。

Nonce（ノンス）は「一度だけ使う値」を意味しますが、ECDSAでは一意であることに加え、秘密に保つ必要があります。

決定論的ECDSA

決定論的ECDSAでは、署名のたびに新しい乱数を要求するのではなく、秘密鍵とメッセージダイジェストから署名ノンスを生成します。

RFC 6979の決定論的署名手順では、鍵付きハッシュ構造に基づく広く使われている方法が定義されています。

同じ決定論的手順を使う場合、同じ秘密鍵とメッセージからは通常、同じノンスと署名が生成されます。

これにより、署名処理のたびに別の乱数生成器の品質へ依存する度合いを抑えられます。

決定論的署名を使っても、弱い秘密鍵生成が安全になるわけではありません。

秘密鍵の生成には、依然として十分なエントロピーが必要です。

決定論的実装でも、タイミング攻撃、故障攻撃、メモリ漏えい、誤ったメッセージ処理への対策が必要です。

故障攻撃やサイドチャネル攻撃の一部に対する防御として、決定論的なノンス生成に追加のランダム性を加える実装もあります。

ハッシュが重要な理由

ECDSAでは、任意の長さのメッセージを直接処理するのではなく、通常、暗号学的ダイジェストに署名します。

ブロックチェーンプロトコルは、ハッシュ化の前にどのトランザクション項目を含め、どのようにシリアライズするかを正確に定めています。

署名対象の項目が1つでも変われば、異なるダイジェストが生成され、古い署名は無効になります。

同じECDSA曲線を使っていても、暗号資産ごとに異なるハッシュ関数やトランザクションのコミットメントルールが使われることがあります。

したがって、同じ人間可読のメッセージでも、アプリケーションが異なれば署名結果が異なる場合があります。

曖昧なエンコードによって、同じ署名済みバイト列を2つのシステムが異なる意味に解釈するおそれがあるため、開発者は非公式なシリアライズ規則を独自に作るべきではありません。

安全なプロトコルでは、ある目的の署名が別の目的を承認するのを防ぐため、ドメイン分離も利用します。

ECDSA署名のエンコード

数学的なECDSA署名は、

とという2つの整数で構成されます。

ソフトウェアでは、署名を送信または保存する前に、これらの整数をバイト列にエンコードする必要があります。

一般的な方法の1つに、DER（Distinguished Encoding Rules）があります。

DERでは、構造化されたシーケンス内の整数として値を表現します。

正の整数に先頭のゼロバイトが必要になることがあるため、署名の長さは一定ではありません。

ほかの暗号資産システムでは、

に32バイト、に32バイトを使う固定長のコンパクトな形式が使われます。

数学的には有効な署名でも、バイト列のエンコードがプロトコルの正規形式に違反していれば拒否される場合があります。

BitcoinとECDSA

Bitcoinでは従来、secp256k1上のECDSAを使って多くのトランザクションアウトプットの支出を承認します。

ウォレットは、適用されるスクリプトと署名ハッシュのルールに従って定まる、トランザクション固有のダイジェストに署名します。

Bitcoinノードは、公開鍵、署名、スクリプト条件、その他すべてのコンセンサス要件を検証します。

署名だけでは、入力に十分な価値が含まれていることや、トランザクションがすべてのプロトコルルールに従っていることまでは証明できません。

BitcoinのBIP 66仕様では、対象となるスクリプト操作で検証されるECDSA署名について、厳密なDERエンコードがコンセンサス要件として導入されました。

この変更によってパーサー間の差異が減り、サードパーティー製パーサーの変更によってコンセンサス上の動作が左右されるのを防ぎました。

Bitcoin Taprootの支出では、新しい署名経路にECDSAではなくBIP 340で定義されたSchnorr署名を使います。

従来のECDSAベースのアウトプット形式は引き続き存在し、使用できます。

署名の厳密な解析が重要な理由

コンセンサスソフトウェアは、署名の方程式だけでなく、どのバイト列が有効な署名を表すかについても一致しなければなりません。

あるノードが特殊なエンコードを受け入れ、別のノードが拒否すると、トランザクションやブロックの有効性について意見が分かれる場合があります。

この不一致により、ネットワーク上でブロックチェーンの認識が分裂する可能性があります。

厳密な解析によって、同じ数学的な値を表す別形式のエンコードを排除できます。

暗号資産の実装では、整数の符号、先頭のゼロ、長さ、範囲、末尾のデータを正確に定める必要があります。

コンセンサスに関わる暗号処理では、ソフトウェアのバージョンやプログラミング言語が異なっても、バイト単位で一致する必要があります。

EthereumとECDSA

Ethereumの外部所有アカウントは、secp256k1上のECDSAを使ってトランザクションを承認します。

送信者は、ノンス、送信先、価値、データ、手数料パラメーター、トランザクションタイプなどの項目を確定するトランザクションダイジェストに署名します。

Ethereumの署名には、

との値に加え、公開鍵復元情報が含まれます。

古い説明では復元値を

と呼ぶことがよくありますが、新しいタイプ付きトランザクションでは通常、yパリティ値として表されます。

復元情報により、ソフトウェアは署名とメッセージダイジェストから候補となる公開鍵を導出できます。

その後、アカウントアドレスを導出し、主張されている送信者と照合できます。

EIP-2のプロトコル変更では、通常のトランザクション署名の

値がsecp256k1の曲線の位数の半分を上回る場合に拒否されます。

Ethereumのリプレイ保護

同じ署名済みトランザクションが複数のブロックチェーン環境で受け入れられると、有効な署名が危険につながる場合があります。

EthereumのEIP-155のリプレイ保護設計では、トランザクション署名の過程にチェーン識別子が含まれます。

これにより、承認が特定のチェーン環境に結び付けられます。

最新のタイプ付きEthereumトランザクションでは、トランザクションタイプやチェーン固有の項目も署名対象になります。

オフチェーン署名を要求するアプリケーションにも、独自のドメイン分離、ノンス、有効期限ルール、コントラクト識別子が必要です。

有効なECDSA署名であっても、対象となるメッセージとドメインを理解せずに安全だと判断してはいけません。

公開鍵の復元

標準的なECDSA検証では、検証者があらかじめ公開鍵を知っていることが前提です。

復元可能なECDSAでは、署名とメッセージに対応する公開鍵を特定しやすくする少量の情報を追加します。

署名の方程式の一部を満たす曲線上の点が複数ある場合があるため、復元識別子で対象の候補を示します。

この機能により、一部のトランザクション形式では完全な公開鍵を送る必要性を減らせます。

公開鍵の復元によって秘密鍵が明らかになることはありません。

libsecp256k1のオプションの復元モジュールは、用途に応じてsecp256k1の復元可能な署名に対応します。

アプリケーションでは、復元した鍵、署名の範囲、メッセージ形式、ドメインを引き続き検証する必要があります。

ECDSA署名の可塑性

ECDSAには、数学的に固有の署名可塑性があります。

メッセージと公開鍵に対して

が有効なら、基本的な検証式ではも有効です。

第三者は、秘密鍵を知らなくても代替署名を作成できます。

それによって、攻撃者が別のメッセージに署名したり、追加の資産を支出したりできるわけではありません。

署名バイトを含むトランザクションIDが変わる可能性があります。

プロトコルでは、一般に

値が低い方の署名のみを受け入れるなど、正準形式だけを受け入れることで問題を軽減します。

正準化によって署名の比較や一貫した保存も容易になります。

Low-S署名

Low-

ルールでは、が曲線の位数の半分以下であることを求めます。

署名者がそれより大きな値を計算した場合、

に置き換えられます。

変換後の値も数学的には有効であり、許容される低い範囲に収まります。

EthereumはEIP-2を通じて、通常のトランザクション署名にこのルールを適用しています。

Bitcoinソフトウェアは一般にLow-

へ正規化したECDSA署名を生成しますが、コンセンサスやポリシー上の具体的な扱いは支出の状況によって異なります。

すべてのECDSAシステムが同じ形式を受け入れると考えず、対象プロトコルの正確なルールに従ってください。

ECDSAとSchnorr署名の違い

ECDSAとSchnorrは異なる署名アルゴリズムですが、同じsecp256k1楕円曲線を使うことができます。

Schnorr署名はより単純な線形構造を持ち、効率的なマルチシグや署名集約の構成を可能にします。

基本的なECDSAには、同じように分かりやすい線形集約の性質はありません。

BitcoinのBIP 340仕様では、secp256k1上の固定長64バイトのSchnorr署名が定義されています。

BIP 340では、ECDSAに固有の可塑性と、ECDSAの形式的な分析で使われるより複雑なセキュリティ上の前提についても説明されています。

Schnorrの導入によって、既存のECDSA署名が無効になったり、実際に偽造可能になったりするわけではありません。

新しいプロトコル機能で役立つ性質を持った別の署名設計を提供するものです。

ECDSAとEdDSAの違い

EdDSAは、エドワーズ曲線の数学に基づく別の署名方式群です。

Ed25519は、広く使われているEdDSA方式の1つです。

EdDSAでは、決定論的署名や実装動作の簡素化が重要な目標として設計されました。

Ed25519の鍵は、別途変換設計を使わない限りsecp256k1のECDSA鍵として使えず、安易な変換は安全ではありません。

署名サイズ、公開鍵形式、曲線演算、ハッシュ手順、検証ルールが異なります。

両アルゴリズムに対応するシステムでは、鍵と署名ごとにどちらの方式を使うか明確にする必要があります。

ECDSAとBLS署名の違い

BLS署名は、ペアリングに適した楕円曲線を使い、ECDSAとは異なる数学的性質を持ちます。

定められたセキュリティルールのもとで、多数の署名をコンパクトに集約できます。

EthereumのバリデーターはProof of Stakeのコンセンサス業務にBLS署名を使いますが、通常のEthereum外部所有アカウントはsecp256k1のECDSAを使います。

したがって、バリデーター鍵と実行アカウント鍵は互換性がありません。

BLS集約は、多数の参加者が関連するメッセージに署名する際にデータ量を削減できますが、ペアリング演算と異なる検証要件が必要です。

ECDSAとマルチシグウォレット

ブロックチェーンのスクリプトでは、資産を支出する前に複数の独立したECDSA署名を要求できます。

必要な署名者がそれぞれ個別の署名を作成するため、従来型のマルチシグ設計です。

しきい値ECDSAでは、複数の参加者が連携し、通常のECDSA署名に見える1つの署名を共同で作成する、より複雑なプロトコルを使います。

正しく動作すれば、参加者が完全な秘密鍵を復元する必要はありません。

参加者間でノンス生成を調整し、悪意ある動作に対処する必要があるため、しきい値ECDSAの設計は複雑です。

基本のECDSAアルゴリズムが安全でも、しきい値署名プロトコルに欠陥があれば、共有秘密鍵が漏えいする可能性があります。

本番システムでは、独自のマルチパーティ署名の式を作らず、十分にレビューされたプロトコルを使う必要があります。

ハードウェアウォレットとECDSA

ハードウェアウォレットは、専用デバイス内でECDSA秘密鍵を生成し、保管できます。

デバイスはトランザクションデータを受け取り、確認可能な詳細を表示し、ユーザーの承認後に内部で署名を作成します。

秘密鍵は保護された環境の外に出ないよう設計されています。

この隔離により、接続されたスマートフォンやコンピューター上のマルウェアに直接さらされるリスクを抑えられます。

ユーザーが誤解を招く詳細を承認した場合、ハードウェアウォレットでも悪意のあるトランザクションを安全にすることはできません。

安全なトランザクション表示、ファームウェアの完全性、リカバリーフレーズの保護、サプライチェーンのセキュリティが引き続き重要です。

物理的な測定や意図的なエラーによって秘密の署名値が漏れる場合があるため、サイドチャネル攻撃や故障攻撃への耐性も重要です。

サイドチャネル攻撃

サイドチャネル攻撃とは、ECDSA実装の物理的な動作から情報を取り出す攻撃です。

信号には、実行時間、消費電力、電磁放射、キャッシュアクセス、メモリアクセスのパターンなどがあります。

秘密値に依存する分岐やテーブル参照によって、秘密鍵やノンスに関する情報が漏れる場合があります。

定時間実装では、観測できる動作パターンが秘密値に左右されないようにします。

現行のlibsecp256k1プロジェクトでは、署名と公開鍵生成における定時間処理と定メモリアクセス動作が説明されています。

定時間コードは重要なリスクを抑えますが、物理攻撃、コンパイラー、ハードウェア、オペレーティングシステムに関するすべての攻撃を防ぐわけではありません。

故障攻撃

故障攻撃とは、デバイスがECDSA署名を生成する際に意図的にエラーを起こさせる攻撃です。

攻撃者は、電圧、クロックタイミング、温度、メモリ、計算処理の流れを操作する場合があります。

一部の実装では、故障した署名から秘密鍵を復元するのに十分な数学的情報が得られる可能性があります。

セキュリティ性の高い署名デバイスでは、署名を出力する前に内部で検証する場合があります。

冗長計算、故障センサー、耐タンパー性の高いチップ、制限されたエラーメッセージを使うこともあります。

署名デバイスに物理的に触れられる状態は、常に重要なセキュリティ事象として扱う必要があります。

無効な公開鍵と曲線上の点

ECDSA検証では、任意のバイト列を公開鍵として無条件に受け入れてはいけません。

エンコードが有効か、その点が想定した曲線上にあるかを確認する必要がある場合があります。

無限遠点を拒否し、必要な部分群チェックを適用してください。

秘密鍵演算で攻撃者が制御する無効な点を使うと、無効曲線攻撃や小部分群攻撃につながる可能性があります。

正確な検証要件は、曲線、プロトコル、演算によって異なります。

レビュー済みの暗号ライブラリを使う方が、独自の簡易実装よりも安全にこうした詳細を扱えます。

秘密鍵の生成

ECDSA秘密鍵は、暗号学的に安全なエントロピー源から生成する必要があります。

人が選んだフレーズ、誕生日、引用句、繰り返し数字、一般的な乱数関数は安全ではありません。

鍵は、選択した曲線の有効なスカラー範囲内にある必要もあります。

256ビットに見える値だからといって、安全に生成された秘密鍵とは限りません。

ウォレットでは、階層的決定性導出方式を使い、マスターシードから複数のECDSA鍵を導出することがよくあります。

マスターシードを入手した人は、そこから導出されたすべてのアカウントを再現できる場合があります。

ECDSA自体の安全性で、漏えいまたは予測可能なリカバリーフレーズを補うことはできません。

ECDSAとウォレットアドレス

公開鍵と暗号資産アドレスは、常に同じものとは限りません。

Bitcoinアドレスでは、公開鍵情報に関連するハッシュやスクリプト条件が一般にエンコードされます。

Ethereumアドレスは、非圧縮形式のsecp256k1公開鍵のハッシュの一部から導出されます。

アドレス形式には、ネットワーク識別子や誤り検出情報が追加される場合があります。

ウォレットでは、1つのマスターシードから異なる導出パスを使って複数のアドレスを表示することがあります。

すべてのプロトコル上の状態で、アドレスを知れば完全な公開鍵が分かると考えてはいけません。

公開鍵を知っていても、鍵と曲線が安全であれば、古典的な方法で秘密鍵を復元することは現実的ではありません。

トランザクション署名とメッセージ署名

トランザクション署名は、プロトコルで定められたルールに従ってブロックチェーン上の操作を承認します。

メッセージ署名は、ブロックチェーントランザクションを直接送信せずに、鍵を管理していることを証明する場合があります。

ウォレットへのログイン要求、トークン承認、注文、ガバナンス投票、Permitメッセージなどは、いずれもECDSA署名を使う場合があります。

オフチェーン署名でも、後でスマートコントラクトやサービスに送信されれば、価値のある操作を承認する場合があります。

「ログイン」と説明された要求でも、実際の署名データが資産移転の権限を与える場合は危険です。

可能な限り、ウォレットには署名ドメイン、コントラクト、チェーン、ノンス、有効期限、人間が読める操作内容を表示する必要があります。

説明のないデータや想定外の権限を含む署名は拒否してください。

リプレイ攻撃

リプレイ攻撃とは、署名者が適用を意図していない別の環境で、有効な署名を再利用する攻撃です。

攻撃者は署名を偽造するわけではありません。

メッセージとの結び付けが不十分であることを利用します。

安全な署名済みメッセージには、チェーン識別子、アカウントのノンス、コントラクトアドレス、アプリケーションのドメイン、操作タイプ、有効期限などが含まれます。

一度限りのノンスを使うと、同じアプリケーション内で同じ承認を繰り返し使用できなくなります。

開発者は、承認済みの操作が正常に完了した後にのみノンスが消費されることを確認する必要があります。

実装上の誤り

ECDSAの不具合は通常、楕円曲線離散対数問題を直接解くことではなく、実装や鍵管理上の誤りから生じます。

よくある問題には、ノンスの再利用、偏った乱数、無効な鍵の受け入れ、誤ったハッシュ化、曖昧なシリアライズ、範囲チェックの不足、安全でない署名解析などがあります。

ほかにも、サイドチャネル、故障攻撃、デバッグログの漏えい、依存関係の侵害、メモリ漏えいが原因となる場合があります。

広範なテストがあり、セキュリティモデルが明確な、保守されているライブラリを使ってください。

小さなミスで鍵に保護されたすべての資産が危険にさらされる可能性があるため、暗号コードは通常のアプリケーションコードとは別にレビューする必要があります。

独自のECDSAコードが危険な理由

ECDSAの式は単純に見えるため、短いプログラムで実装できるように思える場合があります。

しかし、本番環境で安全に使うには、署名と検証の式を再現する以上の対策が必要です。

実装では、定時間スカラー演算、安全な逆元計算、正確な剰余計算、厳密な解析、点の検証、安全なメモリ管理が必要です。

ゼロ値や無効な点など、まれなケースも正しく処理しなければなりません。

通常の署名テストをいくつか通過したプログラムでも、タイミングやノンスの偏りを通じて秘密鍵を漏えいさせる場合があります。

暗号資産のカストディにチュートリアルのコードを流用せず、確立されたライブラリと公式のテストベクトルを使ってください。

ECDSAのセキュリティ強度

ECDSAのセキュリティは、曲線、ハッシュ関数、秘密鍵のエントロピー、ノンス生成、実装の強度に左右されます。

安全な256ビット楕円曲線は、古典的なセキュリティ強度が約128ビットと一般に考えられています。

これは、攻撃者が鍵を推測する確率が128分の1という意味ではありません。

関連する攻撃モデルにおける計算作業量のおおよその目安です。

ハッシュ関数も、プロトコルのセキュリティ目標に応じた衝突耐性と原像計算耐性を備える必要があります。

運用上の管理が不十分だと、実用上のセキュリティは数学的な強度を大きく下回る場合があります。

ECDSAと量子コンピューティング

ECDSAは、十分な性能を持つフォールトトレラント量子コンピューターに対して安全とは考えられていません。

Shorのアルゴリズムで楕円曲線離散対数問題を解くことができれば、公開鍵から秘密鍵を復元できる可能性があります。

現在、暗号資産規模で実用的にsecp256k1のECDSAを破れる量子コンピューターは公表されていません。

プロトコルのアップグレード、ウォレットの変更、休眠資産の移動には何年もかかる場合があるため、長期運用されるブロックチェーンシステムには移行計画が必要です。

暗号技術に関係する量子ハードウェアが開発された場合、すでにオンチェーンで公開されている公開鍵が優先的な標的になる可能性があります。

現在のECDSAがすでに破られているとする根拠のない主張には注意してください。

耐量子署名の代替方式

耐量子デジタル署名は、古典コンピューターと大規模な量子コンピューターの両方に耐えると考えられる数学的問題に基づいています。

NISTは2024年8月に、ML-DSAに関するFIPS 204およびSLH-DSAに関するFIPS 205を最終化しました。

これらの署名方式は、ECDSAとは鍵サイズ、署名サイズ、計算コスト、実装要件が異なります。

ブロックチェーン上でECDSAを置き換えるのは、ウォレットライブラリを1つ変更するだけで済む作業ではありません。

移行によって、アドレス形式、トランザクションサイズ、ハードウェアウォレット、スマートコントラクト、ネットワーク検証、アカウント復旧、休眠資産に影響が及ぶ場合があります。

一部のプロトコルでは移行期間にハイブリッド方式を使い、既存のECDSA署名と耐量子署名の両方を要求する場合があります。

開発者がECDSAを安全に使う方法

開発者は、対象プロトコルが要求する曲線、ハッシュ関数、メッセージ形式、署名エンコードを正確に使う必要があります。

秘密鍵は、暗号学的に安全な生成または導出プロセスで作成してください。

署名ノンスには、レビュー済みの決定論的方式、または同等の保護を備えた安全な乱数設計を使います。

ライブラリでは、プロトコルに必要な厳密な署名解析、スカラー範囲の確認、公開鍵の検証、正準化を行う必要があります。

秘密鍵を扱う処理には定時間実装を使ってください。

アプリケーションでは、ドメイン分離、リプレイ保護、分かりやすいトランザクション表示、適切なノンス管理が必要です。

テストには、無効な署名、High-

形式、不正なエンコード、ゼロ値、改変されたメッセージ、異なるネットワーク、承認の再利用を含めてください。

高価値のシステムには、独立した暗号技術および実装の監査が必要です。

暗号資産ユーザーがECDSA鍵を保護する方法

信頼できるソフトウェアまたは専用の署名ハードウェアでウォレットを作成してください。

リカバリーフレーズと秘密鍵はオフラインで保管し、サポート担当者やウェブサイトと共有してはいけません。

署名する前に、信頼できる画面でトランザクションの詳細を確認してください。

送信先アドレス、ネットワーク、金額、手数料、コントラクト、権限の範囲を確認してください。

高額資産は、マルチシグポリシー、分散バックアップ、ハードウェアによる隔離、用途を分けたウォレットで保護できます。

1つのリカバリーフレーズを、不要なアプリケーションにインポートしないでください。

多くのブロックチェーンシステムでは、有効な署名は取り消せない承認の証拠となるため、事後の復旧より予防が確実です。

ECDSAでよくある誤り

よくある誤りの1つは、ECDSAが暗号資産のトランザクションを暗号化すると考えることです。

もう1つは、公開鍵が常にウォレットアドレスと同一だとみなすことです。

3つ目は、2つのメッセージで同じ署名ノンスを再利用することです。

4つ目は、一般的な乱数関数を使って秘密鍵やノンスを生成することです。

5つ目は、厳密に解析せず、非正準または不正な署名を受け入れることです。

6つ目は、基本的なECDSAの式で

との両方が有効になり得ることを忘れることです。

7つ目は、署名するデータのネットワーク、ドメイン、ノンス、有効期限を確認しないことです。

8つ目は、無関係なアプリケーションやブロックチェーンで同じ秘密鍵を使うことです。

9つ目は、専門家によるレビューなしに、本番ウォレット向けの独自楕円曲線コードを書くことです。

10個目は、有効な署名があれば、トランザクションが安全、公平であり、鍵の本来の所有者の意図に沿っていると考えることです。

よくある質問

ECDSAは何の略ですか？

ECDSAはElliptic Curve Digital Signature Algorithm（楕円曲線デジタル署名アルゴリズム）の略です。

暗号資産でECDSAは何に使われますか？

ブロックチェーントランザクションやその他のウォレット操作を承認する署名の生成と検証に使われます。

ECDSAはトランザクションを暗号化しますか？

いいえ。ECDSAは承認と完全性を証明しますが、通常の公開ブロックチェーンデータを隠しません。

ECDSA秘密鍵とは？

署名の作成と対応する公開鍵の導出に使う秘密の整数です。

ECDSA公開鍵とは？

秘密鍵から導出され、署名の検証に使われる楕円曲線上の点です。

BitcoinのECDSAで使われる曲線は何ですか？

Bitcoinの従来型ECDSAトランザクション署名では、secp256k1楕円曲線が使われています。

Ethereumのアカウント署名で使われる曲線は何ですか？

Ethereumの外部所有アカウントでは、secp256k1上のECDSAが使われています。

ECDSAのrとsとは？

ECDSA署名を構成する2つの整数値です。

ECDSAノンスとは？

署名生成時に使う、署名ごとの秘密スカラー値です。

ECDSAノンスを再利用してはいけない理由は何ですか？

異なるメッセージに対してノンスを再利用すると、観測者が秘密鍵を計算できる場合があります。

決定論的ECDSAとは？

RFC 6979などの定められた手順に従い、秘密鍵とメッセージダイジェストからノンスを導出する署名方法です。

決定論的ECDSAを使えば乱数は不要ですか？

いいえ。元となる秘密鍵には引き続き十分なエントロピーが必要であり、実装は故障やサイドチャネルから保護されなければなりません。

ECDSA署名の可塑性とは？

同じメッセージと公開鍵に対し、

との両方が有効となり得る性質です。

Low-S署名とは？

値が曲線の位数の半分以下である、正準形式のECDSA署名です。

DERエンコードとは？

ECDSA署名の

およびの整数を表現するためによく使われる、構造化されたバイナリエンコードです。

ECDSA署名から秘密鍵が漏れることはありますか？

正しく生成された署名から秘密鍵が漏れることはないはずですが、ノンスの再利用、偏ったノンス、サイドチャネル、実装の誤りによって漏えいする場合があります。

ECDSAで失われた秘密鍵を復元できますか？

できません。署名や公開鍵から、安全に生成された秘密鍵を実用的に復元する方法はありません。

ECDSA署名を偽造できますか？

安全なパラメーター、鍵、ノンス、ハッシュ、実装が使われていれば、偽造は計算上実行不可能と考えられています。

ECDSAはECCと同じですか？

いいえ。ECCは楕円曲線暗号の総称で、ECDSAはその中のデジタル署名アルゴリズムの1つです。

ECDSAはSchnorrと同じですか？

いいえ。どちらもsecp256k1上で動作する場合がありますが、別の署名アルゴリズムです。

TaprootはECDSAを使いますか？

Taprootの新しい署名経路では、ECDSAではなくBIP 340のSchnorr署名を使います。

スマートコントラクトはECDSA署名を検証できますか？

できます。多くのブロックチェーン環境では、secp256k1のECDSA署名を検証するネイティブ機能またはライブラリを利用できます。

有効なECDSA署名は法的身元を証明しますか？

いいえ。別の証拠で鍵と法的身元が結び付けられない限り、証明するのは秘密鍵を管理していることです。

有効な署名があればトランザクションは安全ですか？

いいえ。ユーザーは、悪意のある送金、無制限の承認、欺瞞的な注文、安全でないスマートコントラクト操作にも有効に署名できます。

量子コンピューターはECDSAを破れますか？

十分な性能を持つフォールトトレラント量子コンピューターであれば破れる可能性がありますが、現在、暗号資産規模で実行できる公開済みのシステムはありません。

現在もECDSAは安全ですか？

適切に実装されたECDSAは、安全な鍵とノンスを使う限り、既知の実用的な古典攻撃に対して耐性があります。

まとめ

ECDSAは、秘密鍵を公開せずに暗号資産トランザクションを承認するために使われる、基盤的なデジタル署名アルゴリズムです。

秘密スカラー、楕円曲線上の公開鍵、メッセージダイジェスト、秘密の署名ノンスを組み合わせ、

との署名値を生成します。

ブロックチェーンノードは、署名された操作を受け入れる前に、これらの値を数学的に検証します。

Bitcoinは従来、secp256k1上のECDSAを使い、Ethereumの外部所有アカウントも同じ曲線と公開鍵復元情報を使います。

厳密なエンコード、Low-

ルール、チェーン識別子、メッセージドメイン、リプレイ保護によって、暗号資産プロトコル内のECDSAの安全性を高められます。

実務上、ECDSAの最大の弱点は楕円曲線の数学そのものではなく、実装や鍵管理の誤りです。

ノンスの再利用、弱い乱数、リカバリーフレーズの漏えい、サイドチャネル、無効な点の処理、分かりにくい署名要求は、強固な数学的基盤を損なうおそれがあります。

開発者は、レビュー済みライブラリ、決定論的ノンス手順、定時間処理、厳密な検証、正確なプロトコル仕様に依拠する必要があります。

ユーザーはリカバリー情報を保護し、信頼できる署名画面で各トランザクションやメッセージを確認してください。

ECDSAは正しく実装されていれば、既知の実用的な古典攻撃に対して引き続き安全ですが、長期運用される暗号資産システムでは耐量子署名技術への移行準備が必要です。