Forward secrecy voor een VPN: wat een gestolen sleutel kan openen

Neem vandaag een versleutelde tunnel op, steel volgend jaar de langetermijnprivésleutel van de server en probeer de opname te ontsleutelen. Forward secrecy is de eigenschap die zegt dat de gestolen sleutel alleen niet genoeg zal zijn. Het is een uitspraak over opgenomen sessies en specifieke geheimen, geen algemene belofte dat de tunnel veilig was. Het bereik goed afbakenen is wat de term bruikbaar maakt.

De vraag gaat over een opname, niet over de live sessie

De langetermijnsleutel identificeert het eindpunt en ondertekent de handshake. Sessiesleutels versleutelen het werkelijke verkeer, en in een forward-secret-ontwerp worden ze afgeleid van vers sleuteluitwisselingsmateriaal dat beide kanten genereren en daarna weggooien. Een aanvaller met alleen de langetermijnsleutel kan die weggegooide waarden niet reconstrueren. Een aanvaller met live sessietoestand kan dat nog wel, en daarom gaat de garantie over het verleden in plaats van het heden.

De bewering is voorwaardelijk: ze geldt alleen als de efemere geheimen echt zijn vernietigd en het protocol het protocol is dat u denkt. Een gemengde uitrol kan er op de ene tunnel aan voldoen en op een andere falen.

Eén geheim mag de andere niet opnieuw opbouwen

Controleer de onderhandelde modus in plaats van de marketingpagina. De handshake-uitvoer noemt de sleuteluitwisseling en de protocolversie.

openssl s_client -connect vpn.example.com:443 -tls1_3 -brief
swanctl --list-sas

De s_client-samenvatting toont de TLS-versie en de sleuteluitwisselingsgroep, en een efemere groep is het zichtbare teken van een forward-secret-sleutelafspraak. De swanctl-lijst toont IKE- en CHILD-associaties met hun sleutelvernieuwingstimers, zodat u kunt zien of de uitrol sleutels volgens een schema vernieuwt. Een statische RSA-sleuteluitwisseling, of een oude compatibiliteitsmodus, verliest de eigenschap ongeacht de naam van het cijfer. Noteer de modus die u hebt waargenomen, niet die de leverancier adverteerde.

Sleutelvernieuwing is niet automatisch forward secrecy

Hoe vaak een tunnel sleutels vernieuwt is een aparte vraag van hoe elke sleutel wordt afgeleid. Een ontwerp dat sleutels opnieuw genereert uit een langetermijngeheim kan elke minuut vernieuwen en toch de test falen, omdat een latere compromittering ze allemaal reconstrueert. Omgekeerd kan een protocol met zeldzame vernieuwing nog steeds forward secret zijn wanneer elke uitwisseling onafhankelijk is. Lees de afleiding, niet het interval, en verwar een korte herverbindingstimer niet met een cryptografische garantie.

Dezelfde verwarring verschijnt bij cijfernamen: een modern cijfer zegt niets over hoe zijn sleutel aankwam.

Wat zichtbaar blijft na de garantie

Forward secrecy beschermt de leesbare tekst van opgenomen sessies tegen een toekomstige sleutelcompromittering, en het doet niets tegen een aanvaller die live verkeer leest op een gecompromitteerd eindpunt. Het verwijdert geen bestemmingsadressen, timing of volume uit de opname, en het beperkt niet hoe lang een operator verbindingslogboeken bewaart. Het maakt een gecompromitteerde client ook niet betrouwbaar, omdat de aanvaller al zit waar inhoud in leesbare vorm bestaat.

Wanneer een provider forward secrecy claimt, vraag welk langetermijngeheim als gestolen wordt verondersteld en welke sessiegeheimen ontoegankelijk blijven. Als deze twee vragen duidelijke antwoorden hebben, betekent de bewering iets.