はじめに
本記事は、Coursera の Network Systems Foundations モジュール「Network Security」で学んだ内容を整理する目的でまとめたものです。
🔷 1. ネットワークセキュリティとは？
通信は Wi-Fi / ISP / Router など
「制御不能な媒介 を通るため攻撃者が介入できる」
→ 盗聴 / 改ざん / 成りすまし の危険あり
🧩 CIA Triad（3 つの柱）
| 要素 | 意味 |
|---|---|
| Confidentiality（機密性） | 権限のある者のみが閲覧可能 |
| Integrity（完全性） | 改ざんされていない |
| Availability（可用性） | 必要な時に利用可能 |
🚨 2. 各レイヤーの脅威と解決策
| レイヤー | 問題 | 解決策 |
|---|---|---|
| Network Data Plane | 盗聴 / 設定ミス | ✨ IPsec |
| Network Control Plane | BGP hijacking | ✨ RPKI |
| Transport / Application | HTTP は平文通信 | ✨ TLS / HTTPS |
🔐 3. 暗号化の基礎
🔑 共通鍵暗号（対称暗号）
- 1 つの鍵を共有 → 暗号化 & 復号
- 高速・実用的
- 鍵の共有方法が課題
例：XOR 暗号（非常に単純）
plaintext: 0100 0101
key: 1101 0111
ciphertext: 1001 0010
→ AES（256bit） = 強力な共通鍵暗号の代表例
🔑 公開鍵暗号（非対称暗号）
- 公開鍵 → 暗号化
- 秘密鍵 → 復号
- 鍵共有の課題を解決（ただし遅い）
RSA 例：
c = m^e mod n # 暗号化
m = c^d mod n # 復号
TLS の鍵共有で使われるが、
現在は ECDHE / Diffie-Hellman が主流
🔁 4. Diffie–Hellman 鍵交換の仕組み
お互いに 秘密値 x, y をランダムに選ぶ
→ 互いに知らずに 同じ共有鍵 K が生成される！
hA = g^x mod p
hB = g^y mod p
# 双方の計算結果は一致：
K = (hB)^x mod p = g^(xy) mod p
= (hA)^y mod p = g^(xy) mod p
x と y を共有しなくても、K が一致するのがポイント！
📌 5. HMAC（暗号化ではなく「改ざん検知」）
Message Authentication Code（MAC）
= 改ざんされていないか確認する仕組み
HMAC = H( key || H(key || message) )
- 共通鍵を用いる（送信者と受信者で共有）
- 送信側：MAC を作って message と一緒に送る
- 受信側：MAC を再計算して比較
→ 内容が改ざんされたら検知可能
🌐 6. IPsec（ネットワーク層の暗号トンネル）
VPN 内部で使われることが多い
→ 拠点間通信を暗号化する技術
IPsec の主要ステップ（IKE）
| ステップ | 内容 |
|---|---|
| SA-1 | 暗号方式・認証方式・ハッシュ方式の交換 |
| Diffie–Hellman | 共通鍵（Session Key）作成 |
| 認証 | 事前共有鍵 or 証明書 |
| SA-2 | Traffic Selectors → 通す通信を指定 |
| Traffic | AH or ESP モードで通信開始 |
🛰️ 7. RPKI（BGP Hijacking 対策）
❌ 攻撃例
Prefix 1.1.1.0/24 を AS3 が保有
AS4 が「自分が AS3 です」と嘘のBGP発表
→ AS1 は短い経路を選び AS4 に送信 → ハイジャック成功
💡 理想解
Prefix Owner が
「1.1.1.0/24 は AS3 が所有」と証明する仕組みが欲しい
それが RPKI（Resource Public Key Infrastructure）
💡 RPKI の流れ
1. RIR（APNIC・ARIN…）が CA（証明書局）になる
2. Prefix Owner が 公開鍵を提出（証明書要求）
3. RIR が ROA を署名・DB登録
4. Validator が ROA を検証
5. Routerが BGP経路を Valid / Invalid / Unknown に判定
| 状態 | 意味 |
|---|---|
| VALID | 正常 |
| INVALID | なりすまし可能性 |
| UNKNOWN | 後方互換モード |
🔒 8. TLS / HTTPS（アプリ層の守護神）
HTTP の問題点
- 平文通信（盗聴可能）
- 改ざん検知なし
- サーバーの真正性保証なし
➡ TLS を挟むと HTTPS になる！
TCP ─ TLS ─ HTTP ← 3 層構造
⚡ TLS 1.2 ハンドシェイク（流れ）
① Client Hello ← 対応可能な暗号方式・バージョンを送信
② Server Hello ← サーバーが選択
③ Server Certificate（CA 署名付き証明書）
④ Server Hello Done
⑤ Client Key Exchange → 公開鍵で Session Key を暗号化送信
⑥ Finished（メッセージ改ざんチェック）
🔐 セキュア通信開始！
🧾 Let's Encrypt（証明書自動発行）
/well-known/acme-challenge/xxxx
に指定された値を置く
→ Let's Encrypt が HTTP リクエストして確認
→ 所有者であると判定されれば証明書発行
🔁 Mutual TLS（mTLS）
通常：クライアントがサーバーの証明書を確認
mTLS：サーバーがクライアントの証明書も確認
➡ API / B2B / 内部通信で使用される
🧠 個人的な理解ポイント（メモ）
- TLS は HTTP 専用ではなく TCP と HTTP の間のレイヤ
- Diffie-Hellman の式が数学的に理解できた
- RIR = CA → RPKI の核心
- AES は共通鍵暗号の中でも強力な例
- HMAC は暗号化ではなく改ざん検出
- IPsec の SA-1 / SA-2 / DH / Traffic の流れが明確になった
- mTLS は API のセキュリティに使える
参考文献
- Coursera:Network Systems Foundations