ECDSAナンス再利用計算機

SECP256k1 ツール • 暗号技術

ECDSAのNonce再利用から秘密鍵を復元

同じ r 成分を持つ2つの署名から、秘密鍵を計算します。各パラメータを16進数形式で入力してください。

計算結果
-


入力例:

R = d47ce4c025c35ec440bc81d99834a624875161a26bf56ef7fdc0f5d52f843ad1
S1 = 44e1ff2dfd8102cf7a47c21d5c9fd5701610d04953c6836596b4fe9dd2f53e3e
S2 = 9a5f1c75e461d7ceb1cf3cab9013eb2dc85b6d0da8c3c6e27e3a5a5b3faa5bab
Z1 = c0e2d0a89a348de88fda08211c70d1d7e52ccef2eb9459911bf977d587784c6e
Z2 = 17b0f41c8c337ac1e18c98759e83a8cccbc368dd9d89e5f03cb633c265fd0ddc



ビットコインの重大な暗号脆弱性

暗号技術の重大なリスク:Bitcoin取引におけるR値(Nonce)の再利用

わずかな乱数生成の問題によって、Bitcoinの秘密鍵がわずか数ミリ秒で第三者に知られる可能性があります。

Bitcoinのセキュリティは、楕円曲線デジタル署名アルゴリズム(ECDSA)という数学的基盤の上に成り立っています。Bitcoinでは、secp256k1という楕円曲線が使用されています。取引を作成してネットワークへ送信する際、ウォレットは秘密鍵(Private Key)を使って取引に署名し、その資金を使用する権限を証明します。

通常の条件では、この仕組みを現在のコンピューター技術だけで破ることは事実上不可能です。しかし、ウォレット開発において長年問題となってきた、重大な弱点が1つ存在します。それがNonceのR値再利用による脆弱性です。

ECDSA署名の仕組み

BitcoinのECDSA署名は、2つの大きな整数 (r, s) で構成されています。

  • z:署名対象となる取引データのSHA-256ハッシュ値。
  • d:秘密鍵(資金を保護するための重要な秘密情報)。
  • k(Nonce):一度だけ使用される一時的な乱数(Number Used Once)。すべての署名で必ず異なる値を使用する必要があります。
  • r:楕円曲線上の点 $R = k \times G$ のx座標。ここで $G$ は楕円曲線の基準点です。
  • s:モジュラー演算によって計算される署名値。

署名の s 成分を生成する際、ウォレットは次の合同式を計算します。

ECDSA署名の計算式
s ≡ k⁻¹ * (z + r * d) mod n

R値の再利用が危険な理由

Nonceパラメータ k は、完全にランダムであり、絶対に再利用されないことが重要です。

しかし、ウォレットソフトウェアの実装に問題があったり、壊れた疑似乱数生成器(PRNG)を使用したりすると、異なる2つの取引で同じ k が誤って再利用される可能性があります。

$R = k \times G$ であるため、$k_1 = k_2$ になると、必然的に $r_1 = r_2 = r$ となります。その結果、公開ブロックチェーン上に同じR値を持つ2つの署名という明確な痕跡が残ることになります。

数学的な仕組み:秘密鍵の導出

同じ $r$ 値を持つ2つの公開取引が存在すると仮定します。

取引1:s₁ ≡ k⁻¹ * (z₁ + r * d) mod n
取引2:s₂ ≡ k⁻¹ * (z₂ + r * d) mod n

2つ目の式を1つ目の式から引くと、秘密鍵に関係する項 $r \times d$ が相殺されます。

s₁ - s₂ ≡ k⁻¹ * (z₁ - z₂) mod n

モジュラー演算による計算によって、使用されたNonce k を求めることができます。

ステップ1:Nonce(k)の導出
k ≡ (z₁ - z₂) / (s₁ - s₂) mod n

k が求まると、それを元の式に代入することで、秘密鍵(d)を計算できます。

ステップ2:秘密鍵(d)の導出
d ≡ (s₁ * k - z₁) / r mod n

実際の事例とブロックチェーン監視

これは単なる理論上の数学的問題ではありません。Bitcoinネットワークでは、公開された取引をリアルタイムで監視する自動化されたプログラムが存在し、新しくブロードキャストされた取引を継続的に確認しています。

Android SecureRandomの問題(2013年)

Android上のJava SecureRandom 実装に存在した重大な問題により、一部のBitcoinウォレットアプリで同じNonce($k$)が生成される事例が発生しました。その結果、影響を受けたアドレスから大量のBitcoinが不正に移動されました。

Blockchain.infoの問題(2014年)

WebウォレットサービスBlockchain.infoのコード更新に関連して、同じR値を持つ署名が生成される問題が発生しました。この問題を利用して秘密鍵を計算しようとする自動化プログラムが現れ、修正が行われるまでに複数のユーザーアカウントが影響を受けました。

同じ R が再利用された取引が公開メンプールに現れた場合、理論上は署名情報からNonceや秘密鍵を計算できる可能性があります。そのため、Nonceの再利用は秘密鍵の安全性を損なう重大な問題となります。

業界における対策と最新の標準

このような問題を防ぐため、Bitcoinのエコシステムでは主に次の2つの技術が利用されています。

  1. 決定論的Nonce生成(RFC 6979)
    ハードウェアやソフトウェアの乱数生成器だけに依存するのではなく、RFC 6979では秘密鍵と取引ハッシュ(z)をHMAC-SHA256で処理し、Nonce k を決定論的に生成します。
    k = HMAC-SHA256(d, z)
    これにより、同じ署名対象データに対して予測可能な方法でNonceを生成しつつ、実装上の乱数生成の問題によって同じNonceが偶発的に再利用されるリスクを低減できます。
  2. Schnorr署名(BIP 340 / Taproot)
    Taprootのソフトフォークによって導入されたSchnorr署名は、Bitcoinの署名方式をより効率的に扱うための仕組みです。また、BitcoinにおけるSchnorr署名ではNonce生成に関する安全対策も組み込まれており、弱い乱数生成器によるリスクを軽減する設計が採用されています。

まとめ

暗号技術の安全性は、アルゴリズムそのものの複雑さだけでなく、一度だけ使用するパラメータが確実に再利用されないことにも大きく依存します。現在のBitcoin関連アプリケーションを安全に開発するためには、RFC 6979やSchnorr署名など、Nonceの安全な生成を考慮した最新の暗号ライブラリを利用することが重要です。