【入門編】 ECDSAにおけるnonceの再利用とハッシュ値の漏洩リスク – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

こんにちは！日々の開発やインフラの保守、本当にお疲れ様です。セキュリティの世界へようこそ！

「認証基盤や暗号」という言葉を聞くと、なんだか数学の博士号を持っているような天才だけが扱う難解な領域に思えてしまいますよね。でも大丈夫です。私たちが毎日使っているパスワードの保存方法や、アプリの安全性を守る技術は、身近な防犯の仕組みと全く同じ考え方で成り立っています。

今回は、現代のWebや仮想通貨、API通信などで引っ張りだこな暗号技術「ECDSA（楕円曲線暗号署名）」の、ちょっと怖くて面白い「秘密の弱点」についてお話しします。

「nonce（ナンス）の再利用」という、一見すると呪文のような言葉を、家の鍵泥棒の例えを使って一緒に優しく解きほぐしていきましょう。一歩ずつ、確実に理解できるように進めていきますね！

—

1. 身近な例え：なぜECDSAの署名は「使い捨ての合言葉」が必要なのか？

まずは、ECDSAがやっていることを身近な例えでイメージしてみましょう。

想像してください。あなたは自分の部屋（サーバー）のドアに、特別な「署名スタンプ（秘密鍵）」を持っています。
あなたが作った手紙（データ）にそのスタンプを押して外に出すと、受け取った人（クライアント）は、あなたの公開用プレート（公開鍵）を使って、「おっ、これは本当に本人から届いた本物の手紙だな！」と確認できます。これがデジタル署名（ECDSA）の基本的な仕組みです。

ここで問題があります。
もし、あなたが手紙を書くたびに「完全に同じ押し方、同じ力加減」でスタンプを押していたらどうでしょうか？
あるいは、手紙の端っこに、毎回「使い回しのランダムな数字（これをECDSAでは nonce と呼びます）」を書き込んでいたとしたら……？

優秀な泥棒は、こう考えるのです。
「あれ？この人とこの人がやり取りした手紙、署名のパターンが完全に一緒だぞ。……ということは、この裏で使われている『使い捨てのランダムな数字（nonce）』を、こいつは同じものフライングで使い回しているな？」

恐ろしいことに、ECDSAの数学的な仕組み上、この nonce を1回でも使い回してしまったり、その中身が外に漏れてしまったりすると、あなたの命綱である「秘密鍵（スタンプそのもの）」が完全に敵に逆算されてしまうのです。

スタンプが盗まれたら最後、泥棒はあなたの部屋の合鍵を自由自在に作り放題になってしまいますよね。これが「nonce の再利用リスク」の正体です。

—

2. 攻撃のメカニズム：なぜ nonce が被ると秘密鍵がバレるのか？

もう少しだけ技術的な裏側を覗いてみましょう。とはいえ、数式は一切使いませんので安心してくださいね。

ECDSAで署名を作るとき、私たちは毎回「その時だけのランダムな値（nonce）」を生成します。英語の Number used once（1回だけ使われる数字） を略して nonce と呼ばれています。

本来、この nonce は、

1. 署名を作るたびに、
2. 絶対に他人（あるいは自分自身でも）に予測されず、
3. 2回以上同じ値が使われない（重複しない）

ものでなければなりません。

もし、不具合のあるプログラムや乱数生成器（擬似乱数のバグなど）のせいで、異なる2つのデータに対してまったく同じ nonce を使って署名を作ってしまったとします。

攻撃者は、その「2つの署名データ」を手に入れた瞬間、高校の数学でやったような「連立方程式」を解く要領で、あなたの「秘密鍵」をものの数秒で割り出してしまうのです。

実際に過去、古いゲーム機や暗号通貨のウォレットアプリで、乱数生成器が壊れて同じ nonce を連発してしまった結果、全財産をごっそり盗まれるというインシデントが起きています。笑い事ではなく、実務において非常に致命的なバグになり得るのです。

—

3. 決定論的ECDSA（RFC 6979）という救世主

「じゃあ、プログラムの乱数生成器（rand関数など）がバグったら終わりじゃないか……人間の手で毎回ランダムを担保するなんて無理だよ！」

そう思いましたよね。その通りです。人間の実装ミスや、OSの乱数プールの枯渇に頼っていると、いつか必ずこの罠にハマります。

そこで登場したのが、「決定論的ECDSA（RFC 6979）」という天才的なアプローチです。

「ランダム（運任せ）にするからバグるんだ。だったら、『秘密鍵』と『送信するメッセージのハッシュ値』を混ぜ合わせて、毎回必ずユニーク（一意）だけど、他人からは予測不可能な nonce を計算で作り出せばいいじゃないか！」

これが決定論的ECDSAの仕組みです。
これなら、乱数生成器の調子が悪かろうが、同じメッセージと秘密鍵の組み合わせであれば、常に同じ安全な nonce が綺麗に導き出されます。そして、メッセージが変われば nonce も完全に変わるため、「nonce の再利用」というミスが構造的に起こらなくなるのです。

現代のまともなセキュリティライブラリやブロックチェーンのSDKは、大体この RFC 6979 を標準で採用しています。

—

4. 実務での実装例とチェックポイント

それでは、現場のエンジニアとして、私たちが書くコードやインフラで何を気をつければいいのかを見ていきましょう。

今回は、モダンな言語（例としてPHPやNode.js、Pythonなど）で暗号署名を扱う際の、実務的なポイントとサンプルコードの考え方をご紹介します。

開発・インフラにおけるチェックポイント

1. 古い自前実装を絶対に使わない：ECDSAの計算や曲線のパラメータ（secp256k1 や prime256v1 など）を自分でスクラッチから書こうとしてはいけません。必ず信頼できる標準ライブラリ（OpenSSL, libsodium, cryptography 等）を使いましょう。
2. nonce を手動で指定しない：多くの高水準ライブラリは、内部で自動的に安全な乱数、あるいは決定論的な nonce 生成（RFC 6979）を行ってくれます。もし引数に nonce を手動で渡すような設計になっているAPIを見かけたら、レッドフラッグ（危険信号）だと思ってください。
3. 乱数生成器（CSPRNG）の健全性を保つ：もし決定論的ではない従来のECDSAを使うシステムを運用している場合は、OSの暗号学的擬似乱数生成器（Cryptographically Secure Pseudorandom Number Generator）が正常に機能しているか、コンテナの熵（エントロピー）枯渇問題が起きていないかを監視しましょう。

実装イメージ（Pythonの cryptography ライブラリの例）

PythonでECDSA署名を安全に行う典型的なコードを見てみましょう。このように、ライブラリ側が裏側で適切に処理してくれるものを選ぶのが鉄則です。

import os
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives.asymmetric.utils import encode_dss_signature

# 1. 秘密鍵を安全に生成する（楕円曲線は一般的な secp256r1 を使用）
# ※秘密鍵は絶対にソースコードにハードコードせず、環境変数やKMSから安全に読み込みます。
private_key = ec.generate_private_key(ec.SECP256R1())

# 2. 署名対象のメッセージ（データ）
message = b"Important transaction data for security check."

# 3. ECDSAによる署名の生成
# ここでライブラリが内部的に安全な（多くは決定論的な）nonceの処理を行ってくれます。
# 開発者が手動でnonceを意識・操作する必要はありません。
signature = private_key.sign(
    message,
    ec.ECDSA(hashes.SHA256())
)

print(f"生成された署名（バイト列）: {signature.hex()}")

# 4. 検証側（公開鍵を使って正当性をチェック）
public_key = private_key.public_key()
try:
    public_key.verify(
        signature,
        message,
        ec.ECDSA(hashes.SHA256())
    )
    print("【検証成功】この署名は正当な秘密鍵によって生成されました。")
except Exception as e:
    print(f"【検証失敗】署名が不正であるか、データが改ざんされています: {e}")

このように、信頼できるライブラリの標準的な関数（上記の sign メソッドなど）を正しく呼び出すことが、泥沼の脆弱性を防ぐ一番の近道です。

—

5. まとめ：安全な認証基盤を築くために

今回は、ECDSAにおける nonce の再利用リスクと、それを防ぐ決定論的ECDSA（RFC 6979）の仕組みについてお話ししました。

nonce の使い回しは、秘密鍵を自ら泥棒に差し出すようなもの
運任せの乱数生成器に頼るのではなく、RFC 6979などの「決定論的アプローチ」が現代のデファクトスタンダード
車輪の再発明（自前の暗号実装）をせず、信頼された実績のあるライブラリを正しく使う

セキュリティの世界は一見すると複雑で冷たく感じられますが、一つひとつの技術背景にある「なぜそうなっているのか（ストーリー）」を理解すれば、怖くありません。むしろ、非常にロジカルで美しい仕組みに満ちています。

日々の開発の中で「お、このライブラリはどうやって安全なランダムを作っているんだろう？」と少し立ち止まってみる、その好奇心こそが、あなたを最高のエンジニアへと導いてくれます。

それでは、また次回のセキュリティ解説でお会いしましょう！安全なコードライフを！