AES-256 が VPN の暗号スイートを表さない理由
スイートは四つの役割を担う。大量暗号化、完全性、鍵の確立、相手の認証である。暗号名はそのうち一つを、一つの層で覆うだけだ。
VPN がどの暗号を使うか尋ねると、答えはたいてい一語で返ってくる。AES-256、あるいは ChaCha20、あるいは WireGuard かもしれない。その答えは一つの層の一つの部品を名指すだけで、接続を実際に守っているのは四つの異なる役割を担うアルゴリズムの集合だ。部品と構成を取り違えるのがこうした会話で最も多い誤りであり、決着のつかない比較を生む。
一つの接続の中の四つの仕事
大量暗号化はデータ経路のために平文を暗号文に変え、その鍵は送られるのではなく導出される。完全性の保護は改変を検出する。これは別の仕事であり、一つの構成が両方を担う場合でも変わりはない。鍵の確立は共有の通信材料を作り、相手の認証は向こう側が誰かを決める。どれか一つでも欠ければ、残りがどれほど強くても接続は安全ではない。
二つの役割を一つに畳む設計もある。AES-GCM と ChaCha20-Poly1305 は認証付き暗号の構成なので、機密性と完全性は一緒に届く。AES-CBC はそうではなく、独自の鍵を持つ別のメッセージ認証コードを必要とする。だから提案を独立した数字の袋として読むと、対として設計されたものを読み違える。
役割は層も異なる。だから同じ語が二つの製品で違う意味になりうる。ESP の中のブロック暗号と TLS の中のブロック暗号は、要件の異なる別の交渉における同じ基本要素だ。だから方式と層を添えずに基本要素だけを引くと、何も引かないより悪いことがある。
暗号名がほとんど何も語らない理由
AES-256 という表現を少し真面目に取ってみよう。それはブロック暗号と鍵長を指す。動作モードや完全性が提供されるか、鍵がどう確立され相手がどう認証されたかについては何も言わない。二つの製品がどちらも AES-256 を宣伝しながら、それ以外のすべてで異なることはありうる。認証なしの方式と組み合わせるものも、現代的な鍵交換を伴う AEAD 方式を使うものも含まれる。
TLS 1.3 はこの分離を標準に持ち込んだ。古い語彙を学んだ人には有用な修正だ。その暗号スイートは AEAD とハッシュだけを名指しし、鍵交換グループと署名アルゴリズムは別のパラメータとして交渉される。だから TLS 1.3 のスイート名は TLS 1.2 のスイート名と対等には比べられない。両方が設定ファイルの同じ欄に現れても、である。二つの文字列を直接比べる監査者は、プロトコルが支えない結論を引き出す。交渉されたグループと署名パラメータも読まなければ、比較は不完全だ。
WireGuard は逆の道を選び、交渉をほぼ完全に除く。プロトコルが固定のアルゴリズム集合を定めるので、二つの実装は相互運用できるかできないかのどちらかだ。これは正当な設計判断であり、WireGuard がどのスイートを交渉するかという問いに比較に値する答えはないことも意味する。監査するなら、仕様を一度読み、その周りの鍵の扱いを監査するほうがよい。交渉ではなく。
語彙を決めるのは層だ
IPsec の配備は二度交渉する。制御経路のための IKE 提案と、データのための ESP 変換であり、両者は正当に異なりうる。前者を読んで後者を説明しているとみなすのは、監査中の混乱のよくある源だ。設定ファイルは両方に触れ、興味深いのは後者だからである。
| Layer | What is negotiated there | What it does not cover |
|---|---|---|
| IKE proposal | Algorithms and groups for the control channel that builds the tunnel | The algorithms protecting the data itself |
| ESP transform | Encryption and integrity for tunneled packets | Peer identity, which authentication already settled |
| TLS handshake | AEAD and hash, plus separately negotiated groups and signatures | Routing, authorization or retention policy |
| WireGuard | Nothing; the algorithm set is fixed by the protocol | Everything above the cryptographic arrangement |
あるライブラリで利用できる名前が、別のデータ経路に自動で実装されるわけではない。だから当社の製品は AES-256 をサポートするという主張は聞こえほど強くなく、相互運用の問題は通常、両側で古いアルゴリズムをすべて有効にするのではなく、維持された共通部分を見つけることで解決される。
TLS 1.3 の仕様はこの分離の最も明快な公開例だ。スイートを対として定義し、残りを独自の交渉へ移している。この形が身につけば、IPsec の提案も WireGuard の一つの固定集合も、同じ発想の変形として読める。
交渉された結果を読み、そこで止める
設定された提案は、二つの相手が何を選んだかの証拠ではない。生きているセッションが答えを持ち、主要な実装はいずれもパケットを取得せずにそれを報告できる。
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg show出力では提示された一覧ではなく、選択されたアルゴリズムを読む。答えが方針の意図より弱いなら、修正はどちらか一方の提案設定にあり、現代の実装では不一致は通常、静かな格下げではなく交渉の失敗として現れる。
次に、スイートが何を覆わないかを思い出す。経路、アプリの権限、記録、保持はそれぞれ独自の見直しを伴う別の決定であり、互換な暗号構成はそれらについて何も語らない。暗号の議論はする価値があるが、ほとんどの人が実際に尋ねている問いより狭い問いに答えるものだ。
語彙を正確に保てば議論は短くなる。スイートは層の上の役割の集合であり、暗号は一つの部品であり、交渉された結果だけが、実際に持っている接続を記述する。比較のその他はすべて飾りだ。