VPNの公開鍵は共有できるのか。確認すべき三つのこと
公開側を公開することはプロトコルの仕組みそのものですが、秘密側を公開すると身元を渡すことになります。三つの確認で、手元にある値がどちらかが決まります。
VPNの公開鍵は、相手やプロバイダー、フォーラムに渡してもトンネルは維持されます。秘密鍵は、それを渡すことで証明される身元ごと渡すことになるため、サポート担当者であっても渡せません。判断がこれほど単純で済むことはまれです。人はペアのどちらの半分を見ているのかを混同しますし、配備によっては公開値を名前のように扱うからです。三つの確認が決め手になります。どちらの半分を持っているのか、配備がその値を何に結び付けているのか、そして交換にどれだけのコストがかかるのかです。
確認その一。ペアのどちらの半分がクリップボードにあるか
非対称鍵はペアで存在します。そして導出の向きが要点です。WireGuardでは秘密鍵が32個のランダムなバイトで、公開鍵はそこから計算されます。逆方向には進めません。wg genkeyは秘密の値を書き出し、wg pubkeyは公開の値を導出します。相手へのメッセージに入れるのは後者だけです。
wg genkey | tee private.key | wg pubkey > public.key
chmod 600 private.key
openssl x509 -noout -pubkey -in server.crt
証明書の世界も同じ分割を、より多くの部品とともに使います。サーバー証明書は公開鍵と名前を運び、CAの外に出ないCA秘密鍵で署名されます。そのサーバーを検証するクライアントが必要とするのは公開されているCA証明書であり、CAの秘密署名鍵は使いません。
どちらの値を持っているか分からないときは、ファイル名ではなく目印を探してください。-----BEGIN PRIVATE KEY----- で始まるPEMブロック、または古いBEGIN RSA PRIVATE KEY 形式のものは秘密の半分です。その目印なしで貼り付けられる値は、次の二つの確認を条件に共有の候補になります。
確認その二。配備がその公開値を何に結び付けているか
暗号としての安全性と匿名性は別の性質です。WireGuardの相手の公開鍵は、配備の中では安定した識別子です。サーバー設定に並び、ハンドシェイクで名前として使われ、ログを読む管理者はその相手が接続するたびに同じ文字列を見ます。設定についての質問のそばにその鍵を投稿すれば、その文字列を投稿内の他のすべてと結び付けたことになります。
証明書は設計上、身元を漏らします。subjectとsubject alternative nameは読めますし、公的に信頼されるTLS証明書では証明書そのものが検索可能なCertificate Transparencyのログに公開されます。どれも秘密鍵を露出しませんが、すべてが関係を露出します。
ここが配備ごとに異なり、それが答えを決めます。実験用サーバー上の使い捨てのテスト用ピアと、企業の拠点間エンドポイントを識別する鍵は、バイト列が同じに見えても別の対象です。
確認その三。何を、どれくらい速く失効できるか
三つ目の確認は二つの半分を完全に分けます。公開された公開鍵は、自分の都合で交換できます。公開された秘密鍵は取り戻せません。手元のコピーを削除しても、すでに取られたコピーには触れず、それを信頼したすべての相手は今、外部の人間が持つ何かを信頼しています。
失効は暗号の操作ではなく設定の操作です。WireGuardは失効リストを提供しないため、ピアを削除します。
wg set wg0 peer <peer-public-key> remove
# then delete the [Peer] block from the config so it does not return on restart
OpenVPN証明書ベースの配備では証明書を失効させ、サーバーが実際に crl-verify を通じて確認するCRLを公開します。そのディレクティブがなければ失効リストは飾りです。どちらの場合も手順は同じです。交換用を発行し、サポートされた経路で配布し、古い身元を引退させます。
三つの確認を一つにまとめてしまうことで起きる誤り
実際の漏えいの多くは、誰かが秘密鍵を公開しようと決めたことではありません。プロファイル全体をフォーラムに貼り付けた結果です。たとえば .conf というWireGuardの設定に PrivateKey 行があるもの、.ovpn バンドルにインラインの鍵ブロックが入ったもの、あるいは鍵の欄がたまたま写ったクライアント画面のスクリーンショットです。公開値自体はおそらく問題なく、問題のある部分と一緒に旅をしただけです。
サポートのやり取りが第二の発生源です。正当な検証手順で秘密鍵が必要になることはありません。相手側は必要なものを公開側から導出するからです。フォームや人が秘密の値を求めてきたときの正しい答えは、公開値と、それを生成するローカルのコマンドです。
ログとスクリーンショットも同じ分類です。診断出力には鍵素材、セッション識別子、内部アドレスが含まれ得ます。一つの質問に答えるためにそのすべてを投稿することは、小さな便利と引き換えに大きな露出を得ることになります。
秘密の値が漏れた後は、身元を引退させる
秘密の値が実際に外に出たなら、その身元は引退したものとして扱ってください。新しいペアを生成し、相手が期待する場所に公開側をインストールし、古いピアを削除するか古い証明書を失効させ、公開した場所を確認します。自分が管理していないコピーは削除できないので、削除は過去ではなく未来に関わることです。
そして配布を書き留めます。どの鍵がどの端末のものか、誰がコピーを持つか、交換品をどう届けるか、誰が引退したピアを削除するか。忘れられがちなのはこうした部分で、漏えいがどれだけ長く有用であり続けるかを決めます。