Ett sertifikat per enhet gjør ikke nøkkelen enhetsbundet
Et sertifikat per enhet er et administrativt valg, ikke en binding til enheten. Det som avgjør bindingen, er hvor den private nøkkelen ligger, fra en kopierbar fil til en TPM.
Du utsteder et eget sertifikat for hver bærbar PC, så du antar at VPN-en kan skille dem. Det kan den ikke. Et klientsertifikat beviser at den som kobler til har den matchende private nøkkelen, og en kopiert profil har den også.
Sertifikatet per enhet er fortsatt en god idé. Det gjør bare en annen jobb enn de fleste forventer.
Hva et klientsertifikat faktisk beviser
Under håndtrykket signerer klienten med den private nøkkelen som passer til sertifikatet, og serveren verifiserer signaturen mot CA-en den stoler på. Ingenting i den utvekslingen beskriver maskinen. Enhver enhet som har både sertifikatet og nøkkelen, produserer en identisk signatur, så en profil kopiert til en annen bærbar PC ser nøyaktig ut som originalen. Sertifikatet navngir en identitet; det navngir ikke maskinvare.
Unikhet per enhet lønner seg fortsatt, fordi det gjør tilbakekalling presis. Det er en administrativ egenskap, ikke en teknisk lås.
Tre nivåer av nøkkellagring
Det første nivået er en nøkkelfil på disken. Den er bærbar av design, og det er der de fleste OpenVPN-profilene bor.
Det andre nivået er en nøkkel som operativsystemet merker som ikke-eksporterbar. Windows kan generere en enhetsnøkkel i sertifikatlageret og nekte vanlig eksport, noe som stopper tilfeldig kopiering. Den er ikke maskinvarebasert, og med nok tilgang til maskinen kan slike nøkler gjenopprettes, så den øker innsatsen i stedet for å bygge en mur.
Det tredje nivået er en nøkkel generert inne i sikkerhetsmaskinvare: en TPM, et smartkort, et SIM-kort eller et PIV-token. Disse modulene mangler kretsene for å eksportere nøkkelen de genererte, og signeringen skjer inne i modulen. Nøkkelen blir aldri en fil noen 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 tabellen er hele argumentet i tre rader.
Hva easy-rsa kan og ikke kan
Å utstede sertifikater per enhet er enkelt. Opprett et eget fellesnavn per enhet mot den samme CA-en, for eksempel ./easyrsa build-client-full laptop-a nopass, og gjenta for hver enhet. Noter hvilket fellesnavn som hører til hvilken person og maskin.
Tilbakekalling er like direkte: ./easyrsa revoke laptop-a, regenerer CRL-en med ./easyrsa gen-crl, og sørg for at serveren faktisk leser den via crl-verify.
Det CA-en ikke kan, er å verifisere hvor den private nøkkelen ligger etterpå. Hvis du genererer nøkkelen på CA-vertsmaskinen og kopierer den til enheten, har du laget en andre kopi ved utstedelsen. En ikke-eksporterbar nøkkel må genereres på enheten, eller importeres til maskinvare som ikke slipper den ut.
Kontroller som overlever en kopiert profil
Anta at profilen kan kopieres, og design deretter. Bind kontoen til en andre faktor slik at et sertifikat alene ikke er nok. Gi hver enhet sin egen policy slik at rekkevidden til én identitet holder seg begrenset. Og følg med på det samme fellesnavnet som kobler til fra to adresser samtidig, for det er slik en delt profil ser ut i en tilkoblingslogg.
Rask, dokumentert tilbakekalling er kontrollen som fortsatt virker etter at en kopi er tatt. Alt annet er forebygging.
Påstanden serveren faktisk kan stole på
Unikhet kommer fra CA-en. Enhetsbinding kommer fra nøkkellagring. Bare maskinvare som ikke kan eksportere nøkkelen sin, gjør ett sertifikat per enhet til en påstand serveren håndhever, i stedet for en policy alle er enige om å følge.