鍵のビット数が大きいだけではVPNは安全にならない理由

広告は256ビットと言い、別の製品は128ビットと言う。結論は明らかなように見えるが、これらの数字が別のものを表していると気づくまでは。 共通鍵暗号の鍵、証明書の公開鍵、鍵交換のパラメータ は同じ尺度では測れない。どれも、クライアントがサーバーを検証したかどうかさえ覆ってはいない。数字は確かな情報だが、それを取り巻く宣伝文句が示すよりずっと狭い範囲の話である。

何かを比較する前に、どの鍵を数えているのか、それが何を守るのかを問うてほしい。

三つの鍵、三つの役割

データ暗号はトンネルのペイロードを暗号化し、その鍵はセッションごとに新しく導出される。証明書の公開鍵は認証の際に端点の身元を証明する。鍵交換の段階は、通常は一時的なDiffie-Hellmanの変種で、後からどちらの側も再現できない共有秘密を確立する。それぞれに独自の強度の前提と、独自のサイズの慣習がある。

だから256を2048の隣に、そのまた隣に32を置いて、大きさで順位づけることはできない。それらは別の問いへの答えである。

ひとつの役割の内側でさえ、数字が語るのは使われているアルゴリズム群との関係においてだけだ。

数字が役立つところ、止まるところ

ひとつのアルゴリズムの内側では、鍵が大きいほど総当たり探索の費用は上がり、公表された指針は計算能力の変化に応じて証明書鍵の下限を定めている。これは正当だが狭い比較だ。AES-128とAES-256はどちらも直接攻撃に大きな余裕で耐えるため、実務ではその差が決め手になることはまれである。

その比較の外では、数字は設定の誤り、証明書の検証、プロトコルの版について何も予測しない。

交渉されたスイート全体を読む

接続が実際に使うのはスイートである。暗号モード、完全性または認証付き暗号の構成、鍵交換グループ、認証方式の組み合わせだ。適切なハンドシェイクを伴う現代のAEADモードは、表に出ている鍵サイズが同じでも、別個のMACと組んだ古いモードとは別の提案である。

openvpn --show-ciphers | head -20
openvpn --show-tls | head -20
openssl x509 -in server.crt -noout -text | grep -E 'Public-Key|Signature Algorithm'
wg show

設定上の最大値ではなく、交渉された結果を読むこと。強いスイートを提示するクライアントでも、サーバーが弱い選択肢を選び、プロファイルがそれを許せば、弱いまま接続する。性能が気になるなら、問題の端末と経路で測ること。ハードウェア加速とパケットサイズが関わってくると、鍵のサイズはスループットの予測には向かない。

数字が決して測らない部分

第一の抜けはソフトウェアの保守である。修正を受け取らなくなったライブラリの上に築かれたトンネルは、鍵のサイズが示すより弱い。設定値ではそれを直せない。第二は運営者の振る舞いだ。接続記録、アカウントのデータ、サポートの対応は、暗号の完全に外側にある。想定より多くを保持するサービスは、鍵を長くしても安全にはならない。

第三にして最も影響が大きいのが相手の検証である。どんな証明書でも受け入れるクライアントは、認証されていない相手の周りに強い暗号を巻いているだけであり、正しく検証する控えめな暗号より悪い。数字より先にこの三つを確かめれば、数字は本来の位置に収まる。