Hvad en forud delt nøgle gør i IPsec, OpenVPN og WireGuard

Ordene forud delt nøgle optræder i dokumentationen for IPsec, OpenVPN og WireGuard, men de beskriver tre forskellige objekter. Den ene er en godkendelseshemmelighed, den anden beskytter en kontrolkanal, og den tredje tilføjer materiale til et håndtryk, der allerede har identiteter. Behandler man dem som udskiftelige, får man en forbindelse, der fejler i en fase, som ingen forventede. Læs, hvad feltet gør i den protokol, før du kopierer en værdi ind i det.

Tre protokoller, tre betydninger

Hver protokol definerer nøglens opgave i sin egen specifikation, og opgaverne overlapper ikke. En godkendelseshemmelighed beviser, at to parter kender den samme værdi. En nøgle til kontrolkanalen beskytter den efterfølgende forhandling. Et tillæg til håndtrykket ændrer nøgleplanen uden at ændre, hvem parterne er.

Ingen af disse roller godkender et menneske, og netop den forveksling koster mest tid. En forud delt nøgle lægges på enheder eller gateways før udvekslingen, så enhver indehaver ser ens ud for den anden side. Den egenskab er en fordel for en forbindelse mellem to routere og en risiko for en fjernadgangstjeneste med navngivne medarbejdere. Hold kontolegitimationen og den kryptografiske hemmelighed i hver sin kolonne i det dokument, der beskriver udrulningen.

IPsec og OpenVPN bruger ordet forskelligt

IKEv2 kan godkende en peer med en forud delt hemmelighed i stedet for certifikater, og værdien skal stemme i begge ender. Fordi den samme hemmelighed normalt konfigureres for en gruppe parter, kan enhver indehaver udgive sig for de andre, og udvekslingen får ingen fremadrettet hemmeligholdelse fra identitetsnøgler, den aldrig havde.

OpenVPNs tls-auth og tls-crypt knytter en statisk nøgle til kontrolkanalen og tilføjer en HMAC-signatur eller krypterer selve forhandlingen. Den nøgle er ikke en brugeradgangskode og erstatter ikke klientcertifikatet. Forskellen betyder noget ved fornyelse, hvor en adgangskodeændring lader kontrolkanalens nøgle urørt.

WireGuards PSK tilføjer, den identificerer ikke

WireGuard-parter har allerede offentlige og private Curve25519-nøgler, og håndtrykket godkender disse identiteter. En valgfri forud delt nøgle blandes ind i kædenøglen og bidrager med symmetrisk materiale oven på udvekslingen af offentlige nøgler.

Den giver ingen egen identitet og ingen brugerkonto, så en operatør kan ikke skelne to indehavere på deres PSK. Begge ender skal bære den samme værdi, ellers fejler håndtrykket uden en hjælpsom fejlmeddelelse. Derfor skal rotation planlægges for begge sider på én gang og ikke som en redigering af en enkelt fil.

Kontrollér distribution, rotation og fjernelse

Distribution er det svage punkt i ethvert design, der bruger én hemmelighed mange steder. En værdi, der indsættes i et chatvindue, gemmes i et repository eller genbruges på tværs af miljøer, samler kopier, som ingen kan opregne, og hver kopi udvider stille skadesradiusen.

Base64-tekst er ikke kryptering. En hemmelighed, der ligger ved siden af et offentligt certifikat i samme mappe, er stadig en hemmelighed i klartekst.

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

Rotér efter en plan og efter enhver mistænkt eksponering, og opdater hver tilsigtet part, før du tilbagekalder den gamle værdi. Test derefter forbindelsen fra begge ender, fordi en nøgle, der ikke passer, fejler ved håndtrykket og ser præcis ud som et firewallproblem.

Dokumentér, hvilken hemmelighed der beskytter hvilken fase, så en nulstilling af adgangskode aldrig forveksles med fornyelse af en kryptografisk nøgle. Den ene linje sparer en time, hver gang nogen reviderer udrulningen.