要約

  • RFC 3526は、既存の1536ビット群5を文書化し、2048～8192ビットの群14～18を定義した。AES強度との単純対応を示さず、秘密指数がシステムの弱点にならないことを別途求めている。
  • 必要な証拠は、公開パラメータの識別だけではない。ローカル方針、指数のエントロピーと新規生成、相手公開値の検証、認証、完全なsuite、鍵の更新・破棄、実際の保護通信を結ぶ必要がある。

標準群のよさは、多くの参加者が同じ公開対象を参照できることにある。素数も生成元も番号も共有され、実装間の意味を合わせられる。

秘密指数のよさは、公開できない。生成の瞬間だけに存在する品質であり、値そのものは守られ、最後には消えるべきである。

この非対称性を無視すると、見える群番号が見えない処理の代理人になる。2003年5月のStandards Track文書で、現在Proposed Standardとして記録されるRFC 3526は、そこまでの権限を番号に与えていない。

群番号が固定するのは公共材料である

RFCは長く実装で使われた1536ビット群5を標準化し、群14、15、16、17、18に2048、3072、4096、6144、8192ビットを割り当てた。いずれも生成元2と公開された素数を使う。

二つの実装が同じ番号を同じ数学的対象として扱える。その調整は重要で、毎回未知のmodulusを持ち込む必要を減らす。

しかし番号には乱数源、秘密指数、受信値の検査、許可方針、相手の名前、PRF、暗号化方式、配送結果が含まれない。

従って群のreceiptは「この公開パラメータを選んだ」とだけ言える。session全体を評価するには、実行時にしか得られないreceiptを後ろへ連結する。

AESとの換算を決めなかった理由を残す

RFC 3526の導入部は、有限体群と128、192、256ビット対称鍵の強度を比較する複数の推定を示す。特に大きな強度では推定差が著しい。

文書は一つを正解として販売しない。複数の群を定義しながら、どの群を各AES鍵長と組み合わせるべきかは指定しない。当時のハードウェアでは8192ビットを超える群も実用上遅すぎるとした。

したがって群18を「256ビット安全」と自動表示するのは、RFCが避けた断定を後から追加することになる。modulus長と対称鍵長は同じ物差しではない。

攻撃能力、秘密保持期間、解析の進歩、装置負荷、他のprimitiveを含む方針判断が必要であり、その判断には版と所有者が要る。

秘密指数はfield幅では測れない

RFCは指数が他の構成要素に釣り合い、最弱点にならないよう求める。目標強度の2倍を超えるrandomnessを持たせ、128ビット強度なら256ビットを超える乱数を使う例を示す。

512ビットの格納域を確保しても512ビットのエントロピーは証明されない。偏ったseed、反復出力、起動直後の故障を長い表現にしても予測不能性は増えない。

監査のために指数を保存するのも誤りである。secretを公開する証拠は制御を破壊する。保存すべきなのは承認済みgeneratorと版、health test、要求entropy、長さ方針、新規生成の事実、保護されたevent bindingである。

公開群の規模と秘密処理の品質は、別々のauthorityから別々に証明される。

相手の公開値には受信側の仕事が残る

RFC 6989はIKEv2のKE payloadを受け取る側の検査を記述する。RFC 3526群を含むSophie Germain primeのMODP群では、公開値rが厳密に1 < r < p-1の範囲にあることを検証する。

群番号は検査方法を選ぶが、検査済みという事実は運ばない。群14と書かれたpayloadでも、値によっては拒否されなければならない。

small subgroupを持つ別群や秘密値のreuseには、さらに異なる条件がある。fresh生成とreuseは同じ証拠ではなく、適用するtestも同じとは限らない。

受信値のhash、validation profile、実装版、判定branchと結果を残す。「DH OK」だけでは認識、数学的妥当性、方針許可が区別できない。

MUST implementはローカル許可ではない

RFC 7296は、IKEv2実装に受理可能suiteを指定するmanagement facilityを求める。受信Transform IDsをローカル設定と比較し、許可されないproposalを拒否する。実装必須でも設定必須ではない。

この境界により、標準registryは名前を調整しても、各現場のsecurity policyにはならない。

RFC 8247公開時には群14がMUSTへ上がり、群5はSHOULD NOTへ下がった。同時に、非常に大きな群はVPN gatewayや制約機器へ大きな負荷を与えると述べる。

提案順序、選択、方針版、許可理由、拒否候補を保存する。support、enable、select、succeedは四つの異なる状態である。

共有値は相手の身元ではない

認証なしDiffie-Hellmanは、実際に参加した相手と値を共有する。意図した相手であることは別の仕組みが示す。IKEのauthenticationがその役割を担い、RFC 3526は群を提供するだけである。

大きなbit数はcertificate chain、PSK identity、EAP判断、受理名と権限対象の一致を検証しない。

画面上の強い群と成功表示から人や組織の信頼を導けば、authentication receiptのauthorityを群番号へ移してしまう。

method、credential path、validation policy、claimed identity、accepted identity、channel bindingを独立して保持し、同じexchangeへ関連付ける。

suiteの他の要素は消えない

RFC 8247は、algorithmとkeyの強さに加え、非暗号的な迂回を防ぐprotocol engineeringが必要だとする。大きな群は弱いPRF、誤った認証、露出した保存域、保護経路外の通信を修復しない。

計算負荷も現実である。大きなmodular exponentiationを未認証相手に無制限で行えば、resource exhaustion面を広げる可能性がある。必要なのは弱い群への退却ではなく、順序と制限を含むreceiptである。

suiteはdependency graphとして評価する。約束の上限は関連する弱点とcompositionで決まり、最大のbit数では決まらない。

TLS向けRFC 7919は別のFFDHE群と交渉を採用した後続比較であり、RFC 3526を遡及変更せず、IKE実装も証明しない。

IANAの行はruntime telemetryではない

IKEv2 registryには群5と14～18が残り、定義にRFC 3526、recipient testsにRFC 6989が示される。番号の意味と参照先を決める正当なcoordinationである。

その行は、装置がfreshな値を生成したか、範囲を検査したか、方針を守ったか、相手を認証したか、古いsecretを消したか、trafficを届けたかを観測しない。

RFC 9395はIKEv1をdeprecatedとしregistryを閉じた。同文書で追加deprecatedとしたalgorithm一覧にはDH群がなかった。この事実は全群の同等な推奨でも、legacy運用の保証でもない。

registry、文書status、implementation requirement、deployment decisionを一つにすると、記録層がrunning codeのauthorityを奪う。

秘密を残さず実行を残す

protocol version、RFC、Transform ID、primeとgeneratorのhashから始める。ordered proposal、選択suite、downgrade context、policy IDと判定を結ぶ。

秘密生成は値を残さず、generator、health、policy、freshnessを残す。peer valueはdigest、test profile、branchを残す。authenticationはmethod、trust path、accepted principalを残す。

derivationでは安全に保持できるnonce、PRF、algorithm、SA生成を記録し、lifecycleではrekey、reuseの有無、erasureを記録する。

最後にprotected packets、integrity failure、traffic selector、期待したpeer、application transactionを観測する。handshakeはその前提になれても、結果の代筆者にはなれない。

証拠の境界

本Articleは特定の実装、vendor、operator、VPN、gateway、peer、user、deployment、flow、incident、attack、compromiseを示さない。採用率、entropy、validation、reuse、性能、安全性、事業結果も測定しない。

RFC 3526は2003年5月のStandards Track文書で、現在Proposed Standardとして記録される。RFC 6989、RFC 7296、RFC 8247、RFC 9395は各自の時点と範囲を保ち、特定runtimeの遵守証明ではない。

Heng Luのauthorityとrunning-codeに関するnoteは明示した編集上の視点であり、公共調整と局所実行を分ける。IETFの意図や暗号学的事実のsourceではない。

狭い結論で十分である。大きな群は一つの数学要素を強めるが、exchange全体の証明は他のreceiptが完成させる。

出典