Wat een wachtwoordzin op een privésleutel van een VPN werkelijk beschermt

De prompt die verschijnt wanneer een VPN-client start, is makkelijk verkeerd te lezen. Het is niet het wachtwoord van het VPN-account, het is niet het wachtwoord voor de tunnel, en het invoeren ervan bewijst niet dat de verbinding veilig is. Hij ontgrendelt één opgeslagen weergave van een privésleutel zodat de client het sleutelmateriaal kan lezen en gebruiken om te authenticeren. Alles wat daarna gebeurt, is een andere vraag.

In de praktijk gaat het antwoord mis aan de randen: mensen nemen aan dat de wachtwoordzin de actieve tunnel beschermt, of dat het wijzigen ervan een kopie van de sleutel intrekt die al is uitgelekt. Beide aannames falen, en beide falen op een manier die een credential bloot laat terwijl de operator denkt dat het is afgehandeld.

Eén dialoog, meerdere verschillende geheimen

Een wachtwoordzin van een privésleutel ontsleutelt een bestand. Een accountwachtwoord authenticeert je bij een dienst. Een PKCS#12-importwachtwoord ontsleutelt een bundel met een sleutel en het bijbehorende certificaat, en het is misschien niet dezelfde tekenreeks als de wachtwoordzin van de sleutel zelf. Deze prompts kunnen er bijna identiek uitzien, en raden welk geheim waar hoort is hoe sleutels in het verkeerde veld belanden.

De versleuteling van de tunnel zelf is een vierde ding. Het datakanaal gebruikt sessiesleutels die tijdens de handshake worden onderhandeld; de wachtwoordzin van de privésleutel speelt geen rol bij de bescherming van afzonderlijke pakketten. Als iemand het sleutelbestand kan lezen, kan hij proberen de wachtwoordzin offline te raden, maar als hij pakketten kan lezen, is de wachtwoordzin irrelevant.

Wat de versleuteling op schijf dekt

Een versleutelde PEM-sleutel bestaat in twee vormen, en de header vertelt je welke je hebt. De moderne PKCS#8-vorm begint met -----BEGIN ENCRYPTED PRIVATE KEY-----; de oudere PEM-vorm, nog steeds gangbaar in oudere OpenVPN-opstellingen, begint met -----BEGIN RSA PRIVATE KEY----- en draagt Proc-Type: 4,ENCRYPTED en een DEK-Info-regel direct eronder. Het bestand bevat de privésleutel versleuteld onder een sleutel die van je wachtwoordzin is afgeleid, meestal via een op een wachtwoord gebaseerde KDF met een opgegeven iteratieaantal of werkfactor. De OpenSSL pkey-documentatie behandelt de formaten en de wachtwoordzinopties die gelden bij het lezen.

Daar volgen twee gevolgen uit. Een zwakke wachtwoordzin is offline aan te vallen met de snelheid die de KDF toestaat, dus bestandsrechten en toegang tot back-ups blijven belangrijk, ook wanneer het bestand versleuteld is. En een aanvaller die alleen het bestand zonder de wachtwoordzin krijgt, moet raden; wie het bestand en de wachtwoordzin krijgt, heeft de sleutel, precies alsof die nooit versleuteld is geweest.

head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout

head -3 toont de header en, op een ouder bestand, de regels Proc-Type en DEK-Info die versleuteling bewijzen; één regel alleen is in geen enkele richting bewijs. De regel pkey vraagt om de wachtwoordzin en print alleen de publieke helft, wat bewijst dat het bestand en de wachtwoordzin werken zonder de privésleutel bloot te leggen. Gebruik -text niet voor die controle: het print de privécomponenten, privateExponent, prime1, prime2 en de rest, en die uitvoer mag nooit ergens worden geplakt, niet in een ticket, een chat of een log. Het PKCS#12-commando vertelt je ook of de bundel een apart MAC- of versleutelingswachtwoord heeft, wat handig is om te weten voordat je hem aan een collega geeft.

Wat het niet meer beschermt zodra de sleutel is geladen

Ontgrendelen is een eenmalige gebeurtenis voor dat proces. De client vraagt de KDF om de sleutel, ontsleutelt het bestand en houdt de privésleutel in het geheugen zolang hij die nodig heeft. Vanaf dat moment beschermt de wachtwoordzin niets meer aan de actieve sessie: niet het procesgeheugen, niet een coredump, niet een foutopsporingssessie die aan de client hangt, en niet een back-up van de machine die is gemaakt terwijl de sleutel in gebruik was.

Dit is dezelfde grens als een SSH-sleutel met een wachtwoordzin, of de ontgrendelde kluis van een wachtwoordmanager. Het verhoogt de kosten van het stelen van het bestand in rust en doet niets tegen malware die als jouw gebruiker draait, een geautoriseerde toepassing die de client om een handtekening vraagt, of een beheerder die geheugen kan lezen. Behandel het als één laag, niet als de controle die een sleutel veilig maakt om te laten liggen.

Waarom de prompt steeds terugkomt

Een client die bij elke herverbinding opnieuw vraagt, is niet per se kapot. Sommige clients cachen de wachtwoordzin voor de sessie, sommige bewaren hem in de sleutelhanger van het besturingssysteem, en sommige kunnen naar een helper worden verwezen die hem levert, dus welk gedrag je krijgt, hangt af van de client en zijn configuratie, niet van het sleutelbestand.

Als de herhaalde prompt de echte klacht is, bekijk dan de cache- en authenticatieopties van de client voordat je versleuteling van de sleutel haalt. De wachtwoordzin verwijderen maakt van een beschermd bestand een sleutel in platte tekst, en de herverbinding wordt stil ten koste van de enige controle in rust die je had. Een beter antwoord is meestal een ondersteunde credentialstore met dezelfde bestandsrechten die je toch al zou gebruiken.

Verlies en blootstelling zijn niet dezelfde reparatie

Een verloren wachtwoordzin kan niet uit het certificaat worden hersteld. Het certificaat is openbaar materiaal dat een naam aan een sleutel bindt; het bevat geen weg terug naar de privésleutel en geen aanwijzing over de wachtwoordzin. De praktische opties zijn een geautoriseerde back-up van de sleutel, of een nieuwe identiteit die via het normale proces van de operator wordt uitgegeven. Iedereen die aanbiedt de wachtwoordzin te 'herstellen', biedt aan hem te raden.

Blootstelling vraagt een andere reactie. Dezelfde sleutel opnieuw versleutelen met een nieuwe wachtwoordzin laat het sleutelmateriaal onveranderd, dus een kopie die elders al is ontgrendeld, werkt nog steeds. De reparatie is de credential intrekken of vervangen: geef een nieuwe sleutel en certificaat uit, distribueer ze, en trek de oude bij de peer uit. Tot dat gebeurt, is het wijzigen van het bestandswachtwoord huishoudelijk werk, geen indamming. Houd het oude bestand pas buiten back-ups nadat de nieuwe identiteit werkt, en noteer welk serienummer of welke vingerafdruk hem heeft vervangen.