共有された DH グループと新しい秘密: 攻撃が安くなる理由

グループのパラメータは設計上公開されており、その公開性こそがパラメータを見落としやすくしている。有限体上の Diffie-Hellman では法と生成元が共有されるが、秘密指数とそこから生じるセッション鍵は共有されない。数体ふるい攻撃の高価な段階は、ひとつの交換ではなくグループに依存する。だからどこでも使われる単一の弱いグループは共有された負債になる。パラメータを公開と呼ぶのは正確だが的外れである。再利用されるのは、そのグループを攻撃する費用そのものだからだ。

公開される半分は脆弱な半分ではない。そこが罠だ

よくある半端な議論はこうだ。パラメータは標準で公開されているのだから攻撃者はすでに知っており、隠しても何も変わらない。両方の文は正しく、どちらも他方から導かれない。同梱された既定グループは公開であり、先週生成した秘密グループも、ハンドシェイクを完了した誰にでも見える。秘密性は制御ではなかった。強度と検証が制御である。

変わるのは、同じ弱点を共有する場所の数だ。自前の 2048 ビットグループを生成する組織は自分の攻撃費用を払うが、何百万人もが選ぶプロトコルの既定値は、ひとつの費用を全員に償却する。その意味で、珍しいグループが自動的に優れているわけではない。小さすぎる珍しいグループは、見る目の少ない、より小さな共有秘密にすぎない。

検証はサイズと同じくらい重要だ。小さな因子を持つ法や、プロトコルが期待する形でない法を送る相手は、ビット長が立派に見えても秘密指数に関する情報を漏らしうる。入り口で不正なパラメータを拒否するライブラリは実質的な仕事をしており、だから手作りのパラメータ解析は労力を節約するのに適さない場所である。

事前計算が攻撃者に実際にもたらすもの

数体ふるいには素数だけに依存する段階があり、その出力はその素数を使うすべての交換に対して再利用できる。これが歴史的な懸念の仕組みのすべてだ。高価な部分は一度だけ支払われ、その後の各セッションの限界費用は下がる。新しい指数は、ふるい分けを実行不能にするほどグループが大きい限り、個々の交換を受動的な観察者から依然として守る。二つの主張は両立しており、この話題の議論の大半は一方を選んで他方を捨てることから生じる。

2015 年の Logjam の論文は、512 ビットの輸出グレード Diffie-Hellman へのダウングレードを示し、大規模な資源でより大きな広く再利用されるグループを攻撃する費用を見積もった。実演は具体的であり、見積もりは見積もりであり、どちらも特定の VPN セッションが解読された証拠ではなかった。

論文は仕組みと実演されたダウングレードのために引用すべきで、自分の配備の測定として引用すべきではない。どれだけのサーバーが既定グループを共有していたかという古い統計は、その年のインターネットを描写するもので、今日検査できるネットワークではない。持ち帰る価値があるのは問いである。あなたの機器は今も小さな、あるいは弱く検証されたグループを交渉しているか。

標準化されていることは弱いことと同じではない

RFC 7919 は名前付きの有限体グループを定義し、双方が識別子でグループに合意し、一貫した方針を適用できるようにする。標準化されていることは利点である。交渉の曖昧さを取り除き、実装が未対応のサイズを拒否できるようにする。名前付きグループが弱いのは、そのサイズが従うと称する方針を下回るときだけで、文書に現れるからではない。同じ論理は楕円曲線グループにも当てはまる。構造も故障の仕方も異なる。

それらについて考えるときは構成を分けて扱う。有限体上の Diffie-Hellman についての結論は X25519 について何も言わず、1024 ビットの MODP グループについての結論は 3072 ビットのそれについて何も言わない。強度の方針は仕組みごと、サイズごと、プロトコル版ごとであり、だから強い暗号という表現はレビュー可能な主張ではない。

認証はもう半分であり、代わりにはならない。相手の検証のない強いグループは攻撃者を中間に置き、有効な証明書は 768 ビットの交換を救えない。二本の独立した線として見直し、そのうえで両方が実際に交渉されていることを確認する。

実際の接続で交渉されたグループを読む

交渉されたグループは設定テンプレートではなく機器から読む。テンプレートは意図を表し、興味深い値は最後のハンドシェイクで双方が合意したものである。IPsec の端点では、状態出力が通常、選択された提案と MODP グループを表示する。

方針を変える前と後にその行を記録し、どちらも変更記録に残す。比較が証拠である。

ipsec statusall | grep -Ei "proposal|ESP|IKE"
openssl dhparam -in /etc/vpn/dh3072.pem -check -noout

変更後も状態が古いグループを示すなら、接続は再交渉しておらず、設定の編集は何も証明していない。相手を再起動するかセキュリティ協会を消去し、それから状態を読み直す。新しい接続にだけ適用される方針は、稼働し続ける限り長寿命のトンネルを古いパラメータに残す。

グループと相手の身元を別々に確認する

グループが守るものと、反対側に誰がいるかを分ける。鍵交換方式、グループのサイズ、認証方式を三つの項目として記録する。これらは独立に失敗するからだ。3072 ビットのグループを交渉したが任意の証明書を受け入れるトンネルは、相手を固定して 2048 ビットのグループを使うトンネルと同じリスクではない。

レビューが始まる前に受け入れ基準を書いておく。そうすれば結果は意見ではなく比較になる。プロトコル版ごとの最小グループサイズ、名前付きグループの許可リスト、相手の検証の義務化で、判断は機械的にできる。その一覧の曖昧さがレビューを議論に変え、議論は是正されない。そして出力は、明示した規則に失敗する端点の一覧になる。

ipsec statusall | grep -Ei "peer|auth|cert"
openssl s_client -connect vpn.acme.example:443 -brief -cipher 'DHE-RSA-AES256-GCM-SHA384'

是正後に交渉された値を読み直して輪を閉じる。準拠した設定ファイルは、トンネルがそれを取り込んだ証拠ではない。状態出力と一度の新しいハンドシェイクが証拠であり、それらを集めるのは、必要かどうかを話す会議より短い時間で済む。