変更要約: 初版
4.3暗号技術と認証（公開鍵暗号・PKI・多要素認証）
共通鍵暗号と公開鍵暗号の仕組みと使い分け、両者を組み合わせたハイブリッド暗号、データの改ざん検知に使うハッシュ関数、正当な作成者を証明するデジタル署名、公開鍵の正当性を保証するPKI（公開鍵基盤）と認証局（CA）、Web通信を保護するSSL/TLS、複数要素で本人確認する多要素認証・生体認証、通信のなりすましを防ぐチャレンジレスポンス認証を学びます。
暗号技術は「誰にも読まれたくない（機密性）」を実現する仕組みですが、デジタル署名のように完全性や真正性を証明するための応用もあり、暗号=機密性という単純化は誤解のもとです。この節では鍵の使い方の違いが、実現できる性質の違いに直結するという視点で、共通鍵暗号・公開鍵暗号・ハッシュ関数それぞれの得意分野を整理します。
4.3.1共通鍵暗号・公開鍵暗号・ハイブリッド暗号
- 共通鍵暗号＝暗号化と復号に同一の鍵を使う方式（例: AES）。処理が高速だが、通信相手ごとに鍵を安全に共有する鍵配送問題が課題（n人が互いに通信するには鍵が組合せ的に増える）。公開鍵暗号＝対になる公開鍵と秘密鍵を使う方式（例: RSA）。公開鍵で暗号化した内容は対応する秘密鍵でしか復号できないため鍵配送問題を解消するが、処理は共通鍵暗号より低速。
- 公開鍵暗号の使い分け＝送信者が受信者の公開鍵で暗号化すれば「受信者だけが復号できる（機密性）」、送信者が自分の秘密鍵で暗号化（署名）すれば「送信者本人にしか作れない（真正性・否認防止）」という逆方向の性質を実現できる。この2用途の区別が最重要ポイント。
- ハイブリッド暗号＝実務での主流方式。データ本体は高速な共通鍵暗号で暗号化し、その共通鍵（セッション鍵）だけを公開鍵暗号で暗号化して送ることで、公開鍵暗号の鍵配送問題の解消と共通鍵暗号の速度を両立させる。SSL/TLSの鍵交換もこの方式に基づく。
4.3.2ハッシュ・デジタル署名・PKI・認証方式
- ハッシュ関数＝任意長のデータから固定長の値（ハッシュ値）を生成する一方向関数（復号不可・元データの復元は不可能）。同じ入力からは必ず同じハッシュ値が得られるため、送信前後のハッシュ値を比較して改ざんの有無を検知できる。デジタル署名＝送信データのハッシュ値を送信者の秘密鍵で暗号化したもの。受信者は送信者の公開鍵で復号しハッシュ値を照合することで、真正性（本人が作成）と完全性（改ざんなし）を同時に検証できる。
- PKI（公開鍵基盤）＝公開鍵が正当な持ち主のものであることを保証する仕組み全体。認証局（CA）＝公開鍵と持ち主の情報を結びつけたデジタル証明書（電子証明書）を発行する信頼された第三者機関。公開鍵だけでは「本当にその人の鍵か」証明できないため、CAの署名が入った証明書によって真正性を保証する。
- SSL/TLS＝WebブラウザとWebサーバ間の通信を暗号化するプロトコル。サーバ証明書（CAが発行）でサーバの真正性を確認 → ハイブリッド暗号でセッション鍵を安全に交換 → 以降は共通鍵暗号で高速に暗号化通信という流れで機密性・完全性・真正性をまとめて実現する。URLが
https://のとき有効。 - 多要素認証（MFA）＝知識情報（パスワード等）・所持情報（ICカード・スマホ等）・生体情報（指紋・虹彩等）のうち異なる2種類以上を組み合わせる認証。1つが漏えいしても他要素で防御できる。生体認証は本人拒否率（FRR）と他人受入率（FAR）のトレードオフに注意。チャレンジレスポンス認証＝サーバが毎回変わるランダムな値（チャレンジ）を送り、利用者側はパスワードと組み合わせた計算結果（レスポンス）のみを返すことで、パスワード自体を通信路に流さず盗聴・再送攻撃を防ぐ。
共通鍵=高速だが鍵配送問題／公開鍵=鍵配送問題を解消するが低速／ハイブリッド暗号=両者の併用、デジタル署名=秘密鍵で暗号化し公開鍵で検証（真正性+完全性）、認証局(CA)が公開鍵の正当性を保証する、多要素認証は異なる種類（知識/所持/生体）の組み合わせが要件が最頻出です。
あるオンライン契約サービスが「契約書データを安全にやり取りし、後から本人が『署名していない』と否認できないようにしたい」という要件を満たす場面を追ってみましょう。まず契約書本体は容量が大きいため、共通鍵暗号で高速に暗号化します。その共通鍵（セッション鍵）自体を安全に相手へ届けるには公開鍵暗号で受信者の公開鍵を使って暗号化し、これがハイブリッド暗号の骨格です。次に「本人が確かに合意した」ことを証明するために、契約書データのハッシュ値を計算し、送信者（契約者）自身の秘密鍵でそのハッシュ値を暗号化したものをデジタル署名として添付します。受信側は届いた契約書データから改めてハッシュ値を計算し、署名を送信者の公開鍵で復号して得たハッシュ値と一致するか照合します。一致すれば「改ざんされていない（完全性）」うえに「確かに秘密鍵の持ち主本人が署名した（真正性・否認防止）」ことが同時に証明されます。ただしこの検証が成立するのは、その公開鍵が本当に契約者本人のものだと第三者が保証している場合に限られます。そこで認証局（CA）が契約者の本人確認を行ったうえで公開鍵と身元を結びつけたデジタル証明書を発行し、PKIの枠組みによって「なりすましの公開鍵ではないか」という懸念を解消します。サービスへのログイン自体も、パスワード（知識情報）だけでなくスマートフォンアプリが生成するワンタイムコード（所持情報）を組み合わせた多要素認証にすることで、パスワード漏えいだけでは突破されない仕組みにする、というのが一連の設計です。
| 方式 | 鍵の使い方 | 特徴 |
|---|---|---|
| 共通鍵暗号 | 暗号化・復号に同一の鍵 | 高速・鍵配送問題あり |
| 公開鍵暗号（機密性用途） | 受信者の公開鍵で暗号化・秘密鍵で復号 | 鍵配送問題を解消・低速 |
| デジタル署名（真正性用途） | 送信者の秘密鍵で暗号化・公開鍵で検証 | 真正性・完全性・否認防止を証明 |
ひっかけ： 「公開鍵暗号は共通鍵暗号より安全だから常に公開鍵暗号だけを使うべきだ」は誤りです。公開鍵暗号は処理が低速なため、実務ではハイブリッド暗号のようにデータ本体は共通鍵暗号、鍵の受け渡しだけ公開鍵暗号とする組み合わせが一般的です。また「デジタル署名は送信者の公開鍵で暗号化して作る」も誤りで、署名の作成は送信者の秘密鍵、検証は送信者の公開鍵という順序が逆です（機密性目的の暗号化とは鍵の使い方が逆になる点に注意）。
4.3.3この節のまとめ
- 共通鍵=高速だが鍵配送問題／公開鍵=鍵配送問題を解消するが低速。実務はハイブリッド暗号（データ=共通鍵・鍵交換=公開鍵）
- デジタル署名=秘密鍵で暗号化・公開鍵で検証＝真正性+完全性+否認防止。CA/PKIが公開鍵の正当性を保証
- 多要素認証=知識・所持・生体のうち異なる2種以上。チャレンジレスポンスはパスワード自体を送らず盗聴・再送を防ぐ
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 取引先が多数あるオンライン取引システムで、通信相手ごとに鍵を安全に配布する手間が課題になっていた。この課題を解消するために適した暗号方式はどれか。
Q2. あるファイルにデジタル署名を付与して送信した。受信者が署名を検証する際に用いる鍵と、その検証で確認できる性質の組み合わせとして最も適切なものはどれか。
Q3. あるシステムへのログインに、パスワードに加えてスマートフォンアプリが生成するワンタイムコードの入力を必須にした。この認証強化はどのような組み合わせに該当するか。