Um certificado por dispositivo não vincula a chave ao dispositivo
Um certificado por dispositivo é uma escolha administrativa, não uma vinculação ao dispositivo. O que decide a vinculação é onde vive a chave privada, de um arquivo copiável a um TPM.
Você emite um certificado separado para cada portátil, portanto assume que a VPN consegue distingui-los. Não consegue. Um certificado de cliente prova que quem se conecta possui a chave privada correspondente, e um perfil copiado também a possui.
O certificado por dispositivo continua a ser uma boa ideia. Só faz um trabalho diferente do que a maioria espera.
O que um certificado de cliente realmente prova
Durante o handshake, o cliente assina com a chave privada que corresponde ao seu certificado, e o servidor verifica essa assinatura contra a AC em que confia. Nada nessa troca descreve a máquina. Qualquer dispositivo que tenha o certificado e a chave produz uma assinatura idêntica, por isso um perfil copiado para um segundo portátil parece exatamente o original. O certificado nomeia uma identidade; não nomeia hardware.
A unicidade por dispositivo continua a valer a pena, porque torna a revogação precisa. É uma propriedade administrativa, não um cadeado técnico.
Três níveis de armazenamento da chave
O primeiro nível é um arquivo de chave no disco. É portátil por conceção, e é aí que vivem a maioria dos perfis OpenVPN.
O segundo nível é uma chave que o sistema operativo marca como não exportável. O Windows pode gerar uma chave de dispositivo no seu arquivo de certificados e recusar a exportação normal, o que trava a cópia casual. Não é suportada por hardware, e com acesso suficiente à máquina essas chaves podem ser recuperadas, pelo que aumenta o esforço em vez de erguer um muro.
O terceiro nível é uma chave gerada dentro de hardware de segurança: um TPM, um smart card, um SIM ou um token PIV. Esses módulos não têm a circuiteria para exportar a chave que geraram, e a assinatura acontece dentro do módulo. A chave nunca se torna num ficheiro que alguém possa 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 |
Essa tabela é todo o argumento em três linhas.
O que o easy-rsa pode e não pode fazer
Emitir certificados por dispositivo é simples. Crie um nome comum distinto por dispositivo contra a mesma AC, por exemplo ./easyrsa build-client-full laptop-a nopass, e repita para cada dispositivo. Registe qual o nome comum que pertence a que pessoa e máquina.
A revogação é igualmente direta: ./easyrsa revoke laptop-a, regenere a CRL com ./easyrsa gen-crl, e garanta que o servidor a lê realmente através de crl-verify.
O que a AC não pode fazer é verificar onde a chave privada vive depois. Se gerar a chave no anfitrião da AC e a copiar para o dispositivo, criou uma segunda cópia na emissão. Uma chave não exportável tem de ser gerada no dispositivo, ou importada para hardware que não a liberte.
Controlos que sobrevivem a um perfil copiado
Assuma que o perfil pode ser copiado e conceba em conformidade. Vincule a conta a um segundo fator para que um certificado sozinho não baste. Dê a cada dispositivo a sua própria política para que o alcance de uma identidade fique limitado. E vigie o mesmo nome comum ligado a partir de dois endereços ao mesmo tempo, porque é assim que um perfil partilhado se parece num registo de ligações.
A revogação rápida e documentada é o controlo que ainda funciona depois de uma cópia ter acontecido. Todo o resto é prevenção.
A afirmação com que o servidor pode realmente contar
A unicidade vem da AC. A vinculação ao dispositivo vem do armazenamento da chave. Só o hardware que não consegue exportar a sua chave transforma um certificado por dispositivo numa afirmação que o servidor impõe, em vez de uma política que todos aceitam seguir.