Ein Zertifikat pro Gerät macht den Schlüssel nicht gerätegebunden
Ein Zertifikat pro Gerät ist eine administrative Entscheidung, keine Gerätebindung. Was die Bindung bestimmt, ist der Speicherort des privaten Schlüssels, von einer kopierbaren Datei bis zu einem TPM.
Sie stellen für jeden Laptop ein eigenes Zertifikat aus und nehmen daher an, das VPN könne sie unterscheiden. Das kann es nicht. Ein Client-Zertifikat beweist, dass wer sich verbindet, den passenden privaten Schlüssel besitzt, und ein kopiertes Profil besitzt ihn auch.
Das Zertifikat pro Gerät ist trotzdem eine gute Idee. Es erfüllt nur eine andere Aufgabe, als die meisten erwarten.
Was ein Client-Zertifikat tatsächlich beweist
Während des Handshakes signiert der Client mit dem privaten Schlüssel, der zu seinem Zertifikat passt, und der Server prüft diese Signatur gegen die CA, der er vertraut. Nichts an diesem Austausch beschreibt die Maschine. Jedes Gerät, das Zertifikat und Schlüssel besitzt, erzeugt eine identische Signatur, sodass ein auf einen zweiten Laptop kopiertes Profil genauso aussieht wie das Original. Das Zertifikat benennt eine Identität; es benennt keine Hardware.
Eindeutigkeit pro Gerät lohnt sich weiterhin, weil sie den Widerruf präzise macht. Sie ist eine administrative Eigenschaft, kein technisches Schloss.
Drei Stufen der Schlüsselspeicherung
Die erste Stufe ist eine Schlüsseldatei auf der Festplatte. Sie ist von Natur aus portabel, und dort liegen die meisten OpenVPN-Profile.
Die zweite Stufe ist ein Schlüssel, den das Betriebssystem als nicht exportierbar kennzeichnet. Windows kann einen Geräteschlüssel im Zertifikatsspeicher erzeugen und den gewöhnlichen Export verweigern, was beiläufiges Kopieren verhindert. Er ist nicht hardwaregestützt, und mit genügend Zugriff auf die Maschine lassen sich solche Schlüssel wiederherstellen, also erhöht er den Aufwand, statt eine Mauer zu bauen.
Die dritte Stufe ist ein Schlüssel, der in Sicherheitshardware erzeugt wird: ein TPM, eine Smartcard, eine SIM-Karte oder ein PIV-Token. Diese Module haben keine Schaltkreise, um den erzeugten Schlüssel zu exportieren, und das Signieren findet im Modul statt. Der Schlüssel wird nie zu einer Datei, die jemand kopieren kann.
| Where the key lives | Copyable | What it buys you |
|---|---|---|
| Key file inside the profile | Trivially | Revocation granularity, nothing more |
| OS non-exportable key store | Hard, not impossible | Stops casual profile sharing |
| TPM or PIV token | No | Binding the server can rely on |
Diese Tabelle ist das ganze Argument in drei Zeilen.
Was easy-rsa kann und was nicht
Zertifikate pro Gerät auszustellen ist unkompliziert. Legen Sie einen eigenen allgemeinen Namen pro Gerät gegen dieselbe CA an, zum Beispiel ./easyrsa build-client-full laptop-a nopass, und wiederholen Sie das für jedes Gerät. Halten Sie fest, welcher allgemeine Name zu welcher Person und Maschine gehört.
Der Widerruf ist ebenso direkt: ./easyrsa revoke laptop-a, erzeugen Sie die CRL mit ./easyrsa gen-crl neu und stellen Sie sicher, dass der Server sie tatsächlich über crl-verify liest.
Was die CA nicht kann, ist zu prüfen, wo der private Schlüssel danach liegt. Wenn Sie den Schlüssel auf dem CA-Host erzeugen und auf das Gerät kopieren, haben Sie bei der Ausstellung eine zweite Kopie erzeugt. Ein nicht exportierbarer Schlüssel muss auf dem Gerät erzeugt oder in Hardware importiert werden, die ihn nicht herausgibt.
Kontrollen, die ein kopiertes Profil überstehen
Nehmen Sie an, dass das Profil kopiert werden kann, und entwerfen Sie entsprechend. Binden Sie das Konto an einen zweiten Faktor, damit ein Zertifikat allein nicht reicht. Geben Sie jedem Gerät seine eigene Richtlinie, damit die Reichweite einer Identität begrenzt bleibt. Und achten Sie auf denselben allgemeinen Namen, der gleichzeitig von zwei Adressen verbindet, denn so sieht ein geteiltes Profil im Verbindungsprotokoll aus.
Ein schneller, dokumentierter Widerruf ist die Kontrolle, die auch nach einer Kopie noch wirkt. Alles andere ist Vorbeugung.
Die Aussage, auf die sich der Server wirklich verlassen kann
Eindeutigkeit kommt von der CA. Gerätebindung kommt von der Schlüsselspeicherung. Nur Hardware, die ihren Schlüssel nicht exportieren kann, macht aus einem Zertifikat pro Gerät eine Aussage, die der Server durchsetzt, statt einer Richtlinie, der alle zustimmen.