Vad en i förväg delad nyckel gör i IPsec, OpenVPN och WireGuard

Orden i förväg delad nyckel förekommer i dokumentationen för IPsec, OpenVPN och WireGuard, men de beskriver tre olika objekt. Den ena är en autentiseringshemlighet, den andra skyddar en kontrollkanal och den tredje tillför material till en handskakning som redan har identiteter. Behandlar man dem som utbytbara får man en anslutning som misslyckas i ett skede som ingen förväntade sig. Läs vad fältet gör i det protokollet innan du kopierar in ett värde i det.

Tre protokoll, tre betydelser

Varje protokoll definierar nyckelns uppgift i sin egen specifikation, och uppgifterna överlappar inte. En autentiseringshemlighet bevisar att två parter känner till samma värde. En nyckel för kontrollkanalen skyddar den efterföljande förhandlingen. Ett tillägg till handskakningen ändrar nyckelschemat utan att ändra vilka parterna är.

Ingen av dessa roller autentiserar en människa, och just den sammanblandningen kostar mest tid. En i förväg delad nyckel läggs på enheter eller gateways före utbytet, så varje innehavare ser likadan ut för andra sidan. Den egenskapen är en fördel för en förbindelse mellan två routrar och en risk för en fjärråtkomsttjänst med namngivna anställda. Håll kontouppgifterna och den kryptografiska hemligheten i skilda kolumner i det dokument som beskriver driftsättningen.

IPsec och OpenVPN använder ordet olika

IKEv2 kan autentisera en peer med en i förväg delad hemlighet i stället för certifikat, och värdet måste stämma i båda ändar. Eftersom samma hemlighet oftast konfigureras för en grupp parter kan varje innehavare utge sig för de andra, och utbytet får ingen framåtriktad hemlighet från identitetsnycklar som det aldrig hade.

OpenVPN:s tls-auth och tls-crypt kopplar en statisk nyckel till kontrollkanalen och lägger till en HMAC-signatur eller krypterar själva förhandlingen. Den nyckeln är inte ett användarlösenord och ersätter inte klientcertifikatet. Skillnaden spelar roll vid förnyelse, då ett lösenordsbyte lämnar kontrollkanalens nyckel orörd.

WireGuards PSK lägger till, den identifierar inte

WireGuard-parter har redan offentliga och privata Curve25519-nycklar, och handskakningen autentiserar dessa identiteter. En valfri i förväg delad nyckel blandas in i kedjenyckeln och bidrar med symmetriskt material ovanpå utbytet av offentliga nycklar.

Den ger ingen egen identitet och inget användarkonto, så en operatör kan inte skilja två innehavare åt via deras PSK. Båda ändar måste bära samma värde, annars misslyckas handskakningen utan ett hjälpsamt felmeddelande. Därför måste rotation planeras för båda sidor samtidigt och inte som en redigering av en enda fil.

Kontrollera distribution, rotation och borttagning

Distribution är den svaga punkten i varje design som använder en hemlighet på många ställen. Ett värde som klistras in i ett chattfönster, sparas i ett repository eller återanvänds mellan miljöer samlar kopior som ingen kan räkna upp, och varje kopia ökar tyst skadans omfattning.

Base64-text är inte kryptering. En hemlighet som ligger bredvid ett offentligt certifikat i samma katalog är fortfarande en hemlighet i klartext.

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

Rotera enligt ett schema och efter varje misstänkt exponering, och uppdatera varje avsedd part innan du återkallar det gamla värdet. Testa sedan förbindelsen från båda ändar, eftersom en nyckel som inte stämmer misslyckas vid handskakningen och ser exakt ut som ett brandväggsproblem.

Dokumentera vilken hemlighet som skyddar vilket skede, så att en lösenordsåterställning aldrig förväxlas med förnyelse av en kryptografisk nyckel. Den enda raden sparar en timme varje gång någon granskar driftsättningen.