Un certificat pe dispozitiv nu leagă cheia de dispozitiv
Un certificat pe dispozitiv este o alegere administrativă, nu o legare de dispozitiv. Ceea ce decide legarea este unde se află cheia privată, de la un fișier copiabil la un TPM.
Emiți un certificat separat pentru fiecare laptop, așa că presupui că VPN-ul le poate distinge. Nu poate. Un certificat de client dovedește că cel care se conectează deține cheia privată corespunzătoare, iar un profil copiat o deține și el.
Certificatul pe dispozitiv rămâne o idee bună. Doar face o altă treabă decât se așteaptă majoritatea oamenilor.
Ce dovedește de fapt un certificat de client
În timpul strângerii de mână, clientul semnează cu cheia privată care corespunde certificatului său, iar serverul verifică semnătura față de CA în care are încredere. Nimic din acel schimb nu descrie mașina. Orice dispozitiv care deține atât certificatul, cât și cheia produce o semnătură identică, așa că un profil copiat pe un al doilea laptop arată exact ca originalul. Certificatul numește o identitate; nu numește hardware.
Unicitatea pe dispozitiv își merită în continuare locul, pentru că face revocarea precisă. Este o proprietate administrativă, nu un lacăt tehnic.
Trei niveluri de stocare a cheii
Primul nivel este un fișier de cheie pe disc. Este portabil prin concepție, și acolo trăiesc majoritatea profilelor OpenVPN.
Al doilea nivel este o cheie pe care sistemul de operare o marchează ca neexportabilă. Windows poate genera o cheie de dispozitiv în magazinul său de certificate și poate refuza exportul obișnuit, ceea ce oprește copierea ocazională. Nu este susținută de hardware, iar cu acces suficient la mașină astfel de chei pot fi recuperate, așa că ridică efortul în loc să construiască un zid.
Al treilea nivel este o cheie generată în interiorul hardware-ului de securitate: un TPM, un card inteligent, un SIM sau un token PIV. Acele module nu au circuitele pentru a exporta cheia pe care au generat-o, iar semnarea are loc în interiorul modulului. Cheia nu devine niciodată un fișier pe care cineva îl poate copia.
| 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 |
Acest tabel este întregul argument în trei rânduri.
Ce poate și ce nu poate face easy-rsa
Emiterea certificatelor pe dispozitiv este simplă. Creează un nume comun distinct pentru fiecare dispozitiv față de aceeași CA, de exemplu ./easyrsa build-client-full laptop-a nopass, și repetă pentru fiecare dispozitiv. Notează care nume comun aparține cărei persoane și mașini.
Revocarea este la fel de directă: ./easyrsa revoke laptop-a, regenerează CRL-ul cu ./easyrsa gen-crl și asigură-te că serverul îl citește într-adevăr prin crl-verify.
Ce nu poate face CA este să verifice unde se află cheia privată după aceea. Dacă generezi cheia pe gazda CA și o copiezi pe dispozitiv, ai creat o a doua copie la emitere. O cheie neexportabilă trebuie generată pe dispozitiv sau importată într-un hardware care nu o va elibera.
Controale care supraviețuiesc unui profil copiat
Presupune că profilul poate fi copiat și proiectează pornind de la asta. Leagă contul de un al doilea factor, astfel încât un certificat singur să nu fie suficient. Dă fiecărui dispozitiv propria politică, astfel încât atingerea unei identități să rămână limitată. Și urmărește același nume comun conectat din două adrese simultan, pentru că așa arată un profil partajat într-un jurnal de conexiuni.
Revocarea rapidă și documentată este controlul care încă funcționează după ce s-a produs o copie. Tot restul este prevenție.
Afirmația pe care serverul se poate baza cu adevărat
Unicitatea vine de la CA. Legarea de dispozitiv vine de la stocarea cheii. Doar hardware-ul care nu își poate exporta cheia transformă un certificat pe dispozitiv într-o afirmație pe care serverul o impune, în loc de o politică pe care toți acceptă să o urmeze.