Var ska en privat VPN-nyckel bo: fil, CNG eller TPM?

Två frågor avgör var en privat VPN-nyckel hör hemma: om nyckelmaterialet kan kopieras från värden, och om en process kan använda den utan någon vid tangentbordet. Ett lagers marknadsföringsetikett svarar inte på någon av dem. En tunneldemon som måste komma tillbaka efter en omstart kräver obemannad användning, vilket utesluter allt som är knutet till en PIN-kod som en människa skriver in.

Välj mellan kopiering och användning

Kopiering och användning misslyckas olika, så behandla dem som två krav i stället för ett. En angripare som kan läsa nyckelbyten bär identiteten till en annan värd, och den ursprungliga maskinen märker inget. En angripare som inte kan läsa byten men kan nå signeringsprocessen autentiserar sig fortfarande så länge den åtkomsten varar.

En filnyckel är trivialt kopierbar, vilket också gör den enklast att säkerhetskopiera och återställa. Ett mjukvarunyckellager ändrar API:t, inte gränsen: leverantören avvisar sina egna exportanrop, men samma administratörskontext som installerade nyckeln har oftast andra vägar till materialet. Icke-exporterbar hos en mjukvaruleverantör är ett påstående om vilka operationer som stöds, inte ett bevis på en hårdvarumur. Behandla det som en fartbula mot slarvig kopiering, inte som skydd mot någon som redan har din session.

En TPM eller ett smartkort utför signeringsoperationen i hårdvara och returnerar bara resultatet. Det stänger kopieringsvägen och lämnar användningsvägen öppen för allt som kan begära en signatur.

Anpassa lagret till tunneldemonen

Demonen begränsar detta mer än säkerhetspolicyn gör. WireGuard tar en base64-kodad privat nyckel från en fil eller från wg set-indata och har ingen väg in i ett certifikatlager, så en TPM-buren gränssnittsnyckel är inte aktuell. OpenVPN byggt mot OpenSSL 3 kan läsa in en nyckel via en leverantörs-URI, och strongSwan levererar en TPM-plugin vid sidan av PKCS#11-stöd, men båda beror på hur ditt paket kompilerades.

En demon som inte kan nå det valda lagret gör hårdvarugränsen till dekoration. Någon exporterar nyckeln en gång, lämnar den i en fil, och resten av designen kör tyst på den kopian.

Förnyelse är den andra halvan av matchningen, och det är där de flesta designer faller isär. Ett lager som fungerar för den första registreringen men kräver en konsolinloggning för varje nyutfärdande kringgås första gången ett certifikat löper ut vid en oläglig timme. Testa nyutfärdandevägen medan den nuvarande nyckeln fortfarande har månader kvar.

Inventera nyckeln innan du flyttar den

Dokumentera vad nyckeln är innan du ändrar var den bor, för en migrering som tappar subject alternative names bryter tunneln på ett sätt som läses som ett routingfel. Dumpa certifikatet, bekräfta att den privata nyckeln är läsbar där demonen förväntar sig den, och kontrollera att paret faktiskt matchar.

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 två sista digestarna måste vara identiska. Är de inte det slutför demonen sin installation och misslyckas sedan vid varje försök med ett certifikat- eller signaturfel som pekar långt från den verkliga orsaken. WireGuard-motsvarigheten är kortare, eftersom den offentliga nyckeln härleds direkt från den privata: wg pubkey < /etc/wireguard/wg0.key måste skriva ut den peer-nyckel som din server redan har sparad.

Behörigheter hör till samma inventering. stat -c '%a %U:%G' /etc/wireguard/wg0.key bör returnera 600 root:root, och allt som är läsbart för grupp eller alla betyder att nyckeln redan har varit tillgänglig för processer du aldrig avsåg.

Kontrollera lagret och användningsvägen

Verifieringen har tre delar, och den tredje hoppas över. Bekräfta att nyckeln finns i lagret du valde, bekräfta att demonen läste in den nyckeln och inte en kvarlämnad kopia, och bekräfta sedan att den fortfarande startar när exportartefakten är borta.

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

På Windows listar det första kommandot det personliga lagret och skriver ut nyckelleverantören bredvid varje post, och där dyker ett certifikat upp som ser hårdvarustött ut men sitter i mjukvaruleverantören. Det andra listar nycklar som plattformskryptoleverantören håller, så en VPN-identitet som saknas där medan certifikatet finns betyder att den privata halvan bor någon annanstans. På en Linux-gateway rapporterar ipsec listcerts vad strongSwan läste in, inklusive nycklar från TPM-pluginen. Jämför fingeravtryck eller publika nyckelhasher med inventeringen i stället för att lita på antalet poster.

Det negativa testet är det som bevisar designen. Flytta den exporterade nyckeln ut ur demonens konfigurationskatalog, starta om tjänsten och läs i loggen vilken identitet den presenterar. En tunnel som ändå kommer upp använder lagret; en misslyckad start betyder att designen verkligen körde på en kopia.

Skriv ned förnyelse och återställning

Återställning skiljer sig kraftigt mellan de två familjerna, och den skillnaden hör i designanteckningen, inte i ett incidentmöte. En filnyckel kan säkerhetskopieras krypterad och återställas, så en misslyckad migrering kan rullas tillbaka. En icke-exporterbar nyckel kan inte säkerhetskopieras alls, vilket gör nyutfärdande och nyregistrering till den enda återställningsvägen när enheten dör.

Kontrollera utgången innan den blir ett avbrott: openssl x509 -in vpn.crt -noout -checkend 2592000 avslutas med en icke-nollkod när certifikatet löper ut inom trettio dagar, så det passar rakt in i en övervakningskontroll. En veckovis körning av den raden fångar den förnyelse som ingen hade planerat.

Borttagning sker på servern: radera peeren eller återkalla serienumret och bekräfta sedan att tunneln misslyckas, eftersom en klient med en cachad session kan dölja en halvfärdig återkallelse ett tag. Återkallelsen måste också nå koncentratorns CRL- eller OCSP-väg, inte bara CA-databasen. Ett certifikat är en offentlig handling, och RFC 5280-profilen täcker hur det valideras; inget av den valideringen skyddar en privat nyckel som kopierades före rotationen.

Skriv beslutet på ett ställe: vilket lager som håller nyckeln, vilken process som får använda den, vem som kan utfärda den igen och vad återställningen är. Det stycket är vad revisorer frågar efter, och det är vad som överlever ett personalbyte.