Hvor skal en privat VPN-nøkkel bo: fil, CNG eller TPM?

To spørsmål avgjør hvor en privat VPN-nøkkel hører hjemme: om nøkkelmaterialet kan kopieres fra verten, og om en prosess kan bruke den uten noen ved tastaturet. En lagers markedsføringsetikett svarer ikke på noen av dem. En tunneldaemon som må komme tilbake etter en omstart trenger ubemannet bruk, noe som utelukker alt som er knyttet til en PIN-kode som et menneske taster inn.

Velg mellom kopiering og bruk

Kopiering og bruk feiler ulikt, så behandle dem som to krav i stedet for ett. En angriper som kan lese nøkkelbyttene, bærer identiteten til en annen vert, og den opprinnelige maskinen merker ingenting. En angriper som ikke kan lese byttene, men kan nå signeringsprosessen, autentiserer seg fortsatt så lenge den tilgangen varer.

En filnøkkel er trivielt kopierbar, noe som også gjør den enklest å sikkerhetskopiere og gjenopprette. Et programvarenøkkellager endrer API-et, ikke grensen: leverandøren avviser sine egne eksportkall, men den samme administratørkonteksten som installerte nøkkelen har vanligvis andre veier til materialet. Ikke-eksporterbar hos en programvareleverandør er en uttalelse om støttede operasjoner, ikke bevis på en maskinvarmur. Behandle det som en fartsdump mot tilfeldig kopiering, ikke som beskyttelse mot noen som allerede har økten din.

En TPM eller et smartkort utfører signeringsoperasjonen i maskinvare og returnerer bare resultatet. Det lukker kopieringsveien og lar bruksveien stå åpen for alt som kan be om en signatur.

Tilpass lageret til tunneldaemonen

Daemonen begrenser dette mer enn sikkerhetspolicyen gjør. WireGuard tar en base64-privat nøkkel fra en fil eller fra wg set-inndata og har ingen vei inn i et sertifikatlager, så en TPM-båret grensesnittnøkkel er ikke aktuelt. OpenVPN bygget mot OpenSSL 3 kan laste en nøkkel via en leverandør-URI, og strongSwan leverer en TPM-plugin ved siden av PKCS#11-støtte, men begge avhenger av hvordan pakken din ble kompilert.

En daemon som ikke kan nå det valgte lageret, gjør maskinvargrensen til dekorasjon. Noen eksporterer nøkkelen én gang, lar den ligge i en fil, og resten av designet kjører stille på den kopien.

Fornyelse er den andre halvdelen av matchingen, og det er her de fleste design faller fra hverandre. Et lager som fungerer for den første registreringen, men krever en konsollinnlogging for hver nyutstedelse, blir omgått første gang et sertifikat utløper på et ubeleilig tidspunkt. Test nyutstedelsesveien mens den nåværende nøkkelen fortsatt har måneder igjen.

Inventer nøkkelen før du flytter den

Registrer hva nøkkelen er før du endrer hvor den bor, for en migrering som mister subject alternative names, bryter tunnelen på en måte som leses som en rutingfeil. Dump sertifikatet, bekreft at den private nøkkelen er lesbar der daemonen forventer den, og kontroller at paret faktisk passer sammen.

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

De to siste digestene må være identiske. Er de ikke det, fullfører daemonen oppsettet og feiler deretter ved hvert forsøk med en sertifikat- eller signaturfeil som peker langt fra den egentlige årsaken. WireGuard-ekvivalenten er kortere, fordi den offentlige nøkkelen utledes direkte fra den private: wg pubkey < /etc/wireguard/wg0.key må skrive ut peer-nøkkelen serveren din allerede har lagret.

Rettigheter hører i samme inventar. stat -c '%a %U:%G' /etc/wireguard/wg0.key bør returnere 600 root:root, og alt som er lesbart for gruppe eller verden, betyr at nøkkelen allerede har vært tilgjengelig for prosesser du aldri mente.

Kontroller lageret og bruksveien

Verifiseringen har tre deler, og den tredje hoppes over. Bekreft at nøkkelen finnes i lageret du valgte, bekreft at daemonen lastet den nøkkelen og ikke en gjenglemt kopi, og bekreft deretter at den fortsatt starter når eksportartefakten er borte.

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

På Windows viser den første kommandoen det personlige lageret og skriver ut nøkkelleverandøren ved hver oppføring, og der dukker et sertifikat opp som ser maskinvarestøttet ut, men sitter i programvareleverandøren. Den andre viser nøkler som plattformkryptoleverandøren holder, så en VPN-identitet som mangler der mens sertifikatet er til stede, betyr at den private halvdelen bor et annet sted. På en Linux-gateway rapporterer ipsec listcerts hva strongSwan lastet, inkludert nøkler fra TPM-pluginen. Sammenlign fingeravtrykk eller offentlige nøkkelhash med inventaret i stedet for å stole på antallet oppføringer.

Den negative testen er den som beviser designet. Flytt den eksporterte nøkkelen ut av daemonens konfigurasjonskatalog, start tjenesten på nytt, og les loggen for identiteten den presenterer. En tunnel som fortsatt kommer opp, bruker lageret; en mislykket start betyr at designet virkelig kjørte på en kopi.

Skriv ned fornyelse og tilbakerulling

Tilbakerulling skiller seg skarpt mellom de to familiene, og den forskjellen hører i designnotatet, ikke i en hendelsessamtale. En filnøkkel kan sikkerhetskopieres kryptert og gjenopprettes, så en mislykket migrering kan rulles tilbake. En ikke-eksporterbar nøkkel kan ikke sikkerhetskopieres i det hele tatt, noe som gjør nyutstedelse og nyregistrering til den eneste gjenopprettingsveien når enheten dør.

Kontroller utløpet før det blir en driftsforstyrrelse: openssl x509 -in vpn.crt -noout -checkend 2592000 avsluttes med en ikke-null-kode når sertifikatet utløper innen tretti dager, så det passer rett inn i en overvåkingssjekk. En ukentlig kjøring av den linjen fanger fornyelsen ingen hadde planlagt.

Fjerning skjer på serveren: slett peeren eller tilbakekall serienummeret, og bekreft deretter at tunnelen feiler, siden en klient med en bufret økt kan skjule en halvferdig tilbakekalling en stund. Tilbakekallingen må også nå konsentratorens CRL- eller OCSP-vei, ikke bare CA-databasen. Et sertifikat er et offentlig dokument, og RFC 5280-profilen dekker hvordan det valideres; ingenting av den valideringen beskytter en privat nøkkel som ble kopiert før rotasjonen.

Skriv beslutningen på ett sted: hvilket lager som holder nøkkelen, hvilken prosess som får bruke den, hvem som kan utstede den på nytt, og hva tilbakerullingen er. Det avsnittet er det revisorer spør om, og det er det som overlever et personalbytte.