Eitt sertifikat per eining gjer ikkje nøkkelen einingbunden
Eit sertifikat per eining er eit administrativt val, ikkje ei binding til eininga. Det som avgjer bindinga, er kvar den private nøkkelen ligg, frå ei kopierbar fil til ein TPM.
Du gjev ut eit eige sertifikat for kvar berbar PC, så du reknar med at VPN-en kan skilje dei. Det kan han ikkje. Eit klientsertifikat provar at den som koplar til har den samsvarande private nøkkelen, og ein kopiert profil har han òg.
Sertifikatet per eining er framleis ein god idé. Det gjer berre ein annan jobb enn dei fleste ventar.
Kva eit klientsertifikat faktisk provar
Under handtrykket signerer klienten med den private nøkkelen som passar til sertifikatet, og tenaren stadfester signaturen mot CA-en han stolar på. Ingenting i den utvekslinga skildrar maskinen. Kvar eining som har både sertifikatet og nøkkelen, lagar ein identisk signatur, så ein profil kopiert til ein annan berbar PC ser nøyaktig ut som originalen. Sertifikatet namngjev ein identitet; det namngjev ikkje maskinvare.
Unikskap per eining svarar seg framleis, fordi det gjer tilbakekallinga presis. Det er ein administrativ eigenskap, ikkje ein teknisk lås.
Tre nivå av nøkkellagring
Det første nivået er ei nøkkelfil på disken. Ho er berbar av design, og det er der dei fleste OpenVPN-profilane bur.
Det andre nivået er ein nøkkel som operativsystemet merkjer som ikkje-eksporterbar. Windows kan lage ein einingsnøkkel i sertifikatlageret og nekte vanleg eksport, noko som stoppar tilfeldig kopiering. Han er ikkje maskinvarebasert, og med nok tilgang til maskinen kan slike nøklar gjenopprettast, så det aukar innsatsen i staden for å byggje ein mur.
Det tredje nivået er ein nøkkel laga inne i tryggleiksmaskinvare: ein TPM, eit smartkort, eit SIM-kort eller eit PIV-token. Desse modulane manglar krinsane for å eksportere nøkkelen dei laga, og signeringa skjer inne i modulen. Nøkkelen vert aldri ei fil nokon 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 heile argumentet i tre radar.
Kva easy-rsa kan og ikkje kan
Å gje ut sertifikat per eining er enkelt. Lag eit eige fellesnamn per eining mot den same CA-en, til dømes ./easyrsa build-client-full laptop-a nopass, og gjer det same for kvar eining. Skriv ned kva fellesnamn som høyrer til kven og kva maskin.
Tilbakekalling er like direkte: ./easyrsa revoke laptop-a, lag CRL-en på nytt med ./easyrsa gen-crl, og pass på at tenaren faktisk les han via crl-verify.
Det CA-en ikkje kan, er å stadfeste kvar den private nøkkelen ligg etterpå. Viss du lagar nøkkelen på CA-verten og kopierer han til eininga, har du laga ein andre kopi ved utgivinga. Ein ikkje-eksporterbar nøkkel må lagast på eininga, eller importerast til maskinvare som ikkje slepp han ut.
Kontrollar som overlever ein kopiert profil
Rekn med at profilen kan kopierast, og design deretter. Bind kontoen til ein andre faktor slik at eit sertifikat åleine ikkje er nok. Gje kvar eining si eiga policy slik at rekkjevidda til éin identitet held seg avgrensa. Og fylg med på det same fellesnamnet som koplar til frå to adresser samstundes, for det er slik ein delt profil ser ut i ein tilkoplingslogg.
Rask, dokumentert tilbakekalling er kontrollen som framleis verkar etter at ein kopi er teken. Alt anna er førebygging.
Påstanden tenaren faktisk kan stole på
Unikskap kjem frå CA-en. Einingbinding kjem frå nøkkellagring. Berre maskinvare som ikkje kan eksportere nøkkelen sin, gjer eitt sertifikat per eining til ein påstand tenaren handhevar, i staden for ein policy alle er samde om å fylgje.