電子署名と証明書 — 「本人が作った」を数学で証明する

RSAとハッシュ関数を学んだ今、それらを組み合わせると偽造できない印鑑が作れます。署名で「誰が作ったか」「改ざんされていないか」を証明し、さらに証明書の連鎖（PKI）で「その公開鍵は本物か？」という最後の穴を塞ぐまでを、動かしながら追いかけます。

1. 秘密鍵で押す印鑑 — 署名と検証の流れ

電子署名の基本アイデアは、秘密鍵の持ち主にしか作れないデータを文書に添えることです。ただし文書全体に直接署名すると遅いので、まずハッシュ関数で文書の「指紋」を取り、その短い指紋に対して秘密鍵で署名します。受け取った側は、①文書のハッシュを自分で再計算し、②署名を送信者の公開鍵で開いて中のハッシュを取り出し、③両者を照合します。

下のデモでパイプライン全体を再生し、途中で「改ざんボタン」を押して検証が壊れる瞬間を確かめてください。

署名と検証のパイプライン — 印鑑を押して、照合する
改ざんボタンを押すと送信途中で「10万円」が「90万円」に書き換わり、受信側で再計算したハッシュと署名の中身が食い違って検証が赤×になります。チェックボックスで、暗号化と署名が鍵を逆向きに使うことも確認できます。
POINT — 署名が保証する3つのこと ① 本人性（その秘密鍵の持ち主が作った）、② 非改ざん（1ビットでも変わると検証が失敗する）、③ 否認防止（秘密鍵の持ち主にしか作れないので、後から「私は書いていない」と言えない）。一方、署名は中身を隠さない — 機密性を守るのは暗号化の仕事で、役割がまったく別。
s = Sign(秘密鍵, H(m))　　　Verify(公開鍵, m, s) → OK / NG RSA署名なら s ≡ H(m)d mod n、検証は se mod n = H(m) の確認 — RSAと同じ数学を「逆向き」に使う

2. その公開鍵、本物ですか？ — すり替え攻撃

署名の検証には「アリスの公開鍵」が必要です。ところが、その公開鍵はどうやって安全に手に入れるのでしょうか。ネット越しに受け取った鍵が途中で別人のものにすり替えられていたら、署名の仕組み全体が土台から崩れます。検証の数学は完璧に動くのに、間違った相手を「本人」と認定してしまうのです。

公開鍵すり替え攻撃（中間者攻撃）— 数学では防げない穴
ステップ③で、ボブの検証は「✓」を出してしまいます — マロリーの鍵で作った署名をマロリーの鍵で検証しているのだから当然です。この攻撃は署名アルゴリズムの欠陥ではなく、鍵の配送の問題。最後のステップで、認証局（CA）の署名がなぜ効くのかが見えます。

3. 信頼の連鎖 — 証明書チェーンとPKI

証明書とは「この公開鍵は example.com のものです」という宣言に、認証局（CA）が署名したものです。しかし「そのCAの公開鍵は本物か？」という同じ問いが連鎖します。実際のインターネットではこの連鎖は2〜3段で、最後はOSやブラウザに最初から入っているルート証明書で止まります。ブラウザはこの鎖を1段ずつ検証し、すべて繋がったときだけアドレスバーに錠前を表示します。

証明書チェーンの検証 — ブラウザの錠前ができるまで
各段の署名を1つ上位の公開鍵で確認し、緑の鎖が右まで繋がると錠前が点灯します。「破壊」ボタンでどこか1段を壊すと、そこから下流の信頼がすべて崩れることを確かめてください。上流ほど被害が大きい理由も見えてきます。
一歩先へ — 信頼の起点（トラストアンカー） あなたのOSとブラウザには、100件以上のルート証明書が出荷時からプリインストールされていて、世界中のhttpsの信頼はすべてここから流れ出している。つまりPKIは「数学だけ」で閉じておらず、最後はOSベンダーと認証局の運用・監査を信頼するという社会的な仕組みで支えられている。だからCAが不正発行を起こすと、ブラウザ側がそのCAを信頼リストから削除するという「大事件」になる。
注意 — 証明書は「生もの」：有効期限と失効 サーバ証明書には有効期限があり（現在は最長でも約13ヶ月）、期限が切れるとブラウザは警告を出す。さらに秘密鍵が漏洩したら期限前でも失効させる仕組み（CRL / OCSP）がある。「一度検証に通ったから永遠に安全」ではなく、検証は接続のたびに毎回やり直す — 錠前はその瞬間の検証結果にすぎない。

4. まとめ — 署名からPKIへ