[コンピュータネットワーク] 19. ネットワークセキュリティ：暗号学からファイアウォールまで

ネットワークセキュリティの核心要素
=====================================

1. 機密性（Confidentiality）
   - 意図された受信者のみがメッセージを読める
   - 実装：暗号化（Encryption）

2. 完全性（Integrity）
   - メッセージが転送中に改ざんされていないことを保証
   - 実装：ハッシュ、MAC、電子署名

3. 認証（Authentication）
   - 通信相手の身元を確認
   - 実装：認証プロトコル、証明書

4. 可用性（Availability）
   - サービスが正常に利用可能な状態を維持
   - 脅威：DDoS攻撃

攻撃者の脅威：
  - 盗聴（Eavesdropping）：機密性の侵害
  - 改ざん（Modification）：完全性の侵害
  - なりすまし（Impersonation）：認証の侵害
  - サービス拒否（DoS）：可用性の侵害

対称鍵暗号の動作
==================

      秘密鍵K（両者が共有）
         |                |
         v                v
[平文] --[暗号化]--> [暗号文] --[復号化]--> [平文]
 "Hello"   E_K()    "xYz!@"    D_K()    "Hello"

特徴：
  - 暗号化/復号化に同じ鍵を使用
  - 高速な演算速度
  - 鍵配布問題：両者が安全に鍵を共有する必要がある

対称鍵アルゴリズム
====================

アルゴリズム | 鍵長        | ブロックサイズ | 状態
-------------+-------------+--------------+--------
DES          | 56ビット    | 64ビット     | 脆弱（使用禁止）
3DES         | 168ビット   | 64ビット     | 安全だが低速
AES          | 128/192/256 | 128ビット    | 現行標準
RC4          | 可変        | ストリーム   | 脆弱（使用禁止）
ChaCha20     | 256ビット   | ストリーム   | モダン、TLS 1.3

AES（Advanced Encryption Standard）：
  - 2001年にNISTがDESの代替として選定
  - ブロック暗号：128ビットブロック単位で処理
  - ラウンド数：10/12/14（鍵長に応じて）
  - 現在最も広く使用されている対称鍵暗号

ブロック暗号の運用モード
==========================

1. ECB（Electronic Codebook）：各ブロックを独立に暗号化
   [B1] -> [E] -> [C1]
   [B2] -> [E] -> [C2]
   問題：同じ平文ブロック -> 同じ暗号文ブロック（パターン露出）

2. CBC（Cipher Block Chaining）：前の暗号文とXOR後に暗号化
   [B1 XOR IV] -> [E] -> [C1]
   [B2 XOR C1] -> [E] -> [C2]
   利点：同じ平文でも異なる暗号文を生成

3. CTR（Counter）：カウンタを暗号化して平文とXOR
   [CTR+0] -> [E] -> XOR [B1] -> [C1]
   [CTR+1] -> [E] -> XOR [B2] -> [C2]
   利点：並列処理可能、ストリーム暗号のように動作

公開鍵暗号の動作
==================

Bobの鍵ペア：（公開鍵Kb+、秘密鍵Kb-）
  - 公開鍵：誰でも知ることができる
  - 秘密鍵：Bobだけが知っている

AliceがBobにメッセージ送信：
  [平文m] --[Kb+で暗号化]--> [暗号文] --[Kb-で復号化]--> [平文m]

特性：
  - Kb+(m)はKb-でのみ復号化可能
  - Kb+からKb-を計算することは計算的に不可能
  - 鍵配布問題を解決（公開鍵は自由に配布）
  - 対称鍵より演算が遅い（100~1000倍）

RSAの動作原理
===============

鍵生成：
  1. 大きな素数p、qを選択（各1024ビット以上）
  2. n = p x qを計算
  3. z = (p-1)(q-1)を計算
  4. zと互いに素なeを選択（公開鍵の一部）
  5. e x d mod z = 1となるdを計算（秘密鍵の一部）

公開鍵：(n, e)
秘密鍵：(n, d)

暗号化：c = m^e mod n
復号化：m = c^d mod n

安全性の根拠：
  - nからp、qを見つけること = 素因数分解問題
  - 現在の技術で2048ビット以上のnは分解不可能

ハイブリッド暗号システム
==========================

公開鍵暗号は遅いため、実際にはセッション鍵の交換にのみ使用

1. Aliceがランダムな対称鍵（セッション鍵）Ksを生成
2. AliceがBobの公開鍵でKsを暗号化して送信
   Kb+(Ks) --> Bobに送信
3. Bobが秘密鍵でKsを復号化
   Kb-(Kb+(Ks)) = Ks
4. 以後両者がKsでAES対称鍵暗号を使用

利点：
  - 公開鍵：安全な鍵交換（遅いが1回のみ）
  - 対称鍵：高速なデータ暗号化（大量データ）

ハッシュ関数の特性
====================

H(m) = 固定長のハッシュ値（メッセージダイジェスト）

要件：
  - 一方向性：H(m)からmを逆算不可
  - 衝突耐性：H(m) = H(m')となる異なるm、m'を見つけることが困難
  - 雪崩効果：入力が1ビット変わっても出力が大きく変化

代表アルゴリズム：
  MD5：    128ビット出力（脆弱、使用禁止）
  SHA-1：  160ビット出力（脆弱、使用禁止）
  SHA-256：256ビット出力（現行標準）
  SHA-3：  可変出力（次世代標準）

MACの動作
==========

送信者（Alice）：                  受信者（Bob）：
  メッセージm                       受信：m + MAC
  秘密鍵s                           秘密鍵s
  MAC = H(m + s)                   MAC' = H(m + s)
  送信：m + MAC                    MAC == MAC'? --> 完全性確認

HMAC（Hash-based MAC）：
  HMAC = H(K XOR opad || H(K XOR ipad || m))

  - 単純なH(m+s)より安全な構造
  - TLS、IPsecなどで標準として使用

電子署名の動作
================

署名生成（Alice）：
  1. メッセージmのハッシュを計算：h = H(m)
  2. 秘密鍵でハッシュを暗号化：sig = Ka-(h)
  3. 送信：m + sig

署名検証（Bob）：
  1. メッセージmのハッシュを計算：h = H(m)
  2. Aliceの公開鍵で署名を復号化：h' = Ka+(sig)
  3. h == h'? --> 署名有効

電子署名が提供するもの：
  - 認証：Aliceが署名したことを確認
  - 完全性：メッセージが改ざんされていない
  - 否認防止：Aliceは署名の事実を否認できない

公開鍵証明書（PKI）
=====================

問題：Bobが受け取った公開鍵は本当にAliceのものか？
解決：信頼できる第三者（CA）が保証

証明書構造：
  +----------------------------------+
  | 発行対象：alice.com              |
  | 公開鍵：Ka+                      |
  | 発行者：DigiCert（CA）           |
  | 有効期間：2026.01.01 ~ 2027.01.01|
  | 署名：CAの秘密鍵で署名済み       |
  +----------------------------------+

検証過程：
  1. Bobがalice.comの証明書を受信
  2. CAの公開鍵で証明書の署名を検証
  3. 有効であれば証明書内のKa+を信頼

代表的なCA：DigiCert、Let's Encrypt、GlobalSign

TLSの位置
==========

[HTTP、SMTP、FTPなど]
[TLS/SSL]
[TCP]
[IP]
[リンク層]

TLSが提供するセキュリティ：
  - 機密性：データ暗号化（AESなど）
  - 完全性：MACで改ざん検出
  - 認証：サーバ証明書で身元確認

TLS 1.2ハンドシェイク
=======================

クライアント                          サーバ
    |                                   |
    |--- ClientHello ------------------>|
    |    （サポート暗号リスト、ランダム値）|
    |                                   |
    |<-- ServerHello -------------------|
    |    （選択された暗号、ランダム値）   |
    |<-- Certificate -------------------|
    |    （サーバ証明書）                |
    |<-- ServerHelloDone ---------------|
    |                                   |
    |--- ClientKeyExchange ------------>|
    |    （プリマスタシークレット、       |
    |     サーバ公開鍵で暗号化）         |
    |--- ChangeCipherSpec ------------->|
    |--- Finished --------------------->|
    |                                   |
    |<-- ChangeCipherSpec --------------|
    |<-- Finished ----------------------|
    |                                   |
    |=== 暗号化されたアプリケーションデータ ===|

TLS 1.3の改善点：
  - 1-RTTハンドシェイク（TLS 1.2は2-RTT）
  - 0-RTT再接続サポート
  - 安全でない暗号の削除
  - より強力な鍵交換（ECDHE必須）

IPsecプロトコル
================

1. AH（Authentication Header）
   - 認証と完全性を提供
   - 暗号化は提供しない
   - あまり使用されない

2. ESP（Encapsulating Security Payload）
   - 認証 + 完全性 + 暗号化をすべて提供
   - 最も多く使用

動作モード：
  トランスポートモード（Transport Mode）：
    元：  [IPヘッダ][データ]
    ESP： [IPヘッダ][ESPヘッダ][データ（暗号化）][ESPトレーラ][ESP認証]
    --> ホスト間の直接通信時に使用

  トンネルモード（Tunnel Mode）：
    元：  [IPヘッダ][データ]
    ESP： [新IPヘッダ][ESPヘッダ][元IPヘッダ + データ（暗号化）][ESPトレーラ]
    --> VPNゲートウェイ間の通信時に使用

VPNの動作
==========

本社                                    支社
[内部ネットワーク] -- [VPN GW] ===IPsecトンネル=== [VPN GW] -- [内部ネットワーク]
10.1.0.0/16                 インターネット          10.2.0.0/16

パケットの流れ：
  1. 10.1.0.5から10.2.0.10へパケット送信
  2. 本社VPN GWがパケットをIPsec ESPで暗号化
  3. 新IPヘッダ：送信元=本社GW、宛先=支社GW
  4. インターネットを通じて暗号化されたパケットを送信
  5. 支社VPN GWが復号化して10.2.0.10に転送

IKE（Internet Key Exchange）：
  - IPsec SA（Security Association）設定のためのプロトコル
  - 相互認証と鍵交換を実行

ファイアウォールの種類
========================

1. パケットフィルタリング（Packet Filtering）
   - IPアドレス、ポート、プロトコルに基づいてフィルタリング
   - ステートレス：各パケットを独立に判断
   - 高速だが精緻な制御が困難

2. ステートフルパケットフィルタリング（Stateful Packet Filtering）
   - TCP接続状態を追跡
   - 接続が確立されたパケットのみ許可
   - より精緻なセキュリティ

3. アプリケーションゲートウェイ（Application Gateway）
   - アプリケーションデータを検査
   - HTTP、FTPなどプロトコル別の細かな制御
   - プロキシサーバとして動作

パケットフィルタリングルールの例
==================================

ルール | 方向     | 送信元IP      | 宛先IP        | プロトコル| ポート | 動作
-------+---------+---------------+---------------+----------+------+------
  1    | インバウンド| *           | 10.1.0.0/16   | TCP      | 80   | 許可
  2    | インバウンド| *           | 10.1.0.0/16   | TCP      | 443  | 許可
  3    | インバウンド| *           | 10.1.0.5      | TCP      | 22   | 許可
  4    | アウトバウンド| 10.1.0.0/16| *             | TCP      | *    | 許可
  5    | *        | *             | *              | *        | *    | 拒否

解釈：
  ルール1：外部から内部Webサーバ（80）へのHTTPアクセスを許可
  ルール2：外部から内部Webサーバ（443）へのHTTPSアクセスを許可
  ルール3：外部から特定サーバへのSSHアクセスを許可
  ルール4：内部から外部への全TCPを許可
  ルール5：それ以外はすべて拒否（デフォルトポリシー）

IDSの種類
==========

1. シグネチャベースIDS
   - 既知の攻撃パターン（シグネチャ）とマッチング
   - 利点：既知の攻撃に対して正確な検知
   - 欠点：新しい攻撃（ゼロデイ）は検知不可

2. 異常検知ベースIDS
   - 正常なトラフィックパターンを学習し異常を検知
   - 利点：新しい攻撃も検知可能
   - 欠点：誤検知（false positive）が高い場合がある

配置位置：
  インターネット --> [ファイアウォール] --> [IDS] --> [内部ネットワーク]

IPS（Intrusion Prevention System）：
  - IDS + 自動ブロック機能
  - 検知された攻撃をリアルタイムでブロック

ネットワーク攻撃の種類
========================

1. IPスプーフィング（Spoofing）
   - 送信元IPアドレスを偽造
   - 対策：イングレスフィルタリング（Ingress Filtering）

2. DoS/DDoS
   - 大量のトラフィックでサービスを麻痺
   - SYN Flood：TCP 3-wayハンドシェイクを悪用
   - 対策：SYNクッキー、トラフィックフィルタリング

3. 中間者攻撃（Man-in-the-Middle）
   - 通信経路に割り込んで盗聴・改ざん
   - 対策：TLS、証明書検証

4. ARPスプーフィング
   - 偽のARP応答でトラフィックを傍受
   - 対策：静的ARPテーブル、802.1X

5. DNSスプーフィング
   - 偽のDNS応答でフィッシングサイトに誘導
   - 対策：DNSSEC