Wat is Forward Secrecy?

December 17, 2013
1

Onlangs maakte Twitter bekend voor de beveiliging van haar communicatie over te gaan op Forward Secrecy (ook wel Forward Security of Forward Privacy genoemd). Dat is een lastig begrip, dat ook in de Nederlandse media niet helemaal goed werd uitgelegd. Want het begrip 'wegwerpsleutel' dekt de lading niet helemaal.

Wat is het dan wel?

Veel websites versleutelen de communicatie tussen jou PC (of mobiel) en hun webserver. Dit kun je zien aan het slotje in je browser (en het feit dat de link van de website begint met https). De sleutel die hiervoor gebruikt wordt, wordt voor iedere 'sessie' (grof gezien een periode waarin je op de website surft en verschillende pagina's bezoekt; je kunt het vergelijken met een 'gesprek') gegenereerd. Jou PC en de webserver moeten natuurlijk dezelfde sleutel gebruiken. Anders kunnen ze elkaar niet 'verstaan'. Deze sessie sleutel moeten ze daarom gezamenlijk aan het begin van de sessie afspreken. Dat kan op een aantal manieren.

Merk op dat iedere andere partij die de sessie sleutel in handen krijgt een opgenomen versleutelde sessie later alsnog kan ontcijferen en de uitgewisselde informatie alsnog kan achterhalen. Aan het eind van de sessie gooien beide partijen deze sessie sleutel daarom ook direct weg.

De eenvoudigste manier om een sessie sleutel af te spreken werkt als volgt.

Er is een vorm van cryptografie die het mogelijk maakt om een bericht te versleutelen met een zogenaamde publieke sleutel (die iedereen mag kennen). Alleen de eigenaar van de bijbehorende private sleutel kan dit bericht vervolgens ontcijferen. Stel de webserver genereert zo'n sleutelpaar, en houdt de private sleutel voor zichzelf en geeft alle gebruikers de bijbehorende publieke sleutel. Dan kunnen een gebruiker en de webserver als volgt een sessie sleutel afspreken:

  • de gebruiker genereert een willekeurige sessie sleutel,
  • versleutelt deze met de publieke sleutel van de webserver, en
  • stuurt die op (aan de webserver).

Alleen de webserver kan dit bericht ontcijferen (alleen hij heeft de bijbehorende private sleutel), en zo achter de te gebruiken sessie sleutel komen.

Dat klinkt veilig, en is dat ook. Maar helaas maar tot op zekere hoogte.

Stel dat de webserver slordig is en zijn private sleutel lekt. Of (en dat is een waarschijnlijker scenario) stel dat de eigenaar van de webserver bezoek krijgt van een opsporingsinstantie met het verzoek hen de private sleutel te overhandigen. Als de opsporingsinstantie al een paar maanden de versleutelde communicatie met de webserver onderschept heeft, kan ze het volgende doen. Ze zoekt naar het begin van de sessie, ontcijfert het eerste bericht (waar de sessie sleutel is afgesproken) met de private sleutel die ze heeft verkregen, en krijgt zo alsnog de sessie sleutel in handen. Met deze sleutel ontcijfert ze de rest van de opgeslagen communicatie in de sessie.

De opsporingsinstantie kan zo dus onbeperkt terug gaan in de tijd. Het zou mooi zijn als dit beperkt kon worden. Dat is waar Forward Secrecy voor is bedacht.

Forward Secrecy zorgt ervoor dat als iemand de private sleutel in handen krijgt, hij alleen toekomstige sessie sleutels kan achterhalen. Sessie sleutels die in het verleden met behulp van deze private (en bijbehorende publieke sleutel) zijn afgesproken zijn dat niet, en de daarmee beschermde communicatie uit het verleden blijft dus geheim.

Om Forward Secrecy te bereiken moet de sessie sleutel dus op een andere manier onderling worden afgesproken. Hiervoor moeten we gebruik maken van een zogenaamde Diffie-Hellman ephemeral key exchange (die term mag je meteen weer vergeten). Die werkt ongeveer als volgt (en om dit uit te leggen moeten we terug naar de lagere school: klok rekenen).

We nemen hiervoor een beetje rare klok: een klok met 13 uren. Stel ik zet de klok op 2 uur. En stel ik vermenigvuldig de tijd op de klok een aantal keren met 2. Zeg dat ik dat 4 keer doe. Iedere keer is als ik daarbij over de 13 heen ga trek ik 13 van het resultaat af. Dan ga ik van 2 naar 4, van 4 naar 8, van 8 naar (16 min 13 is) 3, en van 3 naar 6 uur. Nu geef ik de klok aan jou. Jij vermenigvuldigd de tijd op de klok 3 keer met 2. Dan gaat de klok van 6 naar 12, van 12 naar (24 min 13 is) 11, en van 11 naar (22 min 13 is) 9 uur . Aan het eind staat de klok dus op 9 uur. Datzelfde was gebeurd als jij de tijd op de klok (beginnend bij 2) eerst 3 keer met 2 had vermenigvuldigd, en ik vervolgens 4 keer met 2.

Hiermee kunnen we een sleutel uitwisselen. We zetten allebei de klok op 2 uur. Vervolgens kiezen we ieder een geheim getal: ik x en jij y. Ik vermenigvuldig mijn klok x keer met 2, en jij jou klok met y keer 2. Vervolgens stuur ik mijn klok naar jou (en jij de jouwe naar mij). En ik vermenigvuldig de klok die ik van jou ontvang weer x keer met 2 (en jij de klok die je van mij ontvangt y keer met 2). Dan zijn beide klokken x+y keer met 2 vermenigvuldigd en staan ze op dezelfde tijd: onze geheime sleutel.

Dit werkt alleen op hele grote klokken, en bij een goed gekozen start getal. Bij dit soort klokken is aan de stand van de klok niet te zien hoeveel keer ik hem met het start getal heb vermenigvuldigd. (Als dat wel zou kunnen dan rekent een aanvaller snel uit hoe vaak ik dat heb gedaan met mijn klok, en past dat toe op de klok die jij mij stuurt. Zo heeft de aanvaller dan ook onze 'geheime' sleutel.) Maar nogmaals, op grote klokken kan dat niet. De enige manier om op zo'n klok mijn geheime getal te achterhalen is om met het start getal te beginnen en net zolang door te gaan tot je op mijn stand van de klok uitkomt. Dat is monnikenwerk als je bedenkt dat de klok in werkelijkheid heel erg groot is: de hoogste tijd is een 1 gevolgd door 1000 nullen...

Om te zorgen dat de Diffie Hellman key exchange echt goed verloopt moeten we er wel allebei zeker van zijn dat we inderdaad de klok van de ander ontvangen (en dat de aanvaller niet stiekem klokken verwisselt of verandert). Dat kunnen we voorkomen door onze (digitale) handtekening op de sluiting van de klok te zetten.

P.S.: Als iemand een andere analogie heeft waarmee forward secrecy uitgelegd kan worden, dan hoor ik dat graag. De klokken-analogie is me iets te letterlijk en te wiskundig.

Het is enigzins vergelijkbaar met het mooie verhaal van Roald Dahl over de perfecte moord waarbij een vrouw haar man de schedel in slaat met een bevroren lamsbout. Ze doet vervolgens de lamsbout in de oven en serveert deze aan de hongerige politieagenten die 's avonds bij haar thuis het onderzoek naar de dood van haar man uitvoeren. Op deze manier zorgt ze ervoor dat al het bewijsmateriaal perfect is vernietigd.

In case you spot any errors on this page, please notify me!
Or, leave a comment.
Heartbleed: the effects of irresponsible disclosure. // Jaap-Henk Hoepman
, 2014-04-13 12:37:39
(reply)

[…] Cybercriminals and intelligence agencies are in all likelihood very busy right now collecting user passwords and the private keys of websites while they (still) can. Whether the NSA knew about and exploited the bug for years is in fact not very relevant. By collecting as many private keys of websites as they can right now, they can retroactively decrypt previously recorded secure internet traffic at leisure (unless those sites encrypted their traffic using perfect forward security). […]