ディジタル署名 ─ ハッシュ + 公開鍵の合わせ技

学習目標

本講を終えると、以下を達成できるようになります。

• ディジタル署名と MAC・暗号化の違いを、提供する性質(機密性・完全性・認証・否認防止)で区別できる
• 署名の標準パターン「ハッシュで縮める → 秘密鍵で署名 → 公開鍵で検証」を図示できる
• 主要方式 RSA-PSS / ECDSA / Ed25519 の特徴と使い分けを述べられる
• X.509 証明書と CA 階層がディジタル署名でどう成立しているかを説明できる
• コードサイニング(macOS notarization、Windows Authenticode、署名付き Linux パッケージ)の仕組みを把握する
• OpenSSL で openssl dgst -sign / -verify を使って署名生成・検証できる
• PQC 署名(Dilithium / SPHINCS+)が量子時代の標準になる流れを理解する

このレッスンの目次

ディジタル署名とは ─ MAC との決定的な違い

MAC vs ディジタル署名 ─ 改めて整理

なぜ「否認防止」が成立するのか

署名鍵(秘密鍵)は 署名者しか持っていない。検証は誰でもできる(公開鍵が公開されているから)。だから「正しく検証できる署名」が存在する = その秘密鍵の持ち主(本人)が署名した と数学的に保証されます。これが法的に「電子署名」として通用する根拠で、日本の電子署名法(2001 年)、EU の eIDAS 規則(2014 年)などはこの暗号原理に立脚しています。

つながる知識: 否認防止が成立するには 秘密鍵が本人だけに保持されている 前提が必要。盗難・漏洩があれば成立しない。だから HSM(Hardware Security Module)、TPM、Secure Enclave(Apple)、YubiKey などのハードウェア鍵管理が重要視されます。

標準的な署名スキーム ─ ハッシュ + 公開鍵

署名の流れを図で

図の見方:メッセージは平文で運ばれる(暗号化したいなら別途行う)。重要なのは「署名」だけが秘密鍵で作られ、それを公開鍵で検証する流れ。改ざんされたら h' が変わって検証失敗、偽造には秘密鍵が必要なので作れない。

なぜハッシュを挟むのか

• 速度:RSA-3072 で 1 GB のファイルを直接署名するのは現実的でない。32 バイトのハッシュなら一瞬
• サイズ:RSA は n 以下の数しか扱えない(2048 bit RSA で約 256 バイトまで)。ハッシュなら任意長を 32 バイトに圧縮
• 安全性:衝突耐性のある暗号学的ハッシュなら、ハッシュ値が一致するなら原文も一致(同じ署名で別の文書を作れない)

考えてみよう: もし弱い MD5 のような壊れたハッシュを使ったら?攻撃者は同じハッシュを持つ別の文書を作って「正規の署名付き偽文書」を成立させられる。これが SHA-1 が証明書から廃止された決定的理由。署名の安全性はハッシュの衝突耐性に依存しています。

主要なディジタル署名アルゴリズム

主要 4 アルゴリズムの比較

RSA-PKCS#1 v1.5 vs RSA-PSS

RSA で署名するときは 必ずパディング が必要。古い方式 PKCS#1 v1.5 は決定論的(同じメッセージ → 同じ署名)で、過去に多くの実装脆弱性(Bleichenbacher 攻撃等)が見つかった。RSA-PSS(Probabilistic Signature Scheme) は確率的(ランダムソルトを混ぜる)で、安全性証明もある現代的なパディング。新規システムでは RSA-PSS を使う。

ECDSA の落とし穴

ECDSA は 署名のたびに新しい乱数 k を生成する必要 があり、k を予測されたり再利用したりすると 秘密鍵が漏洩 する。Sony PlayStation 3 の鍵漏洩事件(2010)はこれが原因(同じ k を 2 回使った)。RFC 6979 の「決定論的 ECDSA」 は k をハッシュから決定論的に導出することで乱数生成器の脆弱性を回避します。

Ed25519 ─ なぜモダンの一強

2011 年に djb・タンジャ・ランゲらが発表した Ed25519(EdDSA on Curve25519)は ECDSA の問題を構造的に排除した設計:

• 決定論的 ─ ECDSA の k 問題が起きない
• サイドチャネル攻撃に強い ─ 一定時間実行
• 署名サイズ 64 バイト固定 ─ ECDSA と同等または小さい
• 非常に速い ─ 最新 Intel/Apple CPU で署名 1 万 ops/秒以上
• シンプルな API ─ 鍵長は固定 256 bit、署名は固定 64 B

SSH(OpenSSH 6.5+)、Git(2017+)、WireGuard、Tailscale、Signal など 新しいシステムはほぼ全て Ed25519。RFC 8709(SSH)、RFC 8032(EdDSA)。

X.509 証明書 ─ ディジタル署名の最大ユースケース

「サーバ証明書 → 中間 CA → ルート CA」の チェーン・オブ・トラスト も、各段が前段の証明書の中身に対するディジタル署名であり、ルート CA だけが 自己署名(ブラウザ / OS に事前 install されている)。つまり PKI の階層構造そのものが、本講のスキームを縦に積み重ねた応用例と読めます。

Let's Encrypt が変えたもの

2015 年、Let's Encrypt が 無料の自動化された証明書発行 を始めるまで、TLS 証明書は年額数千〜数万円する商用サービスでした。これにより HTTPS の普及率が劇的に上がり(2014 年:~30% → 2024 年:~85%)、Web 全体が暗号化された流れの引き金になりました。中身は ECDSA(P-256) または RSA-PSS で、X.509 と CA 階層の仕組みは変わらず ─ 「ディジタル署名の自動化された大量生産」 が起きたと言えます。

コードサイニング ─ ソフトウェアに署名する

主要なコードサイニングプラットフォーム

Git の SSH 署名(2022〜)

Git 2.34 から SSH 鍵でコミット署名できるようになり、GitHub の verified 表示にも対応。Ed25519 の SSH 鍵で:

# SSH 鍵を署名鍵として設定
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub

# コミットに署名
git commit -S -m "fix: bug in module"

# 署名を確認
git log --show-signature

つながる知識: 2020 年の SolarWinds 事件、2017 年の NotPetya は 署名されたソフトウェアの配布 が攻撃ベクタになりました(攻撃者がビルドサーバを侵害して署名鍵で偽署名)。コードサイニングが信頼できるのは 署名鍵が安全に管理されている前提 でのみ。HSM・Sigstore のような 証明書透明性ログ を組み合わせる動きが進んでいます。

OpenSSL ハンズオン ─ 署名と検証

1. RSA 鍵で署名・検証

# 鍵を生成(前回作ったものを使う)
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out rsa_priv.pem
openssl rsa -in rsa_priv.pem -pubout -out rsa_pub.pem

# 署名対象
echo "I, Alice, agree to terms" > doc.txt

# 署名(SHA-256 + RSA-PSS)
openssl dgst -sha256 -sign rsa_priv.pem \
    -sigopt rsa_padding_mode:pss \
    -sigopt rsa_pss_saltlen:32 \
    -out doc.sig doc.txt

# 検証(成功すると "Verified OK")
openssl dgst -sha256 -verify rsa_pub.pem \
    -sigopt rsa_padding_mode:pss \
    -sigopt rsa_pss_saltlen:32 \
    -signature doc.sig doc.txt

2. 改ざんすると検証失敗

# 1 文字書き換える
echo "I, Alice, agree to TERMS" > doc.txt

# 検証 → 失敗
openssl dgst -sha256 -verify rsa_pub.pem \
    -sigopt rsa_padding_mode:pss \
    -sigopt rsa_pss_saltlen:32 \
    -signature doc.sig doc.txt
# → "Verification Failure"

3. Ed25519 で署名(モダン推奨)

# Ed25519 鍵生成
openssl genpkey -algorithm Ed25519 -out ed_priv.pem
openssl pkey -in ed_priv.pem -pubout -out ed_pub.pem

# Ed25519 は内部でハッシュ含むので -sha256 不要(指定するとエラー)
openssl pkeyutl -sign -inkey ed_priv.pem -rawin -in doc.txt -out doc.sig

# 検証
openssl pkeyutl -verify -pubin -inkey ed_pub.pem -rawin -in doc.txt -sigfile doc.sig
# → "Signature Verified Successfully"

4. Python で Ed25519 署名

# pip install cryptography
from cryptography.hazmat.primitives.asymmetric.ed25519 import (
    Ed25519PrivateKey, Ed25519PublicKey
)

# 鍵生成
priv = Ed25519PrivateKey.generate()
pub = priv.public_key()

message = b"I, Alice, agree to terms"

# 署名
signature = priv.sign(message)
print(signature.hex())  # → 64 バイトの署名

# 検証(失敗すると InvalidSignature 例外)
try:
    pub.verify(signature, message)
    print("Valid")
except Exception:
    print("Invalid")

5. 証明書を確認する

# Web サイトの証明書チェーンを取得
openssl s_client -connect example.com:443 -showcerts < /dev/null \
    | openssl x509 -text -noout

# 出力で確認できるもの:
#   Subject: CN=example.com
#   Issuer:  CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
#   Signature Algorithm: ecdsa-with-SHA384
#   Public Key Algorithm: id-ecPublicKey  (ECDSA P-384)
#   Validity: ...

PQC 署名 ─ 量子時代に向けて

サイズ比較

PQC 署名の実装状況(2024)

• OpenSSH 9.9(2024):Dilithium のオプションサポート開始
• Cloudflare:証明書チェーンに ハイブリッド署名(古典 + PQC) を実験中
• Apple iMessage:PQ3 プロトコル(2024) で Kyber + 古典の鍵交換、署名は古典のまま
• Microsoft:SymCrypt-OpenSSL に PQC 統合中

「現役の SSH 鍵を 今すぐ Dilithium に移行」までの段階ではないが、長期保存される署名(コードサイニング、法的文書のタイムスタンプ)は次の数年で PQC 移行が進む見込み。

つながる知識: 暗号化(機密性)で「Harvest Now, Decrypt Later」が問題なのと違い、署名は「過去の署名は守れる」のがまだ救い。重要なのは 新規発行する署名 をいつ PQC に切り替えるか。例えば 30 年有効な政府発行のコードサイニング証明書を今 ECDSA で発行すると、20 年後に量子計算機が来た時点で 偽造可能 になる。だからこそ長期署名から先行移行が始まっています。

まとめと用語チェック

用語チェック

確認問題