Symmetrisk vs. offentlig-nøkkel-kryptering i VPN: hva hver gjør
En VPN autentiserer parter med offentlige nøkler og krypterer deretter pakker med avledede sesjonsnøkler. Behandle sertifikater og trafikknøkler som forskjellige objekter.
Folk beskriver en VPN som «den som bruker offentlig-nøkkel-kryptering» og ser så for seg at hver pakke låses med serverens sertifikat. Det bildet er galt på en måte som betyr noe når du leser en konfigurasjonsfil eller et pakkeopptak. VPN-ens offentlige nøkkelhalvdel handler om å bevise hvem motparten er og bli enige om hemmelig materiale; den symmetriske halvdelen er det som faktisk beskytter trafikken, pakke for pakke, gjennom hele sesjonens levetid.
De to halvdelene har ulik levetid, ulike feilmoduser og ulike ting som trygt kan publiseres. Når du skiller dem, slutter spørsmål som «er RSA 2048 svakere enn AES-128» å forvirre, fordi de aldri var sammenlignbare.
Tre operasjoner som blandes sammen
Offentlig-nøkkel-kryptografi er en paraply over minst tre ulike operasjoner. En signatur beviser at innehaveren av en privat nøkkel godkjente en bestemt melding. Nøkkelavtale lar to parter utlede en felles hemmelighet fra verdier de utveksler offentlig. Offentlig-nøkkel-kryptering skjuler data under noens offentlige nøkkel slik at bare den private nøkkelen kan åpne dem.
VPN-håndtrykk bruker stort sett de to første. Et sertifikat er ikke en krypteringsnøkkel; det er en signert erklæring som binder et navn til en offentlig nøkkel og lar den andre siden avgjøre om den skal stole på nøkkelen den nettopp fikk. Etableringen av TLS 1.3-nøkler bygger for eksempel på (EC)DHE-nøkkelavtale pluss sertifikatsignaturer, ikke på å kryptere sesjonen med serverens offentlige nøkkel.
Hva håndtrykket faktisk produserer
I et moderne håndtrykk lager hver side et efemert nøkkelpar, utveksler de offentlige halvdelene og beregner en felles hemmelighet som aldri går over ledningen. Den hemmeligheten går deretter gjennom en nøkkelavledningsfunksjon for å lage separate nøkler for hver retning, i tillegg til nonce-verdiene og IV-materialet som postlaget trenger. WireGuard gjør dette med sin Noise-baserte konstruksjon; TLS 1.3 gjør det med HKDF over håndtrykkstranskriptet.
Den langsiktige legitimasjonen — sertifikat og privat nøkkel, eller en statisk WireGuard-nøkkel — autentiserer den utvekslingen. Den signerer eller blandes inn i transkriptet slik at en fremmed ikke kan fullføre håndtrykket i parts sted. Etterpå gjør ikke legitimasjonen arbeid per pakke. Hvis den gjorde det, ville hver pakke kreve en privatnøkkeloperasjon, og en travel tunnel ville være begrenset av den tregeste operasjonen i stakken.
To bivirkninger følger. For det første er sesjonsnøklene ferske hver gang, så en angriper som senere stjeler den langsiktige nøkkelen ikke kan dekryptere tidligere innspilte sesjoner, så lenge avtalen var efemær. For det andre kompromitterer en lekket sesjonsnøkkel én sesjon, ikke identiteten.
Hvorfor store datamengder bruker symmetriske nøkler
Symmetriske chiffer håndterer volum godt: AES-GCM eller ChaCha20-Poly1305 behandler hver pakke med en nøkkel som allerede ligger i minnet, autentiserer hodet og øker en teller. Mottakersiden kontrollerer nonce og autentiseringstaggen og forkaster alt som feiler eller gjentas. Det er billig nok til å kjøre i linjehastighet på vanlig maskinvare, og den samme konstruksjonen gir konfidensialitet og integritet i én gjennomgang.
Konstruksjonen er også stedet der de fleste implementasjonsfeil bor. En gjentatt nonce i GCM bryter konfidensialitet og autentisitet på én gang, så protokollene avleder nøkler per retning og holder en eksplisitt teller eller epoke. Hvis du leser et pakkeopptak og lengden på chifferteksten stemmer med klarteksten pluss en fast overheng, er det det symmetriske laget som arbeider, ikke en offentlig-nøkkel-operasjon per pakke.
Levetid, nøkkelfornying og fremoverrettet hemmelighold
Sesjonsnøkler er ment å utløpe. TLS 1.3 lar en KeyUpdate-melding rulle trafikknøklene; WireGuard fornyer en sesjon etter konfigurert tid eller meldingsantall og holder den gamle kort for pakker underveis. OpenVPN forhandler på nytt om nøklene til datakanalen etter en plan, med reneg-sec som styrer intervallet.
Ingen av disse rotasjonene er det samme som å fornye et sertifikat. Et sertifikat kan være gyldig i ett år mens sesjonsnøklene endres hvert par minutter, og et sertifikat kan byttes ut uten å røre nøklene til tunnelen som kjører. Når du planlegger utløp, spør hvilket objekt du roterer; svaret avgjør om klientene kobler til på nytt eller bare fornyer nøkler.
Les konfigurasjon og diagnostikk uten å blande objekter
I praksis velger du en komplett protokoll og dens støttede primitiver, ikke setter sammen din egen. --tls-crypt-nøkkelen i OpenVPN beskytter kontrollkanalen; datakanalen bruker forhandlede symmetriske chiffer. PrivateKey- og PublicKey-oppføringene i WireGuard er identitetsmateriale, mens transportnøklene avledes internt. Å lese disse feltene som samme type hemmelighet fører til feil som å lime en offentlig nøkkel der en privat skal være.
Hold offentlig materiale atskilt fra privat. Et sertifikat, en offentlig WireGuard-nøkkel og et fingeravtrykk er trygge å dele i en sak. En privat nøkkel, en forhåndsdelt nøkkel og en eksportert sesjonsnøkkel er det ikke. Når du sammenligner styrke, sammenlign innenfor én type: en elliptisk-kurve-identifikator, en RSA-modulusstørrelse og en AES-nøkkelstørrelse måler ulike ting under ulike forutsetninger. TLS 1.3-spesifikasjonen er en nyttig referanse for hvordan de to lagene passer sammen, selv når tunnelen din ikke er TLS.