VPN の秘密鍵にかけたパスフレーズが実際に守るもの

VPN クライアントの起動時に表示されるプロンプトは、誤解しやすい。これは VPN アカウントのパスワードでも、トンネルのパスワードでもなく、入力しても接続が安全になるわけではない。これは保存された秘密鍵の表現の一つを解錠し、クライアントが鍵素材を読んで認証に使えるようにする。その後に起きることは別の話だ。

実際に答えが崩れるのは端の部分だ。パスフレーズが動作中のトンネルを守る、あるいは変更すればすでに漏えいした鍵のコピーが失効する、という思い込みだ。どちらも成り立たず、しかも資格情報を露出させたまま運用者が処理済みだと信じる形で成り立たない。

一つのダイアログ、複数の異なる秘密

秘密鍵のパスフレーズはファイルを復号する。アカウントのパスワードはサービスに対する本人確認だ。PKCS#12 のインポートパスワードは鍵とその証明書を含むバンドルを復号し、鍵自身のパスフレーズと同じ文字列とは限らない。これらのプロンプトはほぼ同じに見えることがあり、どの秘密をどこに入れるかを推測することが、鍵を間違った欄に貼り付ける原因になる。

トンネル自体の暗号化は四つ目の話だ。データチャネルはハンドシェイクで交渉したセッション鍵を使い、秘密鍵のパスフレーズは個々のパケットの保護に関与しない。鍵ファイルを読める者がいれば、その者はオフラインでパスフレーズを推測できるが、パケットを読める者にとってパスフレーズは無関係だ。

ディスク上の暗号化が覆う範囲

暗号化された PEM 鍵には二つの形があり、ヘッダーでどちらかが分かる。現代的な PKCS#8 形式は -----BEGIN ENCRYPTED PRIVATE KEY----- で始まり、古い OpenVPN 設定で今も一般的な旧 PEM 形式は -----BEGIN RSA PRIVATE KEY----- で始まり、そのすぐ下に Proc-Type: 4,ENCRYPTED と DEK-Info の行を持つ。ファイルは、パスフレーズから導出した鍵の下で秘密鍵を暗号化して保持する。通常は反復回数や作業係数が示されたパスワードベースの KDF を使う。OpenSSL pkey のドキュメントが形式と読み取り時のパスフレーズ指定を扱っている。

そこから二つの帰結が出る。弱いパスフレーズは KDF が許す速度でオフライン攻撃できるため、ファイルが暗号化されていてもファイル権限とバックアップへのアクセスは依然として重要だ。そしてパスフレーズなしでファイルだけを入手した攻撃者は推測するしかないが、ファイルとパスフレーズの両方を入手した者は鍵を持ち、暗号化されていなかった場合とまったく同じになる。

head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout

head -3 はヘッダーを示し、旧形式のファイルでは暗号化を証明する Proc-Type と DEK-Info の行を示す。一行だけではどちらの証拠にもならない。pkey の行はパスフレーズを求め、公開側だけを出力するので、ファイルとパスフレーズが機能することが 秘密鍵を露出せずに 証明される。その確認に -text を使ってはいけない。秘密の構成要素 privateExponent、prime1、prime2 などが出力され、その出力はチケット、チャット、ログのどこにも貼ってはならない。PKCS#12 コマンドは、バンドルに別の MAC または暗号化パスワードがあるかも教えてくれる。同僚に渡す前に知っておく価値がある。

鍵が読み込まれた後に守らなくなるもの

解錠はそのプロセスにとって一方通行の出来事だ。クライアントは KDF に鍵を要求し、ファイルを復号し、必要な間だけ秘密鍵をメモリに保持する。その瞬間から、パスフレーズは動作中のセッションについて何も守らない。プロセスのメモリも、コアダンプも、クライアントに接続されたデバッグセッションも、鍵の使用中に取得されたマシンのバックアップも守らない。

これはパスフレーズ付きの SSH 鍵や、パスワードマネージャーの解錠された保管庫と同じ境界だ。保管中のファイルを盗むコストを上げるだけで、あなたのユーザーとして動くマルウェア、クライアントに署名を求める認可済みアプリケーション、メモリを読める管理者には何の効果もない。鍵を放置しても安全にする制御ではなく、一つの層として扱うべきだ。

プロンプトが何度も戻ってくる理由

再接続のたびに再び尋ねるクライアントが必ずしも壊れているわけではない。パスフレーズをセッション用にキャッシュするクライアントもあれば、OS のキーチェーンに保存するものもあり、提供するヘルパーを指し示せるものもある。したがって得られる挙動はクライアントとその設定に依存し、鍵ファイルには依存しない。

繰り返されるプロンプトが本当の不満なら、鍵から暗号化を外す前にクライアントのキャッシュと認証の設定を確認する。パスフレーズを外すと保護されたファイルが平文の鍵になり、再接続は静かになるが、唯一の保管時制御を失う。より良い答えは通常、同じファイル権限を使う対応済みの資格情報ストアだ。

紛失と露出は同じ修理ではない

失われたパスフレーズは証明書から復元できない。証明書は名前を鍵に結び付ける公開素材であり、秘密鍵への戻り道もパスフレーズの手がかりも含まない。実際の選択肢は、鍵の認可されたバックアップか、運用者の通常の手続きで発行される新しい身元だ。パスフレーズを「復元する」と申し出る者は、それを推測すると申し出ている。

露出には別の対応が必要だ。同じ鍵を新しいパスフレーズで再暗号化しても鍵素材は変わらないので、すでに別の場所で解錠されたコピーは依然として使える。修理は資格情報の失効または交換だ。新しい鍵と証明書を発行し、配布し、相手側で古いものを引退させる。それが済むまで、ファイルのパスワード変更は後片付けであり、封じ込めではない。新しい身元が機能することを確認してから古いファイルをバックアップから外し、どのシリアル番号や指紋が置き換えたかを記録する。