初級では「秘密鍵で署名、公開鍵で検証、証明書で保証」と捉えました。上級では、署名方式とPKIの運用へ。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
署名方式
- RSA-PSS — RSAベース。確率的パディングで安全性を高めた署名
- ECDSA — 楕円曲線ベース。短く高速だがnonce（署名ごとの乱数）の扱いが命
- EdDSA（Ed25519） — 決定的nonceで事故を防ぐ、現代的で高速な方式
流れは「データ→ハッシュ→秘密鍵で署名／公開鍵で検証」。ハッシュを挟むのは、任意長を扱い、安全性を担保するためです。
やさしく言うと（中級）
電子署名は、公開鍵暗号を「逆向き」に使います。
- 送り主がデータのハッシュ（指紋）を取り、それを秘密鍵で署名する
- 受け取った人は、送り主の公開鍵で検証する
- 一致すれば「本人が作った・改ざんされていない」と分かる
ハッシュを挟むのは、任意長のデータを固定長にまとめて効率よく署名するため。これで真正性（本人）・完全性（改ざんなし）・否認防止（やっていないと言わせない）を確かめられます。
PKI — 信頼をたどる仕組み
公開鍵が本物だと保証するのが PKI（公開鍵基盤）。
- 信頼チェーン — ルートCA → 中間CA → サーバ証明書、と署名でつながる
- 失効 — CRL（リスト）／OCSP（オンライン確認）／OCSP stapling
- Certificate Transparency（CT） — 発行された証明書を公開ログに記録し、不正発行を検知
- ACME／自動化 — Let's Encrypt などで短命証明書を自動発行・更新
- mTLS — サーバだけでなくクライアントも証明書で認証
やさしく言うと（中級）
署名の検証には、相手の公開鍵が本物である必要があります。それを保証するのが証明書とPKI（公開鍵基盤）。
- 信頼チェーン — ルートCA → 中間CA → サーバ証明書、と署名でつながる
- 認証局（CA） — 公開鍵の持ち主を保証する信頼された第三者
- 失効の確認 — 期限前でも無効化できる（CRL／OCSPで確認）
- HTTPSの鍵マーク — この検証が通った印
アニメーション『証明書の信頼チェーン』を開く
⚠️ 運用と攻撃
- ECDSAのnonce事故 — 漏洩・再利用で秘密鍵露出（決定的nonce/EdDSAで回避）
- CA侵害・誤発行 — 信頼の起点が破られると全体が揺らぐ（CTで検知）
- 失効の伝播遅延 — 失効しても、確認が届くまで悪用の余地
- 証明書ピンニングの運用難 — 固定しすぎると更新で自分が詰まる
- 期限・チェーン不備 — 最も多いトラブルは、期限切れと中間証明書の欠落
やさしく言うと（中級）
- 秘密鍵の漏洩 — 署名の信頼が根本から崩れる
- 証明書の期限切れ — 警告が出て検証に失敗
- 中間証明書の欠落 — チェーンが切れて検証できない（よくあるトラブル）
- オレオレ証明書 — CAの保証がなく、本物の証明にならない
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. 証明書が「もう信用できない」と失効したことを確認する仕組みは？
問2. ECDSA署名で、署名ごとの乱数（nonce）が漏れたり再利用されたりすると？
問3. EdDSA（Ed25519）がECDSAのnonce事故を避けられるのはなぜ？
問4. 発行された証明書を公開ログに記録し、不正発行を検知する仕組みは？
問5. 署名の前にデータのハッシュを取る理由として正しいのは？
問6. OCSP staplingの利点として正しいのは？
問7. サーバだけでなくクライアントも証明書で認証する方式を、英字4文字で答えてください。
問8. Let's Encrypt などで短命証明書を自動発行・更新するプロトコルを、英字4文字で答えてください。