Wat een vooraf gedeelde sleutel doet in IPsec, OpenVPN en WireGuard

De woorden vooraf gedeelde sleutel staan in de documentatie van IPsec, OpenVPN en WireGuard, en ze beschrijven drie verschillende objecten. Het ene is een authenticatiegeheim, het andere beschermt een controlekanaal en het derde voegt materiaal toe aan een handshake die al identiteiten heeft. Ze als uitwisselbaar behandelen levert een verbinding op die faalt in een fase die niemand verwachtte. Lees wat het veld in dat protocol doet voordat je er een waarde in kopieert.

Drie protocollen, drie betekenissen

Elk protocol legt de taak van de sleutel vast in zijn eigen specificatie, en die taken overlappen elkaar niet. Een authenticatiegeheim bewijst dat twee peers dezelfde waarde kennen. Een sleutel voor het controlekanaal beschermt de onderhandeling die volgt. Een toevoeging aan de handshake verandert het sleutelschema zonder te veranderen wie de peers zijn.

Geen van die rollen authenticeert een menselijke gebruiker, en dat is de verwarring die de meeste tijd kost. Een vooraf gedeelde sleutel wordt vóór de uitwisseling op apparaten of gateways gezet, zodat elke houder er voor de andere kant hetzelfde uitziet. Die eigenschap is een voordeel voor een site-naar-site-koppeling tussen twee routers en een risico voor een dienst voor toegang op afstand met medewerkers bij naam. Houd de accountreferentie en het cryptografische geheim in aparte kolommen van elk document dat de uitrol beschrijft.

IPsec en OpenVPN gebruiken het woord anders

IKEv2 kan een peer authenticeren met een vooraf gedeeld geheim in plaats van certificaten, en de waarde moet aan beide kanten kloppen. Omdat hetzelfde geheim meestal voor een groep peers wordt geconfigureerd, kan elke houder zich als de anderen voordoen, en de uitwisseling wint geen forward secrecy uit identiteitssleutels die er nooit waren.

De opties tls-auth en tls-crypt van OpenVPN hangen een statische sleutel aan het controlekanaal, door een HMAC-handtekening toe te voegen of de onderhandeling zelf te versleutelen. Die sleutel is geen gebruikerswachtwoord en vervangt het clientcertificaat niet. Het onderscheid telt bij de vernieuwing, wanneer een wachtwoordwijziging de sleutel van het controlekanaal ongemoeid laat.

De PSK van WireGuard voegt toe, hij identificeert niet

Peers van WireGuard hebben al publieke en private Curve25519-sleutels, en de handshake authenticeert die identiteiten. Een optionele vooraf gedeelde sleutel wordt in de koppelsleutel gemengd en levert symmetrisch materiaal bovenop de uitwisseling van publieke sleutels.

Hij levert geen eigen identiteit en geen gebruikersaccount, dus een beheerder kan twee houders niet aan hun PSK onderscheiden. Beide kanten moeten dezelfde waarde hebben, anders faalt de handshake zonder nuttige foutmelding. Daarom moet rotatie voor beide zijden tegelijk worden gepland en niet als het bewerken van één bestand.

Controleer distributie, rotatie en verwijdering

Distributie is het zwakke punt van elk ontwerp dat één geheim op veel plaatsen gebruikt. Een waarde die in een chatvenster wordt geplakt, in een repository wordt bewaard of tussen omgevingen wordt hergebruikt, verzamelt kopieën die niemand kan opsommen, en elke kopie vergroot stil de schade.

Base64-tekst is geen versleuteling. Een geheim dat naast een openbaar certificaat in dezelfde map staat, is nog steeds een geheim in klare tekst.

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

Roteer volgens een schema en na elke vermoede blootstelling, en werk elke bedoelde peer bij voordat je de oude waarde intrekt. Test de koppeling daarna vanaf beide kanten, want een sleutel die niet klopt faalt bij de handshake en lijkt precies op een firewallprobleem.

Leg vast welk geheim welke fase beschermt, zodat een wachtwoordreset nooit wordt aangezien voor het vernieuwen van een cryptografische sleutel. Die ene regel bespaart een uur telkens wanneer iemand de uitrol controleert.