Un certificado por dispositivo non vincula a chave ao dispositivo
Un certificado por dispositivo é unha decisión administrativa, non unha vinculación ao dispositivo. O que decide a vinculación é onde vive a chave privada, desde un ficheiro copiable ata un TPM.
Emites un certificado distinto para cada portátil, así que supoñas que a VPN pode distinguilos. Non pode. Un certificado de cliente demostra que quen se conecta ten a chave privada correspondente, e un perfil copiado tamén a ten.
O certificado por dispositivo segue sendo unha boa idea. Só fai un traballo distinto do que a maioría espera.
Que demostra realmente un certificado de cliente
Durante o protocolo de enlace, o cliente asina coa chave privada que corresponde ao seu certificado, e o servidor verifica esa sinatura contra a CA na que confía. Nada nese intercambio describe a máquina. Calquera dispositivo que teña o certificado e a chave produce unha sinatura idéntica, así que un perfil copiado a un segundo portátil parece exactamente o orixinal. O certificado nomea unha identidade; non nomea hardware.
A unicidade por dispositivo segue valendo a pena, porque fai precisa a revocación. É unha propiedade administrativa, non un candado técnico.
Tres niveis de almacenamento da chave
O primeiro nivel é un ficheiro de chave no disco. É portátil por deseño, e alí viven a maioría dos perfís de OpenVPN.
O segundo nivel é unha chave que o sistema operativo marca como non exportable. Windows pode xerar unha chave de dispositivo no seu almacén de certificados e negar a exportación normal, o que detén a copia ocasional. Non está respaldada por hardware, e con suficiente acceso á máquina esas chaves pódense recuperar, así que eleva o esforzo en lugar de levantar un muro.
O terceiro nivel é unha chave xerada dentro de hardware de seguridade: un TPM, unha tarxeta intelixente, unha SIM ou un token PIV. Eses módulos carecen da circuitería para exportar a chave que xeraron, e a sinatura ocorre dentro do módulo. A chave nunca se converte nun ficheiro que alguén poida 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 |
Ese cadro é todo o argumento en tres filas.
Que pode e que non pode facer easy-rsa
Emitir certificados por dispositivo é sinxelo. Crea un nome común distinto por dispositivo contra a mesma CA, por exemplo ./easyrsa build-client-full laptop-a nopass, e repíteo para cada dispositivo. Anota que nome común pertence a que persoa e máquina.
A revocación é igual de directa: ./easyrsa revoke laptop-a, rexenera a CRL con ./easyrsa gen-crl e asegúrate de que o servidor realmente a le mediante crl-verify.
O que a CA non pode facer é verificar onde vive despois a chave privada. Se xeras a chave no host da CA e a copias ao dispositivo, creaches unha segunda copia no momento da emisión. Unha chave non exportable ten que xerarse no dispositivo, ou importarse a hardware que non a libere.
Controls que sobreviven a un perfil copiado
Supón que o perfil se pode copiar e deseña en consecuencia. Vincula a conta a un segundo factor para que un certificado por si só non abonde. Dá a cada dispositivo a súa propia política para que o alcance dunha identidade siga limitado. E vixía o mesmo nome común conectado desde dúas direccións á vez, que é como se ve un perfil compartido nun rexistro de conexións.
A revocación rápida e documentada é o control que segue funcionando despois de que se producise unha copia. Todo o demais é prevención.
A afirmación coa que o servidor realmente pode contar
A unicidade vén da CA. A vinculación ao dispositivo vén do almacenamento da chave. Só o hardware que non pode exportar a súa chave converte un certificado por dispositivo nunha afirmación que o servidor impón, en lugar dunha política que todos aceptan seguir.