Ét certifikat pr. enhed gør ikke nøglen enhedsbundet
Et certifikat pr. enhed er et administrativt valg, ikke en binding til enheden. Det, der afgør bindingen, er hvor den private nøgle ligger, fra en kopierbar fil til en TPM.
Du udsteder et separat certifikat til hver bærbar computer, så du antager, at VPN'en kan skelne dem. Det kan den ikke. Et klientcertifikat beviser, at den, der forbinder, har den matchende private nøgle, og en kopieret profil har den også.
Certifikatet pr. enhed er stadig en god idé. Det gør bare et andet stykke arbejde, end de fleste forventer.
Hvad et klientcertifikat faktisk beviser
Under håndtrykket signerer klienten med den private nøgle, der matcher dens certifikat, og serveren verificerer signaturen mod den CA, den stoler på. Intet i den udveksling beskriver maskinen. Enhver enhed, der har både certifikatet og nøglen, producerer en identisk signatur, så en profil kopieret til en anden bærbar computer ser nøjagtig ud som originalen. Certifikatet navngiver en identitet; det navngiver ikke hardware.
Unikhed pr. enhed betaler sig stadig, fordi den gør tilbagekaldelse præcis. Det er en administrativ egenskab, ikke en teknisk lås.
Tre niveauer af nøgleopbevaring
Det første niveau er en nøglefil på disken. Den er bærbar af design, og det er der, de fleste OpenVPN-profiler bor.
Det andet niveau er en nøgle, som styresystemet markerer som ikke-eksporterbar. Windows kan generere en enhedsnøgle i sit certifikatlager og afvise almindelig eksport, hvilket stopper tilfældig kopiering. Den er ikke hardwareunderstøttet, og med tilstrækkelig adgang til maskinen kan sådanne nøgler gendannes, så den øger indsatsen i stedet for at bygge en mur.
Det tredje niveau er en nøgle genereret inde i sikkerhedshardware: en TPM, et smartkort, et SIM-kort eller et PIV-token. Disse moduler mangler kredsløbet til at eksportere den nøgle, de genererede, og signeringen foregår inde i modulet. Nøglen bliver aldrig en fil, som nogen kan kopiere.
| 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 |
Den tabel er hele argumentet i tre rækker.
Hvad easy-rsa kan og ikke kan
Det er ligetil at udstede certifikater pr. enhed. Opret et særskilt fællesnavn pr. enhed mod den samme CA, for eksempel ./easyrsa build-client-full laptop-a nopass, og gentag for hver enhed. Noter, hvilket fællesnavn der hører til hvilken person og maskine.
Tilbagekaldelse er lige så direkte: ./easyrsa revoke laptop-a, genopret CRL'en med ./easyrsa gen-crl, og sørg for, at serveren faktisk læser den via crl-verify.
Det, CA'en ikke kan, er at verificere, hvor den private nøgle ligger bagefter. Hvis du genererer nøglen på CA-værten og kopierer den til enheden, har du skabt en anden kopi ved udstedelsen. En ikke-eksporterbar nøgle skal genereres på enheden eller importeres til hardware, der ikke frigiver den.
Kontroller, der overlever en kopieret profil
Antag, at profilen kan kopieres, og design ud fra det. Bind kontoen til en anden faktor, så et certifikat alene ikke er nok. Giv hver enhed sin egen politik, så én identitets rækkevidde forbliver begrænset. Og hold øje med det samme fællesnavn forbundet fra to adresser på én gang, for det er sådan en delt profil ser ud i en forbindelseslog.
Hurtig, dokumenteret tilbagekaldelse er den kontrol, der stadig virker, efter at en kopi er sket. Alt andet er forebyggelse.
Den påstand, serveren faktisk kan stole på
Unikhed kommer fra CA'en. Enhedsbinding kommer fra nøgleopbevaring. Kun hardware, der ikke kan eksportere sin nøgle, gør ét certifikat pr. enhed til en erklæring, som serveren håndhæver, i stedet for en politik, som alle er enige om at følge.