Dove deve risiedere una chiave privata VPN: file, CNG o TPM?

Due domande stabiliscono dove deve risiedere una chiave privata VPN: se il materiale della chiave può essere copiato fuori dall'host e se un processo può usarla senza nessuno alla tastiera. L'etichetta di marketing di un archivio non risponde a nessuna delle due. Un demone di tunnel che deve tornare su dopo un riavvio richiede uso senza sorveglianza, il che esclude tutto ciò che dipende da un PIN digitato da una persona.

Scegliere tra copiare e usare

Copia e uso falliscono in modi diversi, quindi trattateli come due requisiti anziché uno. Un aggressore che può leggere i byte della chiave porta l'identità su un altro host, e la macchina originale non se ne accorge. Un aggressore che non può leggere i byte ma raggiunge il processo di firma continua ad autenticarsi finché dura quell'accesso.

Una chiave su file è banalmente copiabile, ed è anche per questo la più facile da salvare e ripristinare. Un archivio di chiavi software cambia l'API, non il confine: il provider rifiuta le proprie chiamate di esportazione, ma lo stesso contesto amministrativo che ha installato la chiave di solito ha altre vie verso il materiale. Non esportabile presso un provider software è un'affermazione sulle operazioni supportate, non la prova di un muro hardware. Trattatelo come un dosso contro la copia occasionale, non come protezione da chi ha già la vostra sessione.

Un TPM o una smart card esegue l'operazione di firma dentro l'hardware e restituisce solo il risultato. Questo chiude la via della copia e lascia aperta la via dell'uso a tutto ciò che può chiedere una firma.

Adattare l'archivio al demone del tunnel

Il demone vincola più della politica di sicurezza. WireGuard prende una chiave privata base64 da un file o dall'input di wg set e non ha una via verso un archivio di certificati, quindi una chiave di interfaccia supportata da TPM non è in discussione. OpenVPN compilato contro OpenSSL 3 può caricare una chiave tramite un URI di provider, e strongSwan fornisce un plugin TPM accanto al supporto PKCS#11, ma entrambi dipendono da come è stato compilato il pacchetto.

Un demone che non riesce a raggiungere l'archivio scelto trasforma il confine hardware in decorazione. Qualcuno esporta la chiave una volta, la lascia in un file, e il resto del progetto gira tranquillamente su quella copia.

Il rinnovo è l'altra metà dell'abbinamento, ed è qui che la maggior parte dei progetti crolla. Un archivio che funziona per la prima registrazione ma richiede un login da console per ogni riemissione viene aggirato la prima volta che un certificato scade a un'ora scomoda. Provate il percorso di riemissione mentre la chiave attuale ha ancora mesi davanti.

Inventariare la chiave prima di spostarla

Registrate cos'è la chiave prima di cambiare dove vive, perché una migrazione che perde i subject alternative names rompe il tunnel in un modo che si legge come un guasto di routing. Scaricate il certificato, confermate che la chiave privata è leggibile dove il demone la attende e verificate che la coppia corrisponda davvero.

openssl x509 -in vpn.crt -noout -subject -ext subjectAltName
openssl pkey -in vpn.key -check -noout
openssl x509 -in vpn.crt -noout -pubkey | openssl sha256
openssl pkey -in vpn.key -pubout | openssl sha256

Gli ultimi due digest devono essere identici. Se non lo sono, il demone completa la configurazione e poi fallisce ogni tentativo con un errore di certificato o di firma che non punta neppure vicino alla causa reale. L'equivalente WireGuard è più corto, perché la chiave pubblica deriva direttamente da quella privata: wg pubkey < /etc/wireguard/wg0.key deve stampare la chiave del peer che il vostro server ha già in archivio.

I permessi rientrano nello stesso inventario. stat -c '%a %U:%G' /etc/wireguard/wg0.key dovrebbe restituire 600 root:root, e qualunque cosa leggibile dal gruppo o dal mondo significa che la chiave è già stata disponibile per processi che non avevate mai previsto.

Verificare l'archivio e la via d'uso

La verifica ha tre parti, e la terza è quella che si salta. Confermate che la chiave esiste nell'archivio scelto, confermate che il demone ha caricato quella chiave e non una copia rimasta, poi confermate che parte ancora quando l'artefatto di esportazione non c'è più.

certutil -store -user My
certutil -csp "Microsoft Platform Crypto Provider" -key -user
certutil -verifykeys -user My
ipsec listcerts

Su Windows il primo comando elenca l'archivio personale e stampa il provider di chiavi accanto a ogni voce, ed è lì che compare un certificato che sembra supportato dall'hardware ma risiede nel provider software. Il secondo elenca le chiavi detenute dal provider crittografico della piattaforma, quindi un'identità VPN assente lì mentre il suo certificato è presente significa che la metà privata vive altrove. Su un gateway Linux, ipsec listcerts riporta ciò che strongSwan ha caricato, comprese le chiavi provenienti dal plugin TPM. Confrontate impronte o hash di chiave pubblica con l'inventario invece di fidarvi del numero di voci.

Il test negativo è quello che dimostra il progetto. Spostate la chiave esportata fuori dalla directory di configurazione del demone, riavviate il servizio e leggete nel log quale identità presenta. Un tunnel che sale comunque sta usando l'archivio; un avvio fallito significa che il progetto girava davvero su una copia.

Scrivere rinnovo e rollback

Il rollback differisce nettamente tra le due famiglie, e quella differenza appartiene alla nota di progetto, non a una chiamata di incidente. Una chiave su file può essere salvata cifrata e ripristinata, quindi una migrazione fallita è reversibile. Una chiave non esportabile non può essere salvata affatto, il che rende riemissione e riregistrazione l'unica via di recupero quando il dispositivo muore.

Controllate la scadenza prima che diventi un'interruzione: openssl x509 -in vpn.crt -noout -checkend 2592000 termina con un codice diverso da zero quando il certificato scade entro trenta giorni, quindi entra direttamente in un controllo di monitoraggio. Un'esecuzione settimanale di quella riga intercetta il rinnovo che nessuno aveva pianificato.

La rimozione avviene sul server: eliminate il peer o revocate il numero di serie, poi confermate che il tunnel fallisce, dato che un client con una sessione in cache può nascondere una revoca a metà per un po'. La revoca deve raggiungere anche il percorso CRL o OCSP del concentratore, non solo il database della CA. Un certificato è un documento pubblico, e il profilo RFC 5280 copre come viene validato; nulla di quella validazione protegge una chiave privata copiata prima della rotazione.

Scrivete la decisione in un solo punto: quale archivio custodisce la chiave, quale processo può usarla, chi può riemetterla e qual è il rollback. Quel paragrafo è ciò che chiedono i revisori, ed è ciò che sopravvive a un cambio di personale.