Vad en lösenfras på en privat VPN-nyckel faktiskt skyddar

Prompten som visas när en VPN-klient startar är lätt att läsa fel. Det är inte VPN-kontots lösenord, det är inte lösenordet för tunneln, och att ange det bevisar inte att anslutningen är säker. Den låser upp en lagrad representation av en privat nyckel så att klienten kan läsa nyckelmaterialet och använda det för autentisering. Allt som händer efteråt är en annan fråga.

I praktiken går svaret fel i kanterna: folk antar att lösenfrasen skyddar den körande tunneln, eller att ändring av den återkallar en kopia av nyckeln som redan läckt. Båda antagandena fallerar, och båda fallerar på sätt som lämnar en autentiseringsuppgift exponerad medan operatören tror att den är hanterad.

En dialog, flera olika hemligheter

En lösenfras för en privat nyckel dekrypterar en fil. Ett kontolösenord autentiserar dig mot en tjänst. Ett PKCS#12-importlösenord dekrypterar ett paket som innehåller en nyckel och dess certifikat, och det är kanske inte samma sträng som nyckelns egen lösenfras. Dessa prompter kan se nästan identiska ut, och att gissa vilken hemlighet som hör var är hur nycklar hamnar inklistrade i fel fält.

Tunnelns egen kryptering är en fjärde sak. Datakanalen använder sessionsnycklar som förhandlas under handskakningen; den privata nyckelns lösenfras spelar ingen roll för att skydda enskilda paket. Om någon kan läsa nyckelfilen kan de försöka gissa lösenfrasen offline, men om de kan läsa paket är lösenfrasen irrelevant.

Vad krypteringen på disken täcker

En krypterad PEM-nyckel finns i två former, och rubriken talar om vilken du har. Den moderna PKCS#8-formen börjar med -----BEGIN ENCRYPTED PRIVATE KEY-----; den äldre PEM-formen, fortfarande vanlig i äldre OpenVPN-inställningar, börjar med -----BEGIN RSA PRIVATE KEY----- och bär Proc-Type: 4,ENCRYPTED och en DEK-Info-rad direkt under. Filen håller den privata nyckeln krypterad under en nyckel som härleds från din lösenfras, vanligtvis via en lösenordsbaserad KDF med ett angivet antal iterationer eller arbetsfaktor. OpenSSL pkey-dokumentationen täcker formaten och de lösenfrasalternativ som gäller vid läsning.

Två konsekvenser följer. En svag lösenfras kan attackeras offline i den takt KDF:en tillåter, så filbehörigheter och åtkomst till säkerhetskopior är fortfarande viktiga även när filen är krypterad. Och en angripare som bara får filen utan lösenfrasen måste gissa; den som får både filen och lösenfrasen har nyckeln, precis som om den aldrig hade varit krypterad.

head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout

head -3 visar rubriken och, på en äldre fil, raderna Proc-Type och DEK-Info som bevisar kryptering; en enda rad är inte bevis i någon riktning. Raden pkey frågar efter lösenfrasen och skriver bara ut den offentliga halvan, vilket bevisar att filen och lösenfrasen fungerar utan att avslöja den privata nyckeln. Använd inte -text för den kontrollen: den skriver ut de privata komponenterna, privateExponent, prime1, prime2 och resten, och den utskriften får aldrig klistras in någonstans, varken i ett ärende, en chatt eller en logg. PKCS#12-kommandot berättar också om paketet har ett separat MAC- eller krypteringslösenord, vilket är bra att veta innan du ger det till en kollega.

Vad den slutar skydda när nyckeln har laddats

Upplåsning är en enkelriktad händelse för den processen. Klienten begär nyckeln från KDF:en, dekrypterar filen och behåller den privata nyckeln i minnet så länge den behövs. Från det ögonblicket skyddar lösenfrasen ingenting i den körande sessionen: inte processminnet, inte en kärndump, inte en felsökningssession kopplad till klienten och inte en säkerhetskopia av maskinen som tagits medan nyckeln användes.

Detta är samma gräns som en SSH-nyckel med lösenfras, eller ett upplåst valv i en lösenordshanterare. Det höjer kostnaden för att stjäla filen i vila och gör ingenting mot skadlig programvara som körs som din användare, en auktoriserad applikation som ber klienten signera, eller en administratör som kan läsa minne. Behandla det som ett lager, inte som kontrollen som gör en nyckel säker att lämna framme.

Varför prompten fortsätter att komma tillbaka

En klient som frågar igen vid varje återanslutning är inte nödvändigtvis trasig. Vissa klienter cachar lösenfrasen för sessionen, andra lagrar den i operativsystemets nyckelring, och andra kan pekas mot en hjälpare som levererar den, så vilket beteende du får beror på klienten och dess konfiguration, inte på nyckelfilen.

Om den upprepade prompten är det egentliga klagomålet, granska klientens cachelagrings- och autentiseringsalternativ innan du tar bort krypteringen från nyckeln. Att ta bort lösenfrasen gör en skyddad fil till en klartextnyckel, och återanslutningen blir tyst på bekostnad av den enda vilo-kontroll du hade. Ett bättre svar är vanligtvis ett stödt autentiseringslager med samma filbehörigheter som du ändå skulle använda.

Förlust och exponering är inte samma reparation

En förlorad lösenfras kan inte återställas från certifikatet. Certifikatet är offentligt material som binder ett namn till en nyckel; det innehåller ingen väg tillbaka till den privata nyckeln och ingen ledtråd om lösenfrasen. De praktiska alternativen är en auktoriserad säkerhetskopia av nyckeln, eller en ny identitet som utfärdas genom operatörens normala process. Den som erbjuder sig att 'återställa' lösenfrasen erbjuder sig att gissa den.

Exponering kräver ett annat svar. Att kryptera samma nyckel igen med en ny lösenfras lämnar nyckelmaterialet oförändrat, så en kopia som redan låsts upp någon annanstans fungerar fortfarande. Reparationen är att återkalla eller ersätta autentiseringsuppgiften: utfärda en ny nyckel och ett nytt certifikat, distribuera dem och pensionera den gamla hos motparten. Tills det sker är byte av filens lösenord hushållsarbete, inte inneslutning. Håll den gamla filen utanför säkerhetskopior först efter att den nya identiteten bekräftats fungera, och notera vilket serienummer eller fingeravtryck som ersatte den.