4.1情報セキュリティの基礎と暗号・認証（PKI・デジタル署名）

応用情報の午前で暗号技術が問われるとき、最も差がつくのは「鍵をどちらの向きに使うか」を正確に言えるかどうかです。公開鍵暗号は「誰が何の鍵で暗号化し、誰が何の鍵で復号するか」によって、実現できる性質が機密性にも真正性にもなります。この節では、CIAという評価軸をまず整理したうえで、共通鍵暗号・公開鍵暗号・ハッシュ関数それぞれの数学的な性質の違いが、実務でどう使い分けられるかを深掘りします。

4.1.1CIAと補完要素

• 機密性（Confidentiality）＝許可された主体だけが情報にアクセスできる状態。完全性（Integrity）＝情報が改ざん・破壊されず正確である状態。可用性（Availability）＝必要なときに利用できる状態。補完要素として真正性（Authenticity）（主張どおりの本人・本物である保証）・責任追跡性（Accountability）（誰が何をしたか追跡できること）・否認防止（Non-repudiation）（後から行為を否認できないこと）・信頼性（Reliability）（意図した動作の継続）がある。
• 同じ侵害事象でも影響を受けるCIA要素は状況で異なる（例: 顧客名簿の漏えい=機密性、Webサイト改ざん=完全性、DoSによる停止=可用性）。デジタル署名は「暗号化」の応用でありながら機密性ではなく真正性・完全性・否認防止を実現する点が、CIA=暗号化という単純化を避けるべき理由である。

4.1.2共通鍵暗号・公開鍵暗号・ハイブリッド暗号

• 共通鍵暗号＝暗号化・復号に同一の鍵を使う方式（AES等）。処理は高速だが、通信相手ごとに鍵を安全に共有する鍵配送問題を抱える（n人が総当たりで通信するには鍵が n(n-1)/2 通り必要）。公開鍵暗号＝対になる公開鍵と秘密鍵を使う方式（RSA等）。機密性用途では「送信者が受信者の公開鍵で暗号化→受信者が自分の秘密鍵で復号」という向きを使う。これにより鍵配送問題を解消するが、処理は共通鍵暗号より大幅に低速。
• 公開鍵暗号には逆向きの使い方もある。送信者が自分の秘密鍵で暗号化（署名）すれば、対応する公開鍵で復号できることが「その秘密鍵の持ち主にしか作れない」ことの証明になり、真正性・否認防止を実現する（＝デジタル署名の原理）。「公開鍵で暗号化→秘密鍵で復号」＝機密性、「秘密鍵で暗号化（署名）→公開鍵で検証」＝真正性、という向きの違いを取り違えないことが最重要。
• ハイブリッド暗号＝実務での主流方式。データ本体は高速な共通鍵暗号で暗号化し、その共通鍵（セッション鍵）だけを受信者の公開鍵で暗号化して送ることで、鍵配送問題の解消と処理速度を両立する。SSL/TLSの鍵交換もこの方式に基づく。

4.1.3ハッシュ関数・デジタル署名・PKI・多要素認証

• ハッシュ関数＝任意長の入力から固定長のハッシュ値を生成する一方向関数。ハッシュ値から元データを復元することは事実上不可能（不可逆）であり、同じ入力からは必ず同じ値が得られる。異なる入力から同じハッシュ値が出る衝突の発生確率が低いことが安全性の条件。改ざん検知に用いる（データとハッシュ値を比較）。
• デジタル署名＝送信データのハッシュ値を送信者の秘密鍵で暗号化したもの。受信者は送信者の公開鍵で署名を復号して得たハッシュ値と、受信データから自ら計算したハッシュ値を照合し、一致すれば真正性（本人作成）と完全性（改ざんなし）を同時に検証できる。署名の生成=秘密鍵・検証=公開鍵という向きを逆にしないこと。
• PKI（公開鍵基盤）＝公開鍵が正当な持ち主のものであることを保証する仕組み全体。認証局（CA）＝本人確認のうえ公開鍵と持ち主を結びつけたデジタル証明書を発行する信頼された第三者機関。公開鍵だけでは真の持ち主を証明できないため、CAの署名付き証明書によって真正性を担保する。SSL/TLSはサーバ証明書でサーバの真正性を確認したうえでハイブリッド暗号によりセッション鍵を交換する。
• 多要素認証（MFA）＝知識情報（パスワード）・所持情報（ICカード・スマホ）・生体情報（指紋・虹彩）のうち異なる2種類以上を組み合わせる。生体認証は本人拒否率（FRR）と他人受入率（FAR）のトレードオフ（閾値を厳しくするとFARは下がるがFRRは上がる）に注意。チャレンジレスポンス認証＝サーバが毎回異なるチャレンジを送り、利用者はパスワードと組み合わせた計算結果（レスポンス）のみ返すことで、パスワード自体を通信路に流さず盗聴・再送攻撃を防ぐ。

午前試験でよく出る計算・判断のパターンを2つ確認しましょう。(1) 鍵配送の本数: 共通鍵暗号だけで10人が総当たりで暗号通信するには、各ペアに専用の鍵が必要なため 10×9/2 = 45 本の鍵が必要です。これが公開鍵暗号なら各人が公開鍵・秘密鍵の1組（公開鍵10個の配布のみ）で済み、鍵配送問題が解消されることが計算からも裏付けられます。(2) デジタル署名の検証プロセス: 契約書データを送る場面を想定すると、送信者はまず契約書のハッシュ値を計算し、これを自分の秘密鍵で暗号化して署名を作り、契約書本体に添付します。受信者は届いた契約書から改めてハッシュ値を計算する一方、添付された署名を送信者の公開鍵で復号して元のハッシュ値を取り出し、両者を照合します。一致すれば「改ざんされていない（完全性）」かつ「秘密鍵の持ち主本人が作成した（真正性・否認防止）」ことが同時に証明されます。ここでもし送信者が公開鍵で暗号化していたら、対応する秘密鍵を持つのは受信者自身であり、「送信者が作った」ことの証明にはならない点に注意してください。さらに、この検証が成立する前提として「その公開鍵が本当に送信者本人のものだ」という保証が必要であり、これを認証局（CA）が発行するデジタル証明書が担います。証明書自体もCAの秘密鍵で署名されており、検証者はCAの公開鍵（多くはOS/ブラウザに信頼済みルート証明書として組み込み済み）を使って証明書の真正性を確認する、というPKIの信頼の連鎖が成立しています。

4.1.4この節のまとめ

• CIA=機密性・完全性・可用性。補完要素は真正性・責任追跡性・否認防止・信頼性
• 「公開鍵で暗号化→秘密鍵で復号」=機密性、「秘密鍵で暗号化(署名)→公開鍵で検証」=真正性。向きを逆にしない
• 共通鍵=高速だが鍵配送問題(n(n-1)/2本)／公開鍵=解消するが低速。実務はハイブリッド暗号。CA/PKIが公開鍵の正当性を保証