Jeden certyfikat na urządzenie nie wiąże klucza z urządzeniem
Certyfikat na każde urządzenie to wybór administracyjny, a nie powiązanie z urządzeniem. O powiązaniu decyduje miejsce przechowywania klucza prywatnego, od kopiowalnego pliku po TPM.
Wydajesz osobny certyfikat dla każdego laptopa, więc zakładasz, że VPN potrafi je rozróżnić. Nie potrafi. Certyfikat klienta dowodzi, że ten, kto się łączy, ma pasujący klucz prywatny, a skopiowany profil też go ma.
Certyfikat na urządzenie to nadal dobry pomysł. Po prostu wykonuje inną pracę, niż większość ludzi oczekuje.
Co właściwie dowodzi certyfikat klienta
Podczas uzgadniania klient podpisuje kluczem prywatnym pasującym do jego certyfikatu, a serwer weryfikuje ten podpis wobec CA, któremu ufa. Nic w tej wymianie nie opisuje maszyny. Każde urządzenie mające i certyfikat, i klucz wytwarza identyczny podpis, więc profil skopiowany na drugi laptop wygląda dokładnie jak oryginał. Certyfikat nazywa tożsamość; nie nazywa sprzętu.
Unikalność na urządzenie nadal się opłaca, bo czyni unieważnienie precyzyjnym. To cecha administracyjna, a nie techniczna kłódka.
Trzy poziomy przechowywania klucza
Pierwszy poziom to plik klucza na dysku. Jest przenośny z założenia i tam mieszka większość profili OpenVPN.
Drugi poziom to klucz, który system operacyjny oznacza jako nieeksportowalny. Windows może wygenerować klucz urządzenia w swoim magazynie certyfikatów i odmówić zwykłego eksportu, co powstrzymuje przypadkowe kopiowanie. Nie jest oparty na sprzęcie, a przy dostatecznym dostępie do maszyny takie klucze da się odzyskać, więc zwiększa wysiłek, zamiast budować mur.
Trzeci poziom to klucz generowany wewnątrz sprzętu bezpieczeństwa: TPM, karta inteligentna, SIM lub token PIV. Te moduły nie mają układów do eksportu wygenerowanego klucza, a podpisywanie odbywa się wewnątrz modułu. Klucz nigdy nie staje się plikiem, który ktoś może skopiować.
| 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 |
Ta tabela to cały argument w trzech wierszach.
Co easy-rsa może, a czego nie może
Wydawanie certyfikatów na urządzenie jest proste. Utwórz odrębną nazwę wspólną dla każdego urządzenia wobec tej samej CA, na przykład ./easyrsa build-client-full laptop-a nopass, i powtórz to dla każdego urządzenia. Zapisz, która nazwa wspólna należy do której osoby i maszyny.
Unieważnienie jest równie bezpośrednie: ./easyrsa revoke laptop-a, wygeneruj ponownie CRL poleceniem ./easyrsa gen-crl i upewnij się, że serwer naprawdę ją czyta przez crl-verify.
CA nie może zweryfikować, gdzie klucz prywatny znajduje się później. Jeśli wygenerujesz klucz na hoście CA i skopiujesz go na urządzenie, przy wydaniu powstała druga kopia. Klucz nieeksportowalny musi zostać wygenerowany na urządzeniu albo zaimportowany do sprzętu, który go nie wyda.
Kontrole, które przetrwają skopiowany profil
Załóż, że profil można skopiować, i projektuj z myślą o tym. Powiąż konto z drugim czynnikiem, żeby sam certyfikat nie wystarczył. Daj każdemu urządzeniu własną politykę, żeby zasięg jednej tożsamości pozostawał ograniczony. I obserwuj tę samą nazwę wspólną łączącą się z dwóch adresów naraz, bo tak wygląda współdzielony profil w dzienniku połączeń.
Szybkie, udokumentowane unieważnienie to kontrola, która działa jeszcze po wykonaniu kopii. Wszystko inne to profilaktyka.
Twierdzenie, na którym serwer naprawdę może polegać
Unikalność pochodzi z CA. Powiązanie z urządzeniem pochodzi z przechowywania klucza. Tylko sprzęt, który nie potrafi wyeksportować swojego klucza, zamienia jeden certyfikat na urządzenie w twierdzenie, które serwer egzekwuje, zamiast w politykę, na którą wszyscy się zgadzają.