静的鍵ファイルのビット数は OpenVPN の暗号強度ではない

スキャナや同僚が、OpenVPN の静的鍵ファイルに印字されたビット数を指して、なぜトンネルはその大きさの暗号を使っていないのかと尋ねる。質問はもっともらしく聞こえるが、答えは数値ではない。バナーが数えるのは保存された鍵素材であり、暗号はその鍵長が要求する部分だけを消費する。この合計を強度設定として扱えば何も変わらない編集に終わるが、この形式は単一のアルゴリズムが使う量より多くの素材を保持するように作られている。

ここでは、ファイルがどれだけの鍵素材を保存しているかという問いと、折衝された暗号がどれだけ強いかという問いが混ざっている。トンネルを説明するのは後者だけだ。

バナーの数値が実際に数えているもの

コンテナは暗号素材と HMAC 素材を別個の構造として直列化し、双方向の形式はそうした組を二つ保持して各方向が独自の鍵を持てるようにしている。書き込み側のコードは、直列化された構造の数とその大きさ、そして一バイトあたり八ビットから印字される数を導く。これは保存量についての算術であり、一つの暗号があらゆる保存バイトを消費するという主張ではない。ヘッダは暗号素材の最大割り当ても固定しており、ライブラリの変更が形式の寸法を黙って変えられないようにしている。

これを証明書の鍵と比べてみると、そこではビット数が確かに一つの対象の大きさを表す。4,096 ビットの RSA 鍵と、バナーに 4,096 ビットと記された鍵ファイルは、役割の異なる別の成果物であり、両者を一つのダイヤルの二つの設定として並べると誤った結論になる。

一つのファイルに二組の鍵

ファイルのどちら半分も暗号化と認証の素材を供給するのは、事前共有鍵モードがその別個の部品で両方向のパケットを守るからだ。有効な暗号はその鍵長が要求するバイトだけを使い、ダイジェストは自身の出力長を使うので、使える強度はファイルの長さではなくオプションから決まる。十六進の塊を延ばしても、設定されたアルゴリズムに多くを消費させることにはならない。コメントをより大きな数値に書き換えても、さらに何も変わらない。

本当に長い鍵が欲しいなら、変えるべき設定は暗号かダイジェストであり、生成器は選択したアルゴリズムが必要とするものを出力する。

プロファイルを読めば、どちらのモードかが分かる

同じファイル形式がまったく異なる二つの役割を担い、どちらなのかはプロファイルだけが示す。旧来の secret 行はファイルをトンネル唯一の鍵素材にし、tls-auth や tls-crypt は証明書と並ぶ制御チャネルの保護にする。どちらの用途でも、ブロックがどれほど似て見えても、クライアント証明書の秘密鍵にはならない。代替品を生成する前にオプションとバージョンを特定し、文字を付け足すのではなく文書化された生成器を使うこと。

この区別は露出への対応も決める。漏れた tls-auth 鍵はセッション鍵を露出させないが、攻撃者に制御チャネルへの通信注入を許すため、それでも交換が必要だ。漏れた secret 鍵がさらに悪いのは、データそのものを守っていた素材だったからだ。

セキュリティレビューが記録すべきこと

折衝されたデータチャネルの保護、制御チャネルの保護、そしてピアがどう認証するかという三つを別個に記録する。data-ciphers AES-256-GCM のような行は一つ目しか説明しておらず、そこで止まる報告書は制御チャネルがそもそも保護されているか答えられない。静的鍵ファイルは tls-auth や tls-crypt と使う場合は二つ目の分類に入り、使わない場合はどちらにも入らない。分類を混同するレビュアは、より強い暗号を望んでいるのに、より大きな鍵ファイルを求めてしまう。

ファイルが露出したなら、承認された経路でローテーションして再配布する。侵害された秘密に文字を足すのはローテーションではなく、露出した素材を有効なまま残す。

ローテーションの記録は、それが属するプロファイルと一緒に保管する。次のレビューは どの鍵がどの期間を守ったのかを問うだろうし、バナーはそれに答えない。