Hva en passfrase på en privat VPN-nøkkel faktisk beskytter

Ledeteksten som vises når en VPN-klient starter, er lett å lese feil. Det er ikke VPN-kontoens passord, det er ikke passordet for tunnelen, og å skrive det inn beviser ikke at tilkoblingen er sikker. Den låser opp én lagret representasjon av en privatnøkkel slik at klienten kan lese nøkkelmaterialet og bruke det til autentisering. Alt som skjer etterpå, er et annet spørsmål.

I praksis går svaret galt i kantene: folk antar at passfrasen beskytter den kjørende tunnelen, eller at endring av den tilbakekaller en kopi av nøkkelen som allerede er lekket. Begge antakelsene svikter, og begge svikter på måter som etterlater en legitimasjon eksponert mens operatøren tror den er håndtert.

Én dialog, flere forskjellige hemmeligheter

En passfrase for en privatnøkkel dekrypterer en fil. Et kontopassord autentiserer deg mot en tjeneste. Et PKCS#12-importpassord dekrypterer en pakke som inneholder en nøkkel og sertifikatet dens, og det er kanskje ikke samme streng som nøkkelens egen passfrase. Disse ledetekstene kan se nesten identiske ut, og å gjette hvilken hemmelighet som hører hvor er hvordan nøkler ender opp med å bli limt inn i feil felt.

Tunnelens egen kryptering er en fjerde ting. Datakanalen bruker sesjonsnøkler som forhandles under håndtrykket; privatnøkkelens passfrase spiller ingen rolle for å beskytte enkeltpakker. Hvis noen kan lese nøkkelfilen, kan de prøve å gjette passfrasen offline, men hvis de kan lese pakker, er passfrasen irrelevant.

Hva krypteringen på disken dekker

En kryptert PEM-nøkkel kommer i to former, og headeren forteller deg hvilken du har. Den moderne PKCS#8-formen begynner med -----BEGIN ENCRYPTED PRIVATE KEY-----; den eldre PEM-formen, fortsatt vanlig i eldre OpenVPN-oppsett, begynner med -----BEGIN RSA PRIVATE KEY----- og bærer Proc-Type: 4,ENCRYPTED og en DEK-Info-linje rett under. Filen holder den private nøkkelen kryptert under en nøkkel som er utledet fra passfrasen din, vanligvis via en passordbasert KDF med et angitt antall iterasjoner eller arbeidsfaktor. OpenSSL pkey-dokumentasjonen dekker formatene og passfrasevalgene som gjelder når du leser en.

To konsekvenser følger. En svak passfrase kan angripes offline med den hastigheten KDF-en tillater, så filrettigheter og tilgang til sikkerhetskopier er fortsatt viktige selv når filen er kryptert. Og en angriper som bare får filen uten passfrasen, må gjette; den som får både filen og passfrasen, har nøkkelen, akkurat som om den aldri hadde vært kryptert.

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

head -3 viser headeren og, på en eldre fil, linjene Proc-Type og DEK-Info som beviser kryptering; én linje alene er ikke bevis i noen retning. Linjen pkey spør etter passfrasen og skriver bare ut den offentlige halvdelen, noe som beviser at filen og passfrasen fungerer uten å avsløre den private nøkkelen. Ikke bruk -text til den kontrollen: den skriver ut de private komponentene, privateExponent, prime1, prime2 og resten, og den utskriften må aldri limes inn noe sted, verken i en sak, en chat eller en logg. PKCS#12-kommandoen forteller deg også om pakken har et separat MAC- eller krypteringspassord, noe det er greit å vite før du gir den til en kollega.

Hva den slutter å beskytte når nøkkelen er lastet

Opplåsing er en enveishedelse for den prosessen. Klienten ber KDF-en om nøkkelen, dekrypterer filen og beholder den private nøkkelen i minnet så lenge den trenger den. Fra det øyeblikket beskytter passfrasen ingenting ved den kjørende sesjonen: ikke prosessminnet, ikke en kjernedump, ikke en feilsøkingssesjon knyttet til klienten, og ikke en sikkerhetskopi av maskinen tatt mens nøkkelen var i bruk.

Dette er samme grense som en SSH-nøkkel med passfrase, eller et opplåst hvelv i en passordbehandler. Det øker kostnaden ved å stjele filen i ro og gjør ingenting mot skadelig programvare som kjører som brukeren din, en autorisert applikasjon som ber klienten signere, eller en administrator som kan lese minne. Behandle det som ett lag, ikke som kontrollen som gjør en nøkkel trygg å la ligge.

Hvorfor ledeteksten fortsetter å komme tilbake

En klient som spør igjen ved hver gjenoppkobling er ikke nødvendigvis ødelagt. Noen klienter bufrer passfrasen for sesjonen, noen lagrer den i OS-nøkkelringen, og noen kan pekes på en hjelper som leverer den, så hvilken oppførsel du får, avhenger av klienten og konfigurasjonen, ikke av nøkkelfilen.

Hvis den gjentatte ledeteksten er den egentlige klagen, undersøk klientens bufrings- og autentiseringsalternativer før du fjerner krypteringen fra nøkkelen. Å fjerne passfrasen gjør en beskyttet fil om til en klartekstnøkkel, og gjenoppkoblingen blir stille på bekostning av den eneste ro-kontrollen du hadde. Et bedre svar er vanligvis et støttet legitimasjonslager med de samme filrettighetene du uansett ville brukt.

Tap og eksponering er ikke samme reparasjon

En tapt passfrase kan ikke gjenopprettes fra sertifikatet. Sertifikatet er offentlig materiale som binder et navn til en nøkkel; det inneholder ingen vei tilbake til den private nøkkelen og ingen antydning om passfrasen. De praktiske alternativene er en autorisert sikkerhetskopi av nøkkelen, eller en ny identitet utstedt gjennom operatørens normale prosess. Alle som tilbyr å 'gjenopprette' passfrasen, tilbyr å gjette den.

Eksponering krever et annet svar. Å kryptere den samme nøkkelen på nytt med en ny passfrase lar nøkkelmaterialet være uendret, så en kopi som allerede er låst opp et annet sted, fungerer fortsatt. Reparasjonen er å tilbakekalle eller erstatte legitimasjonen: utsted en ny nøkkel og et nytt sertifikat, distribuer dem, og pensioner den gamle hos motparten. Inntil det skjer, er endring av filpassordet husarbeid, ikke inndemming. Hold den gamle filen ute av sikkerhetskopier bare etter at den nye identiteten er bekreftet å fungere, og noter hvilket serienummer eller fingeravtrykk som erstattet den.