Hvad en adgangsfrase på en VPN-privatnøgle egentlig beskytter

Prompten, der vises, når en VPN-klient starter, er let at læse forkert. Det er ikke VPN-kontoens adgangskode, det er ikke adgangskoden til tunnelen, og ved at indtaste den beviser du ikke, at forbindelsen er sikker. Den låser én lagret repræsentation af en privatnøgle op, så klienten kan læse nøglematerialet og bruge det til at autentificere. Alt, hvad der sker bagefter, er et andet spørgsmål.

I praksis går svaret galt i kanterne: folk antager, at adgangsfrasen beskytter den kørende tunnel, eller at ændring af den tilbagekalder en kopi af nøglen, der allerede er lækket. Begge antagelser fejler, og begge fejler på måder, der efterlader en legitimationsoplysning blotlagt, mens operatøren tror, at den er håndteret.

Én dialog, flere forskellige hemmeligheder

En adgangsfrase til en privatnøgle dekrypterer en fil. En kontoadgangskode autentificerer dig over for en tjeneste. En PKCS#12-importadgangskode dekrypterer en pakke, der indeholder en nøgle og dens certifikat, og den er måske ikke den samme streng som nøglens egen adgangsfrase. Disse prompts kan se næsten identiske ud, og at gætte, hvilken hemmelighed der hører hvor, er hvordan nøgler ender med at blive indsat i det forkerte felt.

Tunnelens egen kryptering er en fjerde ting. Datakanalen bruger sessionsnøgler, der forhandles under håndtrykket; privatnøglens adgangsfrase spiller ingen rolle for beskyttelsen af de enkelte pakker. Hvis nogen kan læse nøglefilen, kan de forsøge at gætte adgangsfrasen offline, men hvis de kan læse pakker, er adgangsfrasen irrelevant.

Hvad krypteringen på disken dækker

En krypteret PEM-nøgle findes i to former, og headeren fortæller dig, hvilken du har. Den moderne PKCS#8-form begynder med -----BEGIN ENCRYPTED PRIVATE KEY-----; den ældre PEM-form, stadig almindelig i ældre OpenVPN-opsætninger, begynder med -----BEGIN RSA PRIVATE KEY----- og bærer Proc-Type: 4,ENCRYPTED og en DEK-Info-linje lige under. Filen indeholder den private nøgle krypteret under en nøgle, der er afledt af din adgangsfrase, typisk via en adgangskodebaseret KDF med et angivet antal iterationer eller arbejdsfaktor. OpenSSL pkey-dokumentationen dækker formaterne og de adgangsfraseindstillinger, der gælder, når man læser en.

Der følger to konsekvenser. En svag adgangsfrase kan angribes offline med den hastighed, KDF'en tillader, så filrettigheder og adgang til backups er stadig vigtige, selv når filen er krypteret. Og en angriber, der kun får filen uden adgangsfrasen, må gætte; en, der får både filen og adgangsfrasen, har nøglen, præcis som hvis den aldrig havde været krypteret.

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 ældre fil, linjerne Proc-Type og DEK-Info, der beviser kryptering; en enkelt linje er ikke bevis i nogen retning. Linjen pkey spørger efter adgangsfrasen og udskriver kun den offentlige halvdel, hvilket beviser, at filen og adgangsfrasen virker uden at afsløre den private nøgle. Brug ikke -text til den kontrol: den udskriver de private komponenter, privateExponent, prime1, prime2 og resten, og det output må aldrig indsættes nogen steder, hverken i en ticket, en chat eller en log. PKCS#12-kommandoen fortæller også, om pakken har en separat MAC- eller krypteringsadgangskode, hvilket er værd at vide, før du giver den til en kollega.

Hvad den holder op med at beskytte, når nøglen er indlæst

Oplåsning er en envejshændelse for den proces. Klienten beder KDF'en om nøglen, dekrypterer filen og beholder den private nøgle i hukommelsen, så længe den har brug for den. Fra det øjeblik beskytter adgangsfrasen intet ved den kørende session: ikke proceshukommelsen, ikke en kernedump, ikke en fejlfindingssession knyttet til klienten og ikke en backup af maskinen taget, mens nøglen var i brug.

Det er den samme grænse som en SSH-nøgle med adgangsfrase eller en åbnet vault i en adgangskodeadministrator. Det hæver prisen for at stjæle filen i hvile og gør intet mod malware, der kører som din bruger, en autoriseret applikation, der beder klienten om at signere, eller en administrator, der kan læse hukommelse. Behandl det som et lag, ikke som den kontrol, der gør en nøgle sikker at lade ligge fremme.

Hvorfor prompten bliver ved med at komme tilbage

En klient, der spørger igen ved hver genopkobling, er ikke nødvendigvis i stykker. Nogle klienter cacher adgangsfrasen til sessionen, nogle gemmer den i OS-nøglering, og nogle kan peges på en hjælper, der leverer den, så hvilken adfærd du får, afhænger af klienten og dens konfiguration, ikke af nøglefilen.

Hvis den gentagne prompt er den egentlige klage, skal du undersøge klientens caching- og autentificeringsindstillinger, før du fjerner krypteringen fra nøglen. At fjerne adgangsfrasen gør en beskyttet fil til en klartekstnøgle, og genopkoblingen bliver stille på bekostning af den eneste hvilekontrol, du havde. Et bedre svar er normalt et understøttet legitimationslager med de samme filrettigheder, du ville bruge alligevel.

Tab og eksponering er ikke den samme reparation

En mistet adgangsfrase kan ikke gendannes fra certifikatet. Certifikatet er offentligt materiale, der binder et navn til en nøgle; det indeholder ingen vej tilbage til den private nøgle og intet vink om adgangsfrasen. De praktiske muligheder er en autoriseret backup af nøglen eller en ny identitet udstedt gennem operatørens normale proces. Enhver, der tilbyder at 'gendanne' adgangsfrasen, tilbyder at gætte den.

Eksponering kræver et andet svar. Genkryptering af den samme nøgle med en ny adgangsfrase efterlader nøglematerialet uændret, så en kopi, der allerede er låst op et andet sted, virker stadig. Reparationen er at tilbagekalde eller erstatte legitimationsoplysningen: udsted en ny nøgle og et nyt certifikat, distribuer det, og pensioner den gamle hos modparten. Indtil det sker, er ændring af filadgangskoden husarbejde, ikke inddæmning. Hold den gamle fil ude af backups, først når den nye identitet er bekræftet at virke, og noter hvilket serienummer eller fingeraftryk, der erstattede den.