openssl rand が tls-crypt の求める鍵を作れない理由

OpenSSL はすでに導入されており、ホストにはエントロピーもあり、それで鍵を作るのが明白な近道に思えます。出力はランダムで秘密で、そしてまったく使えませんが、失敗は鍵の形式に触れるものではなく制御チャネルのエラーとして現れます。この誤誘導が高くつく部分であり、人々が暗号方式を調べ始める原因になります。VPN が読むのは特定のファイル構造であって任意のバイト列ではなく、しかもこの機能の一方の変種はサーバーの外ではまったく作れません。

ディスク上のファイルが実際にどうあるべきか

OpenVPN の静的鍵ファイルはテキストです。それが何であるかを宣言するコメント行で始まり、固定幅の行に十六進データを並べ、合計 256 バイトの鍵素材を持ちます。OpenVPN はそれを制御チャネルの共有秘密として読み、証明書としても、パスフレーズとしても、TLS ライブラリが認識する何かとしても読みません。

同じ種類のオブジェクトが制御チャネルの両方の機能に使われます。tls-auth では、片側のパケットが自分に反射されないように、各ピアに方向も必要です。tls-crypt では、単一の共有秘密が制御チャネルを両方向で暗号化および認証し、ハンドシェイクを隠すと同時に保護します。

そのどれも秘密の知識ではなく、形式が要点ではありません。要点は、ファイルが読み手の期待するヘッダー、行幅、末尾の改行、全体の長さに正確に一致しなければならないことです。一行ずれたファイルはゴミとして読み込まれるか、完全に失敗します。したがって、二つのピアをバイト単位で比較することは正当な最初のテストであり、二つの設定ファイルのどちらかを読むより速い方法です。

サポートされた作り方

消費する側のツールで単純な静的鍵を生成し、両端からそれを参照します：

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

オプションの綴りは時代とともに変わり、2.4 時代の古い導入ではファイル名の前に別のフラグを置く形を使っていましたが、現在のビルドは短い方を受け付けます。いずれにせよ生成されるファイルは同じ種類のオブジェクトなので、確認すべきは両方のピアが同一のバイトを持っているかどうかです。

第二世代は、外部の生成器が発明できない構造を加え、サーバー鍵が一度だけ作られて各クライアントはそこから派生したラップされた鍵を受け取ります。

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

クライアントが受け取るのは、サーバー自身の鍵を複製したものではありません。サーバーだけが開けるメタデータを運ぶラップされたオブジェクトであり、このラップがあるからこそ、デバイスごとのファイルを 他のどのデバイスにも触れずに失効させられます。サーバー鍵はサーバー上に保管し、そのデバイスごとの信頼の根として扱ってください。

手製のバイトが破綻する場所

正しいヘッダーの下に 256 個のランダムなバイトを十六進で出力すれば、理論上は読み込める静的鍵ファイルになります。それでも悪い考えです。書式の細部がすべて、読み込み時に失敗する素材、あるいはさらに悪いことに、認証失敗としてしか現れない異なる値を二つのピアに持たせる素材を作る機会になります。

v2 変種では同等のことはできません。ラップされたクライアント鍵はサーバー鍵プロセスの出力としてしか存在せず、サーバーはそれを開くのに必要な素材を保持します。ランダムな塊は拒否されるか、単に復号に失敗し、どちらのメッセージもランダム性には触れません。

バージョン互換性はこのすべての上に乗っています。第一世代は両端でそれをサポートするリリースが必要で、第二世代はさらに新しいリリースが必要です。機能が存在する前にビルドされたクライアントは、ラップされた素材しか受け付けないサーバーとハンドシェイクを完了できず、報告される失敗はバージョンではなく制御チャネルを指します。

全員を締め出さずにローテーションする

単一の共有秘密のローテーションは技術的な作業ではなく、調整の作業です。サーバーが前のものを撤回する前に、すべてのクライアントが交換用ファイルを手元に持っている必要があり、古い値を持ったままのマシンはその瞬間に失敗します。勤務日の途中でそのローテーションを始めないでください。

v2 の構成では、ローテーションはデバイスごとで、一台のマシンに新しいラップされた鍵を発行し、古いものはそのマシンのためだけに引退させます。すべてのクライアントがそれをサポートするリリースになったら移行する、というのが主な論拠です。

ファイルの権限も同じ話です。鍵はサービスを実行するアカウントだけが読めるべきで、それが保護するプロファイルと同じリポジトリに置くべきではありません。OpenVPN 2.6 のリファレンスは生成形式と鍵素材の節を文書化しており、フォーラム投稿からコピーしたコマンドより良い情報源です。