Hva en forhåndsdelt nøkkel gjør i IPsec, OpenVPN og WireGuard

Ordene forhåndsdelt nøkkel forekommer i dokumentasjonen for IPsec, OpenVPN og WireGuard, men de beskriver tre forskjellige objekter. Den ene er en autentiseringshemmelighet, den andre beskytter en kontrollkanal, og den tredje tilfører materiale til et håndtrykk som allerede har identiteter. Behandler man dem som utskiftbare, får man en forbindelse som feiler i en fase ingen forventet. Les hva feltet gjør i den protokollen før du kopierer en verdi inn i det.

Tre protokoller, tre betydninger

Hver protokoll definerer nøkkelens oppgave i sin egen spesifikasjon, og oppgavene overlapper ikke. En autentiseringshemmelighet beviser at to parter kjenner samme verdi. En nøkkel for kontrollkanalen beskytter forhandlingen som følger. Et tillegg til håndtrykket endrer nøkkelplanen uten å endre hvem partene er.

Ingen av disse rollene autentiserer et menneske, og nettopp den forvekslingen koster mest tid. En forhåndsdelt nøkkel legges på enheter eller gatewayer før utvekslingen, slik at enhver innehaver ser lik ut for den andre siden. Den egenskapen er en fordel for en forbindelse mellom to rutere og en risiko for en fjernaksess-tjeneste med navngitte ansatte. Hold kontoopplysningene og den kryptografiske hemmeligheten i hver sin kolonne i dokumentet som beskriver utrullingen.

IPsec og OpenVPN bruker ordet ulikt

IKEv2 kan autentisere en peer med en forhåndsdelt hemmelighet i stedet for sertifikater, og verdien må stemme i begge ender. Fordi den samme hemmeligheten vanligvis konfigureres for en gruppe parter, kan enhver innehaver utgi seg for de andre, og utvekslingen får ingen fremoverrettet hemmeligholdelse fra identitetsnøkler den aldri hadde.

OpenVPNs tls-auth og tls-crypt knytter en statisk nøkkel til kontrollkanalen og legger til en HMAC-signatur eller krypterer selve forhandlingen. Den nøkkelen er ikke et brukerpassord og erstatter ikke klient sertifikatet. Forskjellen betyr noe ved fornyelse, når et passordbytte lar kontrollkanalens nøkkel være urørt.

WireGuards PSK tilfører, den identifiserer ikke

WireGuard-parter har allerede offentlige og private Curve25519-nøkler, og håndtrykket autentiserer disse identitetene. En valgfri forhåndsdelt nøkkel blandes inn i kjedenøkkelen og bidrar med symmetrisk materiale oppå utvekslingen av offentlige nøkler.

Den gir ingen egen identitet og ingen brukerkonto, så en operatør kan ikke skille to innehavere på deres PSK. Begge ender må bære samme verdi, ellers feiler håndtrykket uten en nyttig feilmelding. Derfor må rotasjon planlegges for begge sider samtidig og ikke som redigering av én fil.

Kontroller distribusjon, rotasjon og fjerning

Distribusjon er det svake punktet i ethvert design som bruker én hemmelighet mange steder. En verdi som limes inn i et chatvindu, lagres i et repository eller gjenbrukes på tvers av miljøer, samler kopier ingen kan ramse opp, og hver kopi utvider stille skadeomfanget.

Base64-tekst er ikke kryptering. En hemmelighet som ligger ved siden av et offentlig sertifikat i samme mappe, er fortsatt en hemmelighet i klartekst.

openssl rand -base64 32
sudo wg show wg0 preshared-keys
sudo grep -R -n 'psk' /etc/ipsec.d/ 2>/dev/null

Roter etter en plan og etter enhver mistenkt eksponering, og oppdater hver tiltenkt part før du tilbakekaller den gamle verdien. Test deretter forbindelsen fra begge ender, fordi en nøkkel som ikke passer feiler ved håndtrykket og ser nøyaktig ut som et brannmurproblem.

Dokumenter hvilken hemmelighet som beskytter hvilken fase, slik at en tilbakestilling av passord aldri forveksles med fornyelse av en kryptografisk nøkkel. Den ene linjen sparer en time hver gang noen reviderer utrullingen.