端末ごとに証明書を一枚発行しても鍵が端末に縛られるわけではない

ノートPCごとに別々の証明書を発行しているので、VPNがそれらを見分けられると考えている。見分けられない。クライアント証明書が証明するのは、接続する者が対応する秘密鍵を持っていることであり、コピーされたプロファイルも同じ鍵を持っている。

端末ごとの証明書は今でも良い考えだ。ただ、多くの人が期待するのとは違う仕事をしているだけだ。

クライアント証明書が実際に証明するもの

ハンドシェイクの間、クライアントは自分の証明書に対応する秘密鍵で署名し、サーバーはその署名を信頼するCAに対して検証する。そのやり取りのどこにもマシンの記述はない。証明書と鍵の両方を持つ端末はどれも同じ署名を作るので、二台目のノートPCにコピーされたプロファイルは原本とまったく同じに見える。証明書が名指しするのは身元であり、ハードウェアではない。

端末ごとの一意性は、失効を正確にするという理由で依然として価値がある。これは管理上の性質であり、技術的な錠ではない。

鍵の保管には三つの段階がある

第一段階はディスク上の鍵ファイルだ。設計上持ち運べるもので、ほとんどのOpenVPNプロファイルはそこにある。

第二段階は、OSがエクスポート不可と印を付けた鍵だ。Windowsは証明書ストア内にデバイス鍵を生成し、通常のエクスポートを拒否できるので、気軽なコピーは防げる。ただしハードウェアによる裏付けはなく、マシンへの十分なアクセスがあればそうした鍵は復元できるので、壁を作るのではなく手間を増やすだけだ。

第三段階は、TPM、スマートカード、SIM、PIVトークンといったセキュリティハードウェアの内部で生成される鍵だ。これらのモジュールには、自分が生成した鍵をエクスポートする回路がなく、署名はモジュール内部で行われる。鍵が誰かにコピーできるファイルになることはない。

その表が三行で示す議論のすべてだ。

easy-rsaにできることとできないこと

端末ごとの証明書の発行は簡単だ。同じCAに対して端末ごとに別のコモンネームを作り、たとえば ./easyrsa build-client-full laptop-a nopass を実行して端末ごとに繰り返す。どのコモンネームがどの人物とマシンに属するかを記録しておく。

失効も同じくらい直接的で、./easyrsa revoke laptop-a を実行し、./easyrsa gen-crl でCRLを再生成し、サーバーが crl-verify を通じて実際にそれを読むことを確認する。

CAにできないのは、その後で秘密鍵がどこにあるかを検証することだ。CAホストで鍵を生成して端末にコピーしたなら、発行の時点で二つ目のコピーを作ったことになる。エクスポート不可の鍵は端末上で生成するか、鍵を手放さないハードウェアにインポートする必要がある。

コピーされたプロファイルに耐える統制

プロファイルはコピーされうると想定して設計する。アカウントを第二要素に結び付け、証明書だけでは足りないようにする。端末ごとに独自のポリシーを与え、一つの身元の到達範囲を限定する。そして、共有プロファイルが接続ログでそう見えるので、同じコモンネームが二つのアドレスから同時に接続していないか監視する。

速やかで文書化された失効こそ、コピーが起きた後でも機能する統制だ。それ以外はすべて予防である。

サーバーが実際に依拠できる主張

一意性はCAから来る。端末への紐付けは鍵の保管から来る。鍵をエクスポートできないハードウェアだけが、端末ごとの証明書を、全員が従うと合意したポリシーではなく、サーバーが強制する主張に変える。