変更要約: 初版
2.6証明書とセキュリティ
PKIによる公開鍵の真正性、対称（高速・共有鍵）と非対称（鍵配送）の使い分け、そしてTLSで交渉される暗号スイート・X.509証明書・鍵交換・プロトコルバージョン・PKCSという証明書の構成要素を、監視で「この暗号通信は安全か・改ざんされていないか」を判断する視点で学びます。
前の節々で「暗号化は監視の可視性を下げる」と繰り返し見てきました。だからこそSOCアナリストは、暗号通信そのものの健全性——正しい相手か・強度は十分か・改ざんの余地はないか——を証明書とハンドシェイクから読み取る必要があります。この節では、公開鍵の真正性を担保するPKI、速度と鍵配送を役割分担する対称/非対称暗号、そしてTLSハンドシェイクで交渉される暗号スイート・X.509・鍵交換・プロトコルバージョン・PKCSを、「この暗号は信頼してよいか」を判断する監視の視点で整理します。
2.6.1対称・非対称とPKI
- 対称鍵暗号＝暗号化と復号に同じ鍵を使う（AES等）。高速で大量データ向きだが、通信相手に鍵を安全に渡す（鍵配送）問題がある。非対称鍵暗号＝公開鍵と秘密鍵の対を使う（RSA・ECC等）。公開鍵で暗号化したものは秘密鍵でしか復号できず、鍵配送問題を解けるが計算コストが高い。
- 実際のTLSは両者を組み合わせる：非対称で安全に鍵を配り（鍵交換）、以後の大量データは高速な対称鍵で暗号化する（ハイブリッド）。「非対称は遅いから使わない」でも「対称だけで鍵配送も済ませる」でもなく、役割分担で両方の利点を取るのが本質。
- PKI（公開鍵基盤）＝公開鍵が本当にその相手のものかを第三者（認証局CA）の署名で保証する仕組み。CAが署名したX.509証明書を検証することで、なりすまし（MITM）を防ぐ。証明書の信頼チェーン（ルートCA→中間CA→サーバ証明書）をたどれることが真正性の根拠になる。
2.6.2証明書とハンドシェイクの要素
- 暗号スイート（cipher suite）＝TLSで使う暗号アルゴリズムの組み合わせ（鍵交換方式・認証・対称暗号・ハッシュ）。ハンドシェイクで双方が対応する中から交渉して決まる。監視では、弱い/廃止された暗号スイート（例：RC4・DES・輸出グレード）への交渉は危険信号で、ダウングレード攻撃の兆候にもなる。
- X.509＝証明書の標準形式で、発行者(CA)・サブジェクト(相手)・公開鍵・有効期間・シリアル・署名・SAN（対象ドメイン）等を含む。監視での典型的な危険信号は、期限切れ・自己署名・サブジェクト（CN/SAN）と接続先ドメインの不一致・失効(CRL/OCSP)済みの証明書で、MITMや偽サイトの兆候になり得る。
- 鍵交換（key exchange）＝対称鍵を安全に共有する手順（RSA鍵転送やDH/ECDHE）。ECDHEのような方式は前方秘匿性（Perfect Forward Secrecy）を持ち、後で秘密鍵が漏れても過去の通信は復号されない。プロトコルバージョンはTLS1.2/1.3が現行で、SSL3.0やTLS1.0/1.1は脆弱＝廃止。古いバージョンへの交渉は危険信号。PKCSは公開鍵暗号の各種標準（例：PKCS#7署名、PKCS#10証明書要求、PKCS#12鍵/証明書のバンドル）で、鍵・証明書の形式やコンテナを規定する。
「対称＝同一鍵で高速だが鍵配送問題／非対称＝公開・秘密鍵対で鍵配送を解くが低速／TLSは両者ハイブリッド」「PKIはCA署名で公開鍵の真正性を保証」「X.509の危険信号＝期限切れ/自己署名/名前不一致/失効」「弱い暗号スイート・古いバージョン(SSL3/TLS1.0-1.1)は危険」「ECDHEは前方秘匿性」「PKCSは鍵/証明書の標準形式(例#12バンドル)」が頻出です。「この暗号は信頼してよいか」を要素から判断できるように。
あなたはSOCで、社内から外部サイトへのHTTPS接続に関するアラートを調べています。プロキシのTLSインスペクションログには、あるサーバとのハンドシェイクでプロトコルバージョンがTLS 1.0に交渉され、暗号スイートにRC4が選ばれ、提示されたX.509証明書が自己署名で、CN/SANが接続先ドメインと一致していないと記録されていました。要素を一つずつ判断します。まずTLS 1.0とRC4は廃止済みの脆弱な組み合わせで、これ自体がダウングレード攻撃や旧式サーバの危険信号です。次に自己署名でCAの信頼チェーンに繋がらない証明書は、PKIの真正性保証を欠き、MITM（間に割り込んだ攻撃者が自前の証明書を提示している）の典型的兆候です。さらにCN/SANと接続先ドメインの不一致は、「正規サイトを装った別物」への接続を示します。ここで「暗号化されているのだから安全」と判断するのは重大な誤りです——暗号化されていることと正しい相手と十分な強度で暗号化されていることはまったく別で、後者を保証するのがPKI・証明書・暗号スイート・バージョンの検証だからです。正しい対処は、当該接続を遮断し、その証明書のフィンガープリント/発行者を記録し、同じ不正証明書を提示する他の通信がないかを横展開で探すことです。対照的に、別の接続ではTLS 1.3・ECDHE鍵交換・有効なCA署名済みX.509・ドメイン一致が確認でき、前方秘匿性もあるため、こちらは暗号通信として健全と判断できます。監視における証明書の読み解きは、「見えない中身」を諦める代わりに、「その暗号の器そのものが信頼できるか」を要素から確定させる、可視性低下時代の重要なスキルです。
| 要素 | 役割 | 監視での危険信号 |
|---|---|---|
| 対称/非対称 | 高速なデータ暗号/鍵配送・署名 | 弱い/短い鍵、非対称のみで大量データ |
| PKI / X.509 | CA署名で公開鍵の真正性を保証 | 期限切れ・自己署名・名前不一致・失効 |
| 暗号スイート | 使用アルゴリズムの組み合わせ | RC4/DES等の弱い/廃止スイート |
| 鍵交換 | 対称鍵を安全に共有 | 前方秘匿性なし（旧RSA鍵転送のみ） |
| プロトコルバージョン | TLSの版（現行1.2/1.3） | SSL3.0・TLS1.0/1.1への交渉 |
| PKCS | 鍵/証明書の標準形式（例#12） | 不正/破損したコンテナ・想定外の署名 |
ひっかけ： 「HTTPSで暗号化されていれば、相手や証明書に関わらず安全と判断してよい」は誤りです——暗号化されていることと正しい相手と十分な強度で暗号化されていることは別問題で、自己署名・名前不一致・失効のX.509や弱い暗号スイート/古いTLS版はMITMや偽サイトの危険信号です。また「対称鍵暗号は非対称より速いので、鍵配送も含めすべて対称鍵だけで済む」も誤り＝対称鍵は鍵配送問題を抱え、TLSは非対称で鍵を配り対称で本文を暗号化するハイブリッドです。
2.6.3この節のまとめ
- 対称は同一鍵で高速だが鍵配送問題、非対称は公開/秘密鍵対で鍵配送を解くが低速。TLSは両者のハイブリッド
- PKIはCA署名で公開鍵の真正性を保証。X.509の危険信号は期限切れ・自己署名・名前不一致・失効で、MITMや偽サイトの兆候
- 暗号スイート・プロトコルバージョン・鍵交換・PKCSを検証し「その暗号の器が信頼できるか」を判断。弱いスイートや古い版(SSL3/TLS1.0-1.1)は危険信号
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. プロキシのTLSインスペクションログで、ある外部サーバとのHTTPS接続がTLS1.0・RC4で交渉され、提示されたX.509証明書が自己署名で、CN/SANが接続先ドメインと一致していなかった。この状況の判断として最も適切なものはどれか。
Q2. TLS通信で「大量データは高速に暗号化したいが、相手に鍵を安全に渡す方法も必要」という要件がある。実際のTLSがこれをどう解決しているかとして最も適切なものはどれか。
Q3. 暗号通信の設計方針を評価している。「後で万一サーバの秘密鍵が漏えいしても、それ以前に記録された過去の暗号化通信は復号されない」という前方秘匿性を得るために最も適切な選択はどれか。