楕円曲線暗号（ECC）

楕円曲線暗号とは？

楕円曲線暗号（ECC）は、有限体上の楕円曲線の点に関する数学的演算に基づく公開鍵暗号方式です。

暗号資産ネットワークでは、主に公開鍵と秘密鍵のペアの生成、デジタル署名の作成、トランザクションの承認検証、共有秘密の確立、高度な暗号学的証明の実現にECCが使われます。

秘密鍵は、暗号資産アカウントまたは署名用IDを管理する権限を持つ秘密の数値です。

公開鍵は秘密鍵と数学的に関連する値で、他の参加者は秘密鍵を知ることなく署名を検証できます。

ECCの安全性は、主に楕円曲線離散対数問題を解くことの難しさに依存しています。

秘密鍵と選択した生成点があれば、対応する公開鍵を効率的に計算できます。

安全な曲線、鍵長、実装を用いる場合、公開鍵と生成点だけから秘密鍵を復元することは、計算上実行不可能と考えられています。

NISTの楕円曲線暗号プロジェクトでは、デジタル署名や暗号鍵の確立における重要な手法としてECCが説明されています。

ECCは、単一のアルゴリズム、曲線、ブロックチェーン、暗号資産を指すものではありません。

ECDSA、EdDSA、ECDH、Schnorr署名、BLS署名など、さまざまな方式を含む暗号技術の幅広い系統です。

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

暗号資産システムでは、資産を管理する秘密情報を公開せずに、ユーザーがトランザクションを承認できる仕組みが必要です。

デジタル署名によって、ECCはこれを可能にします。

ウォレットは秘密鍵を使ってトランザクションデータに署名します。

ネットワーク参加者は、関連する公開鍵を使って署名が有効かどうかを検証します。

この手順により、必要な鍵によって操作が承認されたことを証明しながら、その鍵自体を公開せずに済みます。

ECCは、比較的小さな公開鍵と署名で強固な古典計算機に対する安全性を実現できるため、広く利用されています。

同程度の安全性を持つ一部の従来型公開鍵方式と比べて、暗号学的な値が小さいことで、トランザクションサイズ、ネットワーク帯域幅、ストレージ要件、検証負荷を抑えられます。

ブロックチェーンでは、何千もの独立したノードが同じ暗号データを保存または検証する場合があるため、こうした効率性は重要です。

楕円曲線とは？

暗号技術で使われる楕円曲線とは、有限体上で定義された方程式を満たす点の数学的集合です。

一般的な短いWeierstrass形式は、

と表されます。

暗号学的計算では、入門図に描かれる滑らかな連続曲線を通常使用しません。

モジュラー演算に従って計算された整数を座標とする、有限個の点を使用します。

曲線のパラメーターによって、有効な点と、点の加算やスカラー倍算などの演算方法が定まります。

完全なドメインパラメーターのセットには、有限体、曲線係数、生成点、生成点の位数、余因子が含まれる場合があります。

安全なシステムでは、任意の曲線方程式を選ぶのではなく、十分に分析されたパラメーターを使う必要があります。

NIST SP 800-186の最終勧告では、対象となる暗号システム向けに、承認済みの楕円曲線ドメインパラメーターが指定されています。

有限体とは？

有限体とは、加算、減算、乗算、除算の規則が定められた有限個の値の集合です。

暗号資産で使われる多くの曲線は、巨大な素数を法として計算する素体上で動作します。

モジュラー演算では、値が体の法に達すると、値が折り返すように処理されます。

これにより、無限の幾何平面ではなく、有限個の座標が作られます。

体と曲線の数学的特性によって、点の演算は構造化された代数群を形成します。

暗号学的安全性を確保するには、既知の数学的攻撃に耐えられる体と群のパラメーターを選ぶ必要があります。

点の加算

点の加算とは、2つの有効な曲線上の点を組み合わせ、別の有効な点を得る演算です。

具体的な計算式は、楕円曲線の形式によって異なります。

点を自分自身に加算する演算は、点の2倍算と呼ばれます。

この加算を繰り返すことで、スカラー倍算の基礎が作られます。

実装では、群の単位元として機能する無限遠点など、特殊なケースも正しく処理する必要があります。

点演算の誤りは、無効な署名の生成、秘密情報の漏えい、悪用可能な例外処理につながることがあります。

スカラー倍算

スカラー倍算とは、指定した回数だけ楕円曲線上の点を自分自身に加算する演算です。

暗号資産では、公開鍵は一般に

として計算されます。

この式で、

は秘密鍵、は曲線の公開生成点、は計算結果の公開鍵です。

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

システムの安全性は、

とからを復元することの難しさに依存しています。

実運用されるライブラリでは、最適化された乗算方式を用いるとともに、タイミング情報やサイドチャネル情報から秘密スカラーが漏れないように対策しています。

楕円曲線離散対数問題

楕円曲線離散対数問題（ECDLP）とは、生成点とその結果得られる公開点が分かっているとき、秘密スカラーを求める問題です。

適切に選ばれた大規模な曲線上のECDLPを解く、効率的な古典アルゴリズムは公に知られていません。

攻撃者は総当たりや高度な数学的手法を試みることができますが、安全な256ビット曲線の場合、必要な計算量は実用的なコンピューティング能力をはるかに超えるはずです。

この主張は、正しい曲線の選択、鍵の生成、検証、実装を前提としています。

乱数生成器が弱かったり、秘密鍵が漏えいしたりすれば、攻撃者はECDLPを解かなくてもシステムを破ることができます。

ECCの秘密鍵

ECCの秘密鍵は通常、曲線の群の位数によって決まる有効範囲内でランダムに選ばれた整数です。

値が0であってはならず、有効範囲外であってもいけません。

256ビット秘密鍵だからといって、任意の256ビット文字列がすべての曲線で自動的に有効になるわけではありません。

ウォレットソフトウェアは、暗号学的に安全な乱数源を用いて値を生成し、曲線の範囲規則を適用する必要があります。

関連アカウントの有効な署名を通常作成できるため、秘密鍵は秘密に保たなければなりません。

同じ有効な鍵を使う正当な所有者と窃盗犯を、ブロックチェーンのコンセンサスが区別することはできません。

ECCの公開鍵

ECCの公開鍵は、選択した楕円曲線上の点です。

秘密鍵からスカラー倍算によって計算されます。

現在の古典計算機に対する安全性の前提では、秘密鍵を明かすことなく公開鍵を共有できます。

暗号資産システムでは、完全な公開鍵、圧縮形式の公開鍵、またはハッシュから生成したアドレスを保存する場合があります。

不正な点による攻撃や部分群攻撃を防ぐため、機密性の高いプロトコルで使う前に公開鍵を検証する必要があります。

検証には、符号化形式の確認、点が想定された曲線上にあることの確認、単位元の拒否、部分群規則の適用などが含まれます。

公開鍵と暗号資産アドレスの違い

暗号資産アドレスは、必ずしも公開鍵と同じものではありません。

多くのシステムでは、公開鍵情報をハッシュ化したり、別の方法で符号化したりしてアドレスを作成します。

これにより、短くて使いやすい識別子が作られ、チェックサム、ネットワーク識別子、スクリプト条件が加えられる場合もあります。

一部のアドレスでは、資金を使用するまで完全な公開鍵が明らかになりません。

別のアカウントシステムでは、トランザクションが行われる前に公開鍵から固定アドレスが生成されます。

アドレスから秘密鍵を復元できると思い込んではいけません。

適切に設計されたアドレス生成プロセスは、実用上、一方向です。

ECCとデジタル署名

暗号資産におけるECCの最も一般的な用途はデジタル署名です。

署名者は秘密鍵を使ってトランザクションデータを処理し、署名を生成します。

他のネットワーク参加者は、対応する公開鍵と同じトランザクションデータを使って署名を検証します。

有効な署名は、必要な秘密鍵が署名対象のメッセージを承認したことを示す証拠となります。

署名後に署名対象データが変更された場合、その変更を検出できます。

署名はトランザクションを暗号化したり、その内容を隠したりするものではありません。

NIST FIPS 186-5「デジタル署名標準」の最終版では、承認済みの署名方式としてECDSAとEdDSAが規定されています。

ECCは暗号化と同じではない

楕円曲線暗号には暗号化や鍵共有に関する方式も含まれますが、暗号資産のトランザクションでは通常、機密性のためではなく署名のためにECCが使われます。

パブリックブロックチェーンでは、残高を検証し、スマートコントラクトを実行し、共有状態を更新するために、通常トランザクションデータを読み取る必要があります。

署名は承認を証明するために使われますが、送信者、送信先、金額、コントラクトへの指示は公開されたままの場合があります。

ECCで暗号化通信向けの共有秘密を確立できますが、これはオンチェーンのトランザクションに署名する操作とは異なります。

楕円曲線暗号が使われているからといって、暗号資産の利用がプライベートだと考えてはいけません。

ECDSAとは？

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

Digital Signature Algorithm（デジタル署名アルゴリズム）を楕円曲線群に適用した方式です。

ECDSAでは、一般に

とと呼ばれる2つの主要な値を含む署名が生成されます。

署名の検証では、署名、メッセージハッシュ、公開鍵、生成点、曲線の位数の間に成り立つ数学的関係を確認します。

ECDSAの安全性は、秘密鍵の保護と、署名ごとに安全で一意な署名ノンスを生成することに依存します。

このアルゴリズムは、暗号資産のトランザクション承認に広く使われてきました。

NISTのECDSAの定義では、楕円曲線を用いたDigital Signature Algorithmの類似方式として説明されています。

ECDSAでノンスが重要な理由

ECDSAの各署名では、一般に

と呼ばれる署名ごとの秘密値が必要です。

同じ秘密鍵を使って異なるメッセージに署名する際、この値を再利用してはいけません。

2つの署名で同じノンスを再利用すると、攻撃者が簡単な代数計算によって秘密鍵を求められることがあります。

偏りのあるノンスや、一部が予測可能なノンスでも、複数の署名から鍵を復元するのに十分な情報が漏れる場合があります。

こうした不具合は、基盤となる楕円曲線が安全なままでも、暗号システムで実際の損失を引き起こしてきました。

現代の実装では、RFC 6979などのレビュー済み手法に従い、秘密鍵とメッセージハッシュから決定論的にノンスを導出することがよくあります。

決定論的なノンス生成でも、正確な実装とサイドチャネル漏えいへの対策が必要です。

secp256k1とは？

secp256k1は、Bitcoin、Ethereumの実行アカウント、その他複数の暗号資産システムで使われる256ビット楕円曲線です。

その素体上の方程式は

です。

この曲線では、係数

、と、標準化された生成点および群の位数が使われます。

名称は、Standards for Efficient Cryptographyシリーズで公開された曲線パラメーターに由来します。

保守が続けられているlibsecp256k1プロジェクトでは、この曲線上の署名や関連演算に特化した実装が提供されています。

secp256k1は、他のすべての256ビット曲線と互換性があるわけではありません。

secp256k1用に作られた鍵や署名は、P-256やEd25519など別の曲線で自動的に検証できるものではありません。

BitcoinとECC

Bitcoinでは従来、secp256k1上のECDSAを使って支出を承認してきました。

トランザクションのインプットには、以前のアウトプットに設定されたロック条件を満たすために必要な情報が含まれます。

通常の署名ベースの条件では、Bitcoinノードは署名が該当するトランザクションデータと公開鍵に一致するかを検証します。

秘密鍵を持っていれば必要な署名を作成できますが、他のスクリプト条件を無視できるわけではありません。

BitcoinではTaprootに関連する支出ルールに、secp256k1上のSchnorr署名も使われます。

BIP-340の仕様では、この用途向けに固定長64バイトのSchnorr署名形式と32バイトの公開鍵エンコーディングが定義されています。

Schnorr署名

Schnorr署名は、楕円曲線群上で動作する別のデジタル署名方式です。

数学的な線形性を持つため、鍵の集約、マルチシグプロトコル、その他の高度な方式に役立ちます。

複数の署名者は、適切に設計されたプロトコルを使って、1つの集約公開鍵と通常の形式に見える1つの署名を作成できます。

すべての公開鍵と署名を個別に公開する場合と比べて、ブロックチェーンデータを削減し、プライバシーを向上させられる可能性があります。

安全に集約するには、なりすまし鍵攻撃、ノンス攻撃、悪意ある参加者の行為を防ぐ、明確に定義されたプロトコルが必要です。

レビュー済みの方式に従わずに公開鍵や署名値を単純に足し合わせるのは安全ではありません。

EthereumとECC

Ethereumの実行アカウントでは、通常のトランザクション署名にsecp256k1上のECDSAを使います。

外部所有アカウント（EOA）のアドレスは、公開鍵から導出されます。

署名により、ネットワークは送信者に対応する公開鍵を復元または検証し、トランザクションが承認されたことを確認できます。

Ethereumの最新のProof of Stake鍵に関するドキュメントでは、実行レイヤーのアカウント鍵は引き続き楕円曲線鍵を使う一方、バリデーターは別の鍵システムを使うと説明されています。

Ethereumのバリデーターの役割では、BLS12-381曲線上のBLS署名が使われます。

したがって、バリデーターの実行鍵とコンセンサス署名鍵は異なる目的を持ち、異なる暗号方式を使用します。

復元可能なECDSA署名

一部の暗号資産システムでは、ECDSA署名に復元情報を含めます。

この情報により、完全な公開鍵を別途送信しなくても、メッセージと署名から対象の公開鍵をソフトウェアが特定できます。

Ethereumの署名では従来、この情報を

、、復元値またはパリティ値として表してきました。

ERC-2098のコンパクト署名標準では、パリティ情報を効率的に使うsecp256k1署名のコンパクトな表現が説明されています。

公開鍵の復元は署名形式の機能であり、秘密鍵を明らかにするものではありません。

EdDSAとは？

EdDSAは、Edwards-Curve Digital Signature Algorithm（Edwards曲線デジタル署名アルゴリズム）の略です。

Twisted Edwards曲線を基盤に設計されたデジタル署名方式の系統です。

EdDSAは、効率的な実装、決定論的署名、一般的な実装ミスへの耐性を実現することを目指しています。

Ed25519は、Curve25519に関連する数学に基づく、広く使われているEdDSAの方式です。

RFC 8032の仕様では、Ed25519および関連するEdwards曲線署名の方式が定義されています。

Ed25519の鍵と署名は、secp256k1 ECDSAの鍵や署名とは互換性がありません。

SolanaとEd25519

Solanaのトランザクションでは、署名が必要なアカウントにEd25519署名を使います。

各トランザクション署名者は、シリアライズされたトランザクションメッセージに対する64バイトのEd25519署名を提供します。

最新のSolanaのトランザクションドキュメントでは、署名の構造と署名者の要件が説明されています。

Solanaは、アプリケーション固有の命令で使うEd25519、secp256k1、secp256r1署名の事前コンパイル済み検証プログラムも提供しています。

複数の検証方式がサポートされているからといって、公開鍵や署名を互いに置き換えられるわけではありません。

ECDHとは？

ECDHは、Elliptic Curve Diffie-Hellman（楕円曲線ディフィー・ヘルマン）の略です。

トランザクション署名アルゴリズムではなく、鍵共有方式です。

2人の参加者が、それぞれ自分の秘密鍵と相手の公開鍵を組み合わせることで、同じ共有秘密を計算します。

公開鍵を見た盗聴者は、ECDLPを解けない限り、その共有秘密を計算できないはずです。

通常、この共有値は鍵導出関数に渡されてから、暗号化や認証に使われます。

ECDHだけでは参加者を認証できないため、認証なしで使用すると中間者攻撃に対して脆弱になる可能性があります。

X25519

X25519は、Curve25519のモンゴメリ形式に基づく、広く利用されている楕円曲線Diffie-Hellman関数です。

共有秘密の確立を効率的に行い、実装を簡素化できるように設計されています。

RFC 7748の仕様では、X25519とX448が定義されています。

X25519は通常の暗号資産トランザクション署名ではなく、鍵共有に使われます。

X25519とEd25519は基盤となる体が関連していますが、鍵の意味は異なるため、安易に変換してはいけません。

BLS署名とペアリングフレンドリー曲線

BLS署名は、双線形ペアリングを使う楕円曲線署名です。

明確に定義された規則の下で、多数の署名や公開鍵を効率的に集約できます。

EthereumのProof of Stakeでは、バリデーターの提案やアテステーションにBLS12-381上のBLS署名を使います。

署名を集約することで、バリデーターごとに個別の署名を公開する場合よりも、多数のバリデーターの投票をコンパクトに表現できます。

BLS12-381決定論的アカウント階層標準では、Ethereumのバリデーター基盤におけるBLS鍵の利用が記載されています。

BLS12-381は、曲線構造、署名アルゴリズム、鍵導出、安全要件の点で、secp256k1やEd25519とは異なります。

異なる楕円曲線は互換性がない

楕円曲線ごとに、方程式、体、生成元、群の位数、余因子、エンコーディング、安全性の前提が異なる場合があります。

secp256k1、P-256、Ed25519、BLS12-381は、それぞれ異なる暗号システムです。

ある種類の公開鍵として有効な32バイト値が、別の方式で解釈すると無効または危険になる場合があります。

開発者は、曲線、署名アルゴリズム、ハッシュ規則、シリアライズ、ドメイン分離を一体として指定する必要があります。

ECCのような一般的な呼称だけでは、2つのアプリケーションの相互運用性を実現できません。

ECCの鍵長と安全性

安全な256ビット素体楕円曲線は、一般に、汎用的な離散対数攻撃に対する約128ビットの古典的安全性に相当するとされています。

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

関連する攻撃モデルにおいて、約

回の演算を試みることに相当する、おおよその作業量を表します。

正確な安全性は、曲線構造、アルゴリズム、実装、乱数生成、攻撃者の能力によって異なります。

攻撃モデルが異なるため、256ビットECC鍵を256ビットの共通鍵暗号鍵と直接比較すべきではありません。

圧縮公開鍵

素体上の楕円曲線の点は、通常、

座標と座標を持ちます。

多くの曲線では、有効な

座標に対して、曲線の方程式から2つの座標が得られます。

そのため、圧縮公開鍵では、

座標と、対応する座標を識別する1ビットまたはプレフィックスを保存できます。

これにより、秘密鍵の探索空間を小さくすることなく、公開鍵のサイズを削減できます。

ソフトウェアは、使用前に点を正しく復元し、検証する必要があります。

BIP-340では、対応する点の選択に関する追加規則を含む、x座標のみを使う公開鍵規約が採用されています。

署名の可塑性

署名の可塑性とは、有効な署名を、同じメッセージと公開鍵に対する別の有効な署名へ変換できる状態を指します。

基本的なECDSAには数学的な対称性があり、互いに関連する

値が生成される場合があります。

暗号資産プロトコルでは、正規形としてlow-

形式を必須にしたり、他のエンコーディング規則を適用したりして、この問題を抑えられます。

可塑性があるからといって、必ずしも攻撃者が承認なしに資金を使えるわけではありません。

トランザクションIDが変わったり、署名のエンコーディングが一意だと想定するシステムが妨害されたりすることはあります。

仕様に従って実装すれば、強い偽造困難性と固定エンコーディングを備えたSchnorr方式は、より明確な非可塑性を実現できます。

鍵の生成とエントロピー

予測可能な情報から生成された秘密鍵は、ECCの数学的な強度では保護できません。

ウォレットは、暗号学的に安全な乱数生成器を使うか、十分なエントロピーを用いて初期化された承認済みの決定論的導出プロセスを使う必要があります。

名前、誕生日、引用文、短いパスワード、ユーザーが選んだ数字のパターンは、安全な秘密鍵ではありません。

故障したハードウェア乱数生成器で作られた鍵は、想定される長さがあっても推測できる可能性があります。

ウォレットは、レビュー済みのエントロピー源を組み合わせ、範囲を検証し、シード生成環境を保護する必要があります。

一般的な表計算ソフトの関数や、暗号用途ではないプログラミング言語の乱数関数で秘密鍵を作成してはいけません。

階層的決定性ウォレット

階層的決定性ウォレットでは、1つのマスターシードから、相互に関連する多数の鍵を導出します。

これにより、ユーザーは1つのシードをバックアップしながら、取引やアカウントごとに別のアドレスを生成できます。

導出システムでは、定められた標準に従い、暗号学的関数と楕円曲線演算が使われます。

一部の導出パスでは、拡張公開鍵から秘密鍵を漏らさずに公開子鍵を生成できます。

拡張公開鍵と漏えいした子秘密鍵を不適切に組み合わせると、一部の非ハード化導出方式では危険が生じる可能性があります。

ウォレット開発者とユーザーは、独自の非公式な鍵階層を設計せず、正確な導出標準に従う必要があります。

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

ハードウェアウォレットは、ECC秘密鍵を専用デバイス内に保存し、その内部で署名計算を行うことができます。

通常、接続先のコンピューターに渡されるのは公開鍵または署名であり、秘密鍵そのものではありません。

これにより、汎用コンピューター上のマルウェアに鍵がさらされるリスクを軽減できます。

ただし、悪意のある送信先やコントラクト呼び出しをユーザーが認識できるよう、デバイスにはトランザクション情報を十分に表示する必要があります。

セキュアエレメントや隔離されたプロセッサーでも、誤解を招くトランザクション情報をユーザーが承認した場合は保護できません。

リカバリーフレーズから別のデバイス上でECC鍵を復元できる場合があるため、リカバリーフレーズも引き続き重要です。

マルチシグと閾値ECC

マルチシグシステムでは、1つの鍵ではなく複数の鍵による承認を求めます。

ブロックチェーンのスクリプトで、複数の独立したECC署名を検証できます。

また、暗号学的な集約方式や閾値プロトコルを使い、複数の参加者が協力して1つの署名を作成することもできます。

MuSig2の仕様では、BIP-340の鍵と署名に対応する対話型マルチシグ方式が定義されています。

閾値方式では、ノンス生成、参加者の識別、トランスクリプトの検証、悪意ある署名者への耐性を慎重に設計する必要があります。

独自の閾値プロトコルは、基盤となる曲線が安全であっても、グループ秘密鍵を漏えいさせる可能性があります。

サイドチャネル攻撃

サイドチャネル攻撃とは、暗号実装の物理的または動作上の挙動から秘密情報を得る攻撃です。

実行時間、消費電力、電磁波の放射、キャッシュの挙動、メモリアクセス、障害への応答などが手掛かりになる場合があります。

秘密鍵のビットごとに異なる処理を行う実装では、数学的に安全なアルゴリズムでも破られる可能性があります。

定時間プログラミングは、観測可能な実行上の違いが秘密データに依存しないようにするための手法です。

ハードウェアウォレットや署名サーバーには、物理的なシールド、障害検知、安全なメモリ、試行回数の制限なども必要となる場合があります。

開発者は、サイドチャネル耐性を考慮して設計・レビューされたライブラリを使う必要があります。

不正曲線攻撃と部分群攻撃

攻撃者は、不正な点や想定外の群に属する点を送り込むことがあります。

ソフトウェアが検証せずにその点に対して秘密鍵演算を行うと、応答から秘密鍵に関する情報が漏れる可能性があります。

小部分群攻撃では、計算を可能な結果が限られる群に誘導できる場合があります。

安全な実装では、選択した曲線とプロトコルに必要な検証規則や余因子の規則を適用します。

現代的な曲線設計ではこの手順の一部が簡素化される場合もありますが、開発者は指定されたデコード規則に従う必要があります。

フォールト攻撃

フォールト攻撃とは、暗号計算中に意図的にエラーを発生させる攻撃です。

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

正常な署名と障害が発生した署名を比較することで、秘密鍵が明らかになる場合があります。

高いセキュリティが求められる署名デバイスでは、計算した署名を返す前に、自ら検証することがあります。

冗長性、障害センサー、堅牢化されたハードウェア、制限されたエラー報告を利用することもできます。

開発者がレビュー済みライブラリを使うべき理由

楕円曲線演算を安全に実装するのは困難です。

開発者が通常のテストに合格するコードを作成しても、タイミング攻撃、不正な点、偏ったノンス、誤った剰余計算、特殊なケースに対して脆弱なままの場合があります。

レビュー済みライブラリは、最適化された演算、テストベクトル、標準化されたシリアライズ、セキュリティ強化を提供します。

開発者は、対象ブロックチェーンで必要とされる正確な曲線とプロトコルに対応したライブラリを使う必要があります。

ライブラリのバージョン、コンパイルオプション、プラットフォーム上の挙動、依存関係の完全性も確認してください。

記事やコード例から短いECC実装をコピーして、本番環境の暗号資産保管に使うのは安全ではありません。

ドメイン分離

ドメイン分離とは、ある目的で作られた署名やハッシュが、別の目的に自動的に再利用されないようにする仕組みです。

プロトコルでは、署名前にネットワーク識別子、アプリケーション名、メッセージ種別、コントラクトアドレス、バージョン、その他のコンテキスト情報を含めることができます。

ドメイン分離がないと、無害なログイン要求として署名されたメッセージが、別の場所で金融取引の承認として解釈される可能性があります。

暗号資産ウォレットは署名対象のドメインを表示し、トランザクションと通常のメッセージを明確に区別する必要があります。

開発者は、対象ブロックチェーンで定められたメッセージのエンコーディングとドメイン分離の規則に従う必要があります。

秘密鍵の再利用

異なるネットワークやアプリケーションで同じECC秘密鍵を使うと、リスクが高まります。

あるアプリケーションの署名実装が弱く、その鍵が漏えいすると、別のアプリケーション上の資産を管理する鍵まで漏れる可能性があります。

システムごとにメッセージのハッシュ化、エンコーディング、検証方法が異なる場合があります。

複数のアプリケーションで鍵を使い回すと、ユーザーの活動を関連付けられやすくなります。

鍵を分けることで、1台のデバイス、ライブラリ、署名プロトコルが侵害された場合の影響を抑えられます。

ウォレットユーザーは、高額資産を管理するシードフレーズを、必要のないアプリケーションにインポートしないようにしてください。

ECCとスマートコントラクト

ブロックチェーンが適切な演算を提供している場合、スマートコントラクトは楕円曲線署名を検証できます。

Ethereumには、

プリコンパイルを通じてsecp256k1署名者を復元するネイティブ機能があります。

他の曲線や証明方式に対応するため、追加のプリコンパイルやコントラクトライブラリを利用できます。

ネットワークに専用のプリコンパイルがない場合、オンチェーンの楕円曲線演算には大きなコストがかかることがあります。

コントラクトは、リプレイ、曖昧なエンコーディング、可塑性のある署名、期限切れの承認、誤った署名者ドメインにも対処する必要があります。

署名の検証で証明されるのは鍵による承認であり、署名された操作が経済的に安全だということではありません。

ECCとゼロ知識証明

多くのゼロ知識証明システムでも楕円曲線が使われています。

ペアリングフレンドリー曲線を使うと、簡潔な証明と効率的な検証が可能になる場合があります。

曲線上の点は、コミットメント、証明の要素、検証鍵を表すために使われることがあります。

証明システムに必要な安全性は、トランザクション署名システムの要件とは異なる場合があります。

通常の署名に適した曲線が、ペアリングベースの証明にも自動的に効率的または安全であるとは限りません。

信頼できるセットアップの前提、回路設計、体の互換性、部分群検査、証明システムの健全性は、それぞれ別に評価する必要があります。

暗号資産におけるECCの利点

ECCは、比較的小さな鍵と署名で、強固な古典的公開鍵暗号の安全性を提供します。

秘密鍵を明かさずにトランザクションを承認できます。

分散型ネットワークの参加者が効率的に検証できます。

鍵共有、署名の集約、閾値署名、コミットメント、ゼロ知識証明の演算にも利用できます。

用途に応じて利用できる、十分に研究された複数の曲線や標準化済みアルゴリズムがあります。

効率性に優れているため、ECCは現代の暗号資産ウォレットやコンセンサスシステムの基盤技術となっています。

ECCの限界

ECCは、実装の誤り、弱い乱数、ノンスの再利用、サイドチャネル漏えいの影響を受けます。

異なる曲線や署名方式に自動的な互換性はありません。

ECCだけで、通常のパブリックブロックチェーントランザクションを暗号化することはできません。

ユーザーが悪意ある送金を承認したり、リカバリーフレーズを漏らしたりすることも防げません。

十分な能力を持つ量子コンピューターによって、安全性の前提が脅かされます。

稼働中のブロックチェーンを別の署名方式へ移行するには、ウォレット、アドレス、ハードウェア、トランザクション形式、スマートコントラクト、コンセンサスソフトウェアの変更が必要になる場合があります。

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

十分に強力な耐故障性量子コンピューターは、Shorのアルゴリズムを使って楕円曲線離散対数を効率的に解ける可能性があります。

その場合、公開鍵から秘密鍵を計算できるため、攻撃者が公開鍵から秘密鍵を導出できるようになります。

現在、実用規模で暗号資産用の全長曲線に対してこの攻撃を実行できると公に確認された量子コンピューターはありません。

ただし、長期にわたって稼働するブロックチェーンシステムは、そのようなハードウェアが利用可能になる前に対策を計画する必要があります。

Ethereumの最新のポスト量子セキュリティガイダンスでは、ECDSA、BLS署名、楕円曲線コミットメントが将来の移行を要する領域として挙げられています。

ECCがすでに破られたという根拠のない主張に慌てるのではなく、公式のプロトコルガイダンスを確認してください。

ポスト量子暗号

ポスト量子暗号では、古典計算機と大規模な量子コンピューターの両方に耐えられると考えられている数学的問題を利用します。

2024年8月、NISTはML-KEMのFIPS 203、ML-DSAのFIPS 204、SLH-DSAのFIPS 205を最終化しました。

NISTのポスト量子標準に関する発表では、移行計画を始めることが推奨されています。

ML-KEMは共有秘密を確立し、ML-DSAとSLH-DSAはデジタル署名を提供します。

これらの方式では、一般に広く使われているECCシステムよりも大きな鍵や署名が必要です。

ブロックチェーンの移行では、セキュリティ、トランザクションサイズ、検証コスト、アドレスとの互換性、長期間利用されていない資金の復旧を考慮する必要があります。

暗号技術のアジリティ

暗号技術のアジリティとは、システム全体を再構築せずに暗号アルゴリズムを置き換えたり、組み合わせたりできる能力です。

アジリティに対応したウォレットは、アカウントを保護する署名方式を識別し、将来の移行手段をサポートできます。

移行期間中、既存のECC署名とポスト量子署名の両方を必要とするハイブリッド署名をプロトコルで使用する場合があります。

スマートアカウントは、署名規則が基盤プロトコルに直接固定されたアカウントよりも柔軟にアルゴリズムを更新できる場合があります。

安全でない移行やダウングレードの経路がシステム全体を弱める可能性があるため、暗号技術のアジリティは慎重に設計する必要があります。

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

開発者は、対象ブロックチェーンまたは標準で求められる正確な曲線とアルゴリズムを選択する必要があります。

十分なレビュー実績があり、保守されている暗号ライブラリを使用してください。

秘密鍵と署名ノンスは、安全な生成プロセスから取得する必要があります。

実装では、公開鍵、曲線上の点、部分群への所属、署名値の範囲、正規エンコーディングを検証してください。

秘密情報に依存する演算では、定時間の手法を使う必要があります。

プロトコルには、明確なメッセージ形式、チェーン識別、アプリケーションのコンテキスト、ノンス管理、リプレイ対策を含めてください。

テストでは、公式テストベクトル、不正な点、無効な署名、境界値、ノンスの不具合、ネットワークをまたいだリプレイ攻撃の試行を検証する必要があります。

高額資産を扱うシステムは、独立した暗号学的レビューと実装レビューを受けるべきです。

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

ユーザーは、信頼できるソフトウェアまたはハードウェアを使い、安全なエントロピーからウォレットを生成してください。

リカバリーフレーズや秘密鍵を、ウェブサイト、メッセージ、サポートフォームに入力してはいけません。

署名する前に、信頼できるディスプレイで重要なトランザクション情報を確認してください。

高額資産は、ハードウェアによる隔離、マルチシグポリシー、支出上限、保管方法の分散によって保護できる場合があります。

1つのシードフレーズを多数のアプリケーションにインポートするのは避けてください。

バックアップは、秘密情報を信頼できないデバイスにさらさずにテストする必要があります。

ウォレットやプロトコルの更新は、検証済みの公式チャネルから入手してください。

ECC署名を使った暗号資産トランザクションの例

AliceがECC秘密鍵によって暗号資産アカウントを管理しているとします。

Aliceのウォレットは、Bobのアドレスにトークンを送るトランザクションを構築します。

ウォレットは、ブロックチェーンの正確な署名規則に従ってトランザクションをシリアライズします。

署名方式の要件に従い、シリアライズされたメッセージをハッシュ化するなどの処理を行います。

ウォレットは、Aliceの秘密鍵と安全な署名ノンスまたは決定論的な署名プロセスを使って署名を作成します。

トランザクションと署名がネットワークにブロードキャストされます。

各検証ノードはAliceの公開鍵を取得または復元し、署名を検証します。

ノードはさらに、Aliceの残高、ノンス、手数料、その他すべてのコンセンサス規則を確認します。

有効なECC署名は、必要な鍵による承認を証明しますが、他のトランザクション有効性チェックに代わるものではありません。

ECCでよくある誤り

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

もう1つは、公開鍵とウォレットアドレスを同じものとして扱うことです。

3つ目は、ECDSA署名ノンスを再利用することです。

4つ目は、一般的な乱数関数で秘密鍵を生成することです。

5つ目は、攻撃者から渡された未検証の公開鍵点を受け入れることです。

6つ目は、すべての256ビット楕円曲線に互換性があると考えることです。

7つ目は、専門家のレビューを受けずに、本番環境の資産保管用に独自の曲線演算を作成することです。

8つ目は、無関係なアプリケーションやネットワーク間で1つの秘密鍵を使い回すことです。

9つ目は、有効な署名があれば署名対象のトランザクションが経済的に安全だと考えることです。

10個目は、移行計画を立てなくてもECCが将来のすべての量子コンピューターに対して安全であり続けると考えることです。

FAQ

暗号資産におけるECCとは何ですか？

ECCは楕円曲線暗号（Elliptic Curve Cryptography）の略です。暗号資産の鍵、署名、鍵共有、高度な証明に使われる公開鍵暗号方式の系統です。

暗号資産におけるECCの主な用途は何ですか？

主な用途は、ブロックチェーントランザクションを承認するデジタル署名の作成と検証です。

ECCは暗号資産のトランザクションを暗号化しますか？

通常は暗号化しません。ほとんどのパブリックブロックチェーントランザクションは暗号化されず、署名されて公開されています。

ECC秘密鍵とは何ですか？

公開鍵の生成と署名の承認に使われる秘密のスカラー値です。

ECC公開鍵とは何ですか？

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

公開鍵から秘密鍵を特定できますか？

安全な曲線と正しい実装を使っている場合、実用的な古典計算機では特定できません。

楕円曲線離散対数問題とは何ですか？

生成点とそこから得られる公開点から、秘密スカラーを復元する困難な数学的問題です。

ECDSAとは何ですか？

暗号資産トランザクションの承認に広く使われている、楕円曲線デジタル署名アルゴリズムです。

secp256k1とは何ですか？

Bitcoin、Ethereumの実行アカウント、その他複数の暗号資産システムで使われる、標準化された256ビット楕円曲線です。

BitcoinはECCを使っていますか？

はい。BitcoinはECDSAにsecp256k1を使い、Taprootの支出にはsecp256k1上のSchnorr署名も使います。

EthereumはECCを使っていますか？

はい。Ethereumの実行アカウントではsecp256k1 ECDSAを使い、Proof of StakeのバリデーターではBLS12-381上のBLS署名を使います。

SolanaはECCを使っていますか？

はい。Solanaのトランザクション署名者はEd25519署名を使います。

Ed25519とは何ですか？

Curve25519に関連するEdwards曲線の数学を用いたEdDSA署名方式です。

Schnorr署名とは何ですか？

安全なプロトコルを通じて実装した場合に、線形性や集約に関する有用な特性を持つ署名方式です。

ECDHとは何ですか？

2者が共有秘密を計算できるようにする楕円曲線の鍵共有方式です。

圧縮公開鍵とは何ですか？

一方の座標と、もう一方の座標を復元するのに十分な情報を保存した、コンパクトな曲線上の点のエンコーディングです。

ECDSAでは一意のノンスが必要なのはなぜですか？

ノンスを再利用したり予測されたりすると、攻撃者が秘密鍵を計算できる場合があるためです。

秘密鍵は推測できますか？

安全に生成された鍵の探索空間は膨大ですが、人が作った弱い鍵や乱数性の低い鍵は推測される可能性があります。

すべてのECC曲線は同じ程度に安全ですか？

いいえ。安全性は、曲線パラメーター、アルゴリズムの設計、鍵長、実装、検証、既知の数学的攻撃によって異なります。

ECC署名をコピーできますか？

データとして署名をコピーすることはできますが、リプレイ対策とメッセージの関連付けによって、別の操作を承認できるかどうかが決まります。

有効な署名があれば安全なトランザクションだと保証されますか？

いいえ。鍵による承認は証明しますが、送信先、コントラクト、価格、金融上の判断が安全であることは証明しません。

ハードウェアウォレットはECC鍵を保護できますか？

鍵と署名操作を隔離できますが、ユーザーは引き続きトランザクション内容を確認し、リカバリーバックアップを保護する必要があります。

マルチシグウォレットでECCを使えますか？

はい。複数のECC署名を検証するか、レビュー済みの集約方式や閾値署名プロトコルを利用できます。

量子コンピューターはECCを破ることができますか？

十分な性能を持つ耐故障性量子コンピューターは、ShorのアルゴリズムでECCを破る可能性があります。ただし、現在、暗号資産規模でこれを実行できると公に知られているコンピューターはありません。

ECCに代わる技術は何ですか？

将来のシステムでは、標準化された格子ベース、ハッシュベース、その他のポスト量子署名方式が使われる可能性があり、移行期間中はECCと併用される場合もあります。

現在、ECCは安全ですか？

適切に選択・実装されたECCは、既知の実用的な古典攻撃に対して引き続き安全です。一方、長期運用されるシステムではポスト量子移行に備える必要があります。

まとめ

楕円曲線暗号は、暗号資産の所有権とトランザクション承認を保護する中核技術の1つです。

秘密鍵と共有可能な公開鍵の間に、一方向の数学的関係を作ります。

デジタル署名方式はこの関係を使い、秘密鍵を明かさずに承認を証明します。

BitcoinはECDSAとSchnorr署名にsecp256k1を使い、Ethereumは実行アカウントにsecp256k1、バリデーターにBLS12-381を使い、Solanaはトランザクション署名にEd25519を使います。

ECCは、鍵共有、マルチシグプロトコル、閾値署名、コミットメント、ゼロ知識証明システムにも利用できます。

安全性は曲線の数学だけでは決まりません。

安全な乱数生成、一意の署名ノンス、公開鍵の検証、定時間の実装、ドメイン分離、安全な鍵の保管、レビュー済みライブラリがすべて不可欠です。

有効なECC署名は、必要な鍵が特定のデータを承認したことを証明しますが、公開トランザクションを暗号化したり、その操作が経済的に安全だと保証したりするものではありません。

適切に実装されたECCは、既知の実用的な古典攻撃に対して引き続き安全ですが、十分な能力を持つ量子コンピューターは、その離散対数の基盤を脅かします。

そのため暗号資産の開発者は、現在の鍵を保護するとともに、ポスト量子暗号への現実的な移行経路を設計する必要があります。