Un certificat per dispositiu no fa que la clau estigui lligada al dispositiu
Un certificat per dispositiu és una decisió d’administració, no una vinculació al dispositiu. El que decideix la vinculació és on viu la clau privada, des d’un fitxer copiable fins a un TPM.
Emeteu un certificat separat per a cada portàtil, així que suposeu que la VPN els pot distingir. No pot. Un certificat de client demostra que qui es connecta té la clau privada corresponent, i un perfil copiat també la té.
El certificat per dispositiu continua sent una bona idea. Només fa una feina diferent de la que la majoria de la gent espera.
Què demostra realment un certificat de client
Durant l’intercanvi de claus, el client signa amb la clau privada que correspon al seu certificat, i el servidor verifica aquesta signatura contra l’AC en què confia. Res d’aquest intercanvi no descriu la màquina. Qualsevol dispositiu que tingui el certificat i la clau produeix una signatura idèntica, així que un perfil copiat a un segon portàtil sembla exactament l’original. El certificat anomena una identitat; no anomena maquinari.
La unicitat per dispositiu encara val la pena, perquè fa precisa la revocació. És una propietat administrativa, no un pany tècnic.
Tres nivells d’emmagatzematge de la clau
El primer nivell és un fitxer de clau al disc. És portàtil per disseny, i és on viuen la majoria de perfils d’OpenVPN.
El segon nivell és una clau que el sistema operatiu marca com a no exportable. Windows pot generar una clau de dispositiu al seu magatzem de certificats i negar-ne l’exportació ordinària, cosa que atura la còpia ocasional. No té suport de maquinari, i amb prou accés a la màquina aquestes claus es poden recuperar, així que augmenta l’esforç en lloc d’aixecar un mur.
El tercer nivell és una clau generada dins de maquinari de seguretat: un TPM, una targeta intel·ligent, una SIM o un testimoni PIV. Aquests mòduls no tenen els circuits per exportar la clau que han generat, i la signatura passa dins del mòdul. La clau mai no es converteix en un fitxer que ningú pugui copiar.
| 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 |
Aquesta taula és tot l’argument en tres files.
Què pot i què no pot fer easy-rsa
Emetre certificats per dispositiu és senzill. Creeu un nom comú diferent per a cada dispositiu contra la mateixa AC, per exemple ./easyrsa build-client-full laptop-a nopass, i repetiu-ho per a cada dispositiu. Anoteu quin nom comú pertany a quina persona i màquina.
La revocació és igual de directa: ./easyrsa revoke laptop-a, regenereu la CRL amb ./easyrsa gen-crl i assegureu-vos que el servidor realment la llegeix mitjançant crl-verify.
El que l’AC no pot fer és verificar on viu la clau privada després. Si genereu la clau a l’amfitrió de l’AC i la copieu al dispositiu, heu creat una segona còpia en el moment de l’emissió. Una clau no exportable s’ha de generar al dispositiu, o importar-se a maquinari que no la deixarà anar.
Controls que sobreviuen a un perfil copiat
Suposeu que el perfil es pot copiar i dissenyeu tenint-ho en compte. Lligueu el compte a un segon factor perquè un certificat sol no basti. Doneu a cada dispositiu la seva pròpia política perquè l’abast d’una identitat quedi limitat. I vigileu el mateix nom comú connectat des de dues adreces alhora, que és com es veu un perfil compartit en un registre de connexions.
La revocació ràpida i documentada és el control que encara funciona després que s’hagi fet una còpia. Tota la resta és prevenció.
L’afirmació amb què el servidor realment pot comptar
La unicitat ve de l’AC. La vinculació al dispositiu ve de l’emmagatzematge de la clau. Només el maquinari que no pot exportar la seva clau converteix un certificat per dispositiu en una afirmació que el servidor imposa, en lloc d’una política que tothom accepta seguir.