Ett certifikat per enhet gör inte nyckeln enhetsbunden
Ett certifikat per enhet är ett administratörsval, inte en enhetsbindning. Det som avgör bindningen är var den privata nyckeln finns, från en kopierbar fil till en TPM.
Du utfärdar ett eget certifikat för varje laptop och antar därför att VPN kan skilja dem åt. Det kan den inte. Ett klientcertifikat bevisar att den som ansluter har den matchande privata nyckeln, och en kopierad profil har den också.
Certifikatet per enhet är fortfarande en bra idé. Det gör bara ett annat jobb än de flesta förväntar sig.
Vad ett klientcertifikat faktiskt bevisar
Under handskakningen signerar klienten med den privata nyckel som hör till certifikatet, och servern verifierar signaturen mot den CA den litar på. Inget i det utbytet beskriver maskinen. Varje enhet som har både certifikatet och nyckeln producerar en identisk signatur, så en profil som kopierats till en andra laptop ser exakt ut som originalet. Certifikatet namnger en identitet; det namnger inte hårdvara.
Unikhet per enhet är fortfarande värt något, eftersom det gör återkallelsen exakt. Det är en administrativ egenskap, inte ett tekniskt lås.
Tre nivåer av nyckellagring
Den första nivån är en nyckelfil på disken. Den är portabel till sin natur, och det är där de flesta OpenVPN-profiler ligger.
Den andra nivån är en nyckel som operativsystemet markerar som icke-exporterbar. Windows kan generera en enhetsnyckel i sitt certifikatarkiv och vägra vanlig export, vilket stoppar tillfällig kopiering. Den är inte hårdvarustödd, och med tillräcklig åtkomst till maskinen kan sådana nycklar återställas, så den höjer insatsen i stället för att bygga en mur.
Den tredje nivån är en nyckel som genereras inuti säkerhetshårdvara: en TPM, ett smartkort, ett SIM eller en PIV-token. De modulerna saknar kretsar för att exportera nyckeln de genererade, och signeringen sker inuti modulen. Nyckeln blir aldrig en fil som någon kan kopiera.
| 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 är hela argumentet i tre rader.
Vad easy-rsa kan och inte kan
Att utfärda certifikat per enhet är enkelt. Skapa ett eget vanligt namn för varje enhet mot samma CA, till exempel ./easyrsa build-client-full laptop-a nopass, och upprepa för varje enhet. Anteckna vilket vanligt namn som hör till vilken person och maskin.
Återkallelsen är lika direkt: ./easyrsa revoke laptop-a, generera om CRL med ./easyrsa gen-crl och se till att servern verkligen läser den via crl-verify.
Det CA:n inte kan är att verifiera var den privata nyckeln sedan finns. Om du genererar nyckeln på CA-värden och kopierar den till enheten har du skapat en andra kopia vid utfärdandet. En icke-exporterbar nyckel måste genereras på enheten eller importeras till hårdvara som inte släpper den.
Kontroller som överlever en kopierad profil
Anta att profilen kan kopieras och konstruera runt det. Bind kontot till en andra faktor så att certifikatet ensamt inte räcker. Ge varje enhet sin egen policy så att en identitets räckvidd förblir begränsad. Och håll utkik efter samma vanliga namn anslutet från två adresser samtidigt, vilket är hur en delad profil ser ut i en anslutningslogg.
Snabb, dokumenterad återkallelse är den kontroll som fortfarande fungerar efter att en kopia har skett. Allt annat är förebyggande.
Det påstående som servern faktiskt kan lita på
Unikheten kommer från CA:n. Enhetsbindningen kommer från nyckellagringen. Bara hårdvara som inte kan exportera sin nyckel förvandlar ett certifikat per enhet till ett påstående som servern upprätthåller, i stället för en policy som alla kommer överens om att följa.