公開鍵暗号による文書データ署名入門
概要
オンラインで交わす契約書や報告書は、途中で書き換えられていないこと（完全性）と、確かに本人が作ったこと（真正性）が分かってはじめて価値を持ちます。この資料は、共通鍵暗号と公開鍵暗号の基本を日常の風景になぞらえながら、公開鍵暗号を使った署名と検証の流れを肩の力を抜いて学べるようにまとめたカジュアルなガイドです。家の合鍵や宅配ロッカー、スタンプカードといった身近なイメージを頼りに、暗号の仕組みを堅苦しく感じずにたどれる構成にしています。
1. 暗号の基礎：共通鍵暗号と公開鍵暗号の二刀流
この章では、暗号の世界に「みんなで同じ鍵をシェアするやり方」と「鍵をペアで使うやり方」があることを紹介します。
共通鍵暗号
同じ合鍵を共有していないとキャンディーボックスに触れない
公開鍵暗号
店長だけが持つマスターキー（秘密鍵）と、来店者全員に配られるロッカーの一時パス（公開鍵）。誰でもパスで荷物を預けられるけれど、取り出せるのは店長だけ
2. 共通鍵暗号と公開鍵暗号の違いをざっくり比較
ここでは二つの暗号方式を机上の言葉だけでなく、どんな場面に向くのか、鍵をどう配るのか、処理性能はどう違うのかという三つの角度から丁寧に比較します。仕事で「どちらを採用すべき？」と迷ったときに、この章の内容をそのまま判断材料として使えるようにするのが狙いです。
比較表
| 観点 | 共通鍵暗号 | 公開鍵暗号 |
|---|---|---|
| 鍵配布の手間 | 事前に同じ鍵を安全に共有する必要があり、人数が増えるほど管理が難しい | 公開鍵は誰にでも配れるため配布は容易、秘密鍵のみ厳重に保管 |
| 処理速度 | 暗号化・復号とも高速で、大量データ向き | 計算が重く処理は遅め。主に鍵配送や署名などポイント利用 |
| 典型的な用途 | VPNやディスク暗号化など大容量データの暗号化 | TLS の鍵交換、電子署名、証明書など真正性・鍵配送が重要な場面 |
| リスク | 鍵が一度漏洩すると全員の通信が危険にさらされる。鍵の入れ替えコストも高い | 秘密鍵が漏れなければ公開鍵が広まっても安全。ただし秘密鍵への攻撃が一点突破で効く |
3. 公開鍵暗号の仕組みをイメージで理解
公開鍵暗号の一連の流れを「鍵を作る→公開鍵を配る→暗号化する→秘密鍵で復号する」という4ステップに分解し、それぞれが身近な動作に置き換えられることを実感してもらいます。数学的な式を前提にせず、ロッカーと封印シールの例でイメージを固めた上で、後の章で署名の仕組みにスムーズにつなげるのが目的です。
鍵を生成して公開鍵を配る
[暗号] 緑色の透明ロッカーに荷物を入れると、中身を取り出せるのは紫色の管理キーを持つ本人だけ
[署名] 管理キーでロッカーに貼った封印シールは、誰でも配布された透明チェックカード（公開鍵）をかざして正規品か確認したうえで取り出せる
4. 署名が必要な理由：完全性と真正性を守る
デジタル文書はコピーも改変も数クリックでできてしまうため、「届いたファイルは途中で誰にも触られていないのか」「本当にあの人が送ってきたものなのか」を確かめる術が欠かせません。 この章では、完全性と真正性という二つの観点を押さえることで、なぜ署名が信頼の支えになるのかを段階的に確認します。
完全性（Integrity）
共有フォルダへアップした資料が途中で書き換えられていないかを確かめること。
真正性（Authenticity）
その資料が本当にあの人から届いたと確認できること。
5. 署名と検証の流れを体験
署名プロセスは、文書が作られてから相手に届くまでの間に何が行われているのかを順番に追うと理解しやすくなります。この章では、現場で署名機能を組み込むときにまさに踏むことになる手順を、ハッシュ化・署名付与・検証という3ステップに分けて、どの場面でどの鍵が登場するのかを明確に描きます。動かす順番が分かれば、トラブルが起きた際にどこを疑えばいいかも見えてきます。
- 文書をハッシュ関数で要約し、短い指紋のような値を作る。
- その指紋を秘密鍵で暗号化し、デジタル署名として添付。
- 受信者は同じハッシュ関数で文書の指紋を再計算し、公開鍵で署名を復号して値を照合。
照合が一致すれば完全性と真正性が満たされた証拠として文書を採用し、不一致の場合は改ざんや送信者違いを疑わなければならない。
おまけ：HTTPSにおける鍵交換の仕組み
ブラウザで「https://」にアクセスすると、裏側では公開鍵暗号と共通鍵暗号がリレーのように働きます。以下は一般的な TLS 1.2/1.3 ハンドシェイクをシンプルに追ったものです。
- クライアントHello：ブラウザは「使える暗号スイート」「TLS バージョン」「乱数」などをサーバーに送る。まだ暗号化はされていない。
- サーバー証明書の提示：サーバーは公開鍵を含む証明書（例：example.com の証明書）と、自身が選んだ暗号スイート、乱数を返す。証明書は認証局（CA）の署名付きなので、ブラウザは CA の公開鍵で検証して真正性を確認する。
- 鍵交換（例：ECDHE）：ブラウザとサーバーは一時的な鍵ペアを生成し、それぞれの公開値を交換する。相手の公開値と自分の秘密値を組み合わせ、同じ共有鍵（プレマスターシークレット）を計算する。ここまでが公開鍵暗号の役割。
- 対称鍵の派生：共有鍵をもとに、送受信それぞれのセッション鍵（共通鍵）を導出する。以降の通信は高速な共通鍵暗号（AES など）で行う。
- Finished メッセージ：双方が新しい共通鍵でメッセージを暗号化し、「これからは暗号化済みのデータだけを送る」と宣言する。ここでハンドシェイク完了。
ポイントは「公開鍵暗号＝身元確認と安全な鍵共有」「共通鍵暗号＝実データの暗号化」という役割分担が HTTPS でもそのまま活用されていること。公開鍵でサーバーの正しさを確かめ、使い捨ての共有鍵を合意し、あとは共通鍵暗号でスピーディーに通信する――という流れが、日々のブラウジングを支えている。
