De tweede voordracht op de WIRE-VIE lezingenavond van 14 maart jl. werd verzorgd door Sieuwert van Otterloo. Als afstudeerwerk bij Wiskunde aan de Universiteit Utrecht heeft hij de veiligheid van het openbare cryptografische systeem Pretty Good Privacy (PGP) onderzocht. Hij is begeleid door Gerard Tel en Mario de Boer. Zijn rapport (Engels, september 2001) blijkt goed leesbaar. Voor afkortingen en verwijzingen zie aan het einde van dit verslagje.
Ik gebruik zelf PGP en ken de achtergronden ervan, maar ik heb altijd blindelings vertrouwd op anderen, als het gaat om de vraag hoe veilig PGP is (uiteraard wegens tijdgebrek :-). Vandaar dat ik benieuwd was naar de werkwijze en bevindingen van Sieuwert.
De lijn van zijn verhaal is kort maar krachtig: Overzicht van de (kern)functionaliteit van PGP, geschiedenis achter het ontstaan van PGP, opzet van het onderzoek, enkele bevindingen (zwaktes!) en een afsluiting met aanbevelingen. Ik vertel het een beetje anders.
PGP is een software systeem waarmee personen, die elkaar berichten sturen, ervoor kunnen zorgen
Eigenschap 1. wordt gerealiseerd door vercijferen en 2. en 3. door digitale handtekeningen. PGP bereikt beide met (onder meer) zogenaamde public-key cryptografie. Elke deelnemer heeft daarbij een sleutelpaar (p, g), bestaande uit een openbare sleutel p (public key) en een geheime sleutel g (secret key). Gegeven p, is de bijbehorende g praktisch onvindbaar. Verder zijn er functies E (encrypt) en D (decrypt) met de eigenschap dat voor sleutelpaar (p, g) en berichten b en c geldt
c = E.p.b <==> b = D.g.c
d.w.z. dat E.p en D.g elkaars inverse zijn.
[Kanttekening bij Eindhovense informatica-notatie: E.p.b is het resultaat van functie E toegepast op de twee argumenten p en b. Voor vaste p is E.p op te vatten als een functie die werkt op één argument, nl. een boodschap.]
Goede crypto-functies hebben de volgende eigenschap, die ik even (*) noem:
Als alleen bericht c=E.p.b en de publieke sleutel p bekend zijn, dan is de bijbehorende boodschap b=D.g.c praktisch onvindbaar.
Tegenwoordig formuleert men dit nog scherper: zonder g moet het praktisch ondoenlijk zijn om welke informatie dan ook over de boodschap b te kunnen achterhalen, zelfs als daarbij uitgebreid mag worden geëxperimenteerd met het systeem.
Als Alice een bericht b alleen door Bob wil laten lezen, dan vercijfert ze het met Bobs publieke sleutel p en stuurt hem c=E.p.b. Alleen Bob weet de bijbehorende geheime sleutel g en kan bij ontvangst van c weer b=D.g.c terugkrijgen. Deze veiligheid berust dus op eigenschap (*).
Als Alice een bericht c wil ondertekenen (opdat anderen kunnen nagaan dat niemand anders dan zij het geschreven heeft), dan verstuurt ze als handtekening b=D.g.c waarbij g haar geheime sleutel is. Een ieder kan via haar openbare sleutel p nagaan dat c=E.p.b en bovendien kan niemand anders dan Alice die b=D.g.c maken uit alleen c en p. De veiligheid berust alweer op eigenschap (*).
Het PGP systeem heeft een drietal onlosmakelijke facetten:
Het PGP schema is openbaar vastgelegd in de OpenPGP Standard RFC 2440 (65 blz.). PGP programmatuur is in vele versies beschikbaar voor vele platformen (zowel vrij/open source, als commercieel). Het derde punt, m.b.t. gebruikers, raakt de kern van de zaak, want de beschikbaarheid van sterke cryptografische algoritmen heeft het probleem van veiligheid verschoven naar sleutelbeheer. Een aanzienlijk deel van PGP heeft hierop betrekking en dit is ook waar PGP zich onderscheid van vercijferprogramma's die alleen maar vercijferen via een zelfverzonnen sleutel of wachtwoord. Daarom besteed Sieuwert wat meer aandacht aan sleutelbeheer.
Het grote "rest"probleem bij gebruik van sterke cryptografische algoritmen is het omgaan met sleutels. Doordat de algoritmen sterk zijn, berust de veiligheid geheel op de sleutels:
Het eerste punt wordt (deels) opgelost door de geheime sleutel niet open en bloot op de computer van de betreffende deelnemer op te slaan, maar beschermd via een wachtwoord, liever zelfs een hele wachtzin (pass phrase). Het tweede punt is het echte probleem. Daartoe is het goed te weten met welke doelen Phil Zimmermann destijds PGP heeft ontwikkeld. Zelf vat hij zijn betoog samen in één zin:
PGP empowers people to take their privacy into their own hands.
Er is legitieme behoefte aan veilige communicatie, ook met anderen die je misschien niet altijd uit eerste hand kent. In vele landen kan alleen al het bespreken van het onderwerp van mensenrechten je in grote problemen brengen. Mensenrechtenorganisaties hebben daarom behoefte aan veilige communicatiekanalen. Sieuwert vertelt nog meer over de woelige geschiedenis rond PGP en Phil Zimmermann, maar dat laat ik weg.
Hoe weet je nu dat je de juiste publieke sleutel te pakken hebt? Omdat die op een webpagina staat? Of omdat de juiste naam erop staat? Misschien heeft een hacker of geheime dienst wel stiekem een eigen publieke sleutel in omloop gebracht met de naam van de ander. De "klassieke" oplossing hiervoor is het verspreiden van publieke sleutels via een onafhankelijke, door iedereen vertrouwde, partij (Trusted Third Party, TTP). De posterijen spelen die rol bij postverzending. Maar wie is in de huidige globale digitale wereld te vertrouwen? Overheden genieten dat vertrouwen allang niet meer. Bovendien kan met TTPs veel mis gaan, ook als ze te goeder trouw zijn. PGP probeert dit op te lossen door het aanleggen van een zogenaamd Web of Trust, dat geen centrale TTP vereist. Deelnemers kunnen daarbij hun vertrouwen in elkaars publieke sleutels aangeven door er een handtekening op te zetten.
Ik vertrouw bijvoorbeeld de sleutel van een goede vriend V, omdat ik die sleutel op een diskette van V zelf overhandigd heb gekregen. Ik kan dat vertrouwen aangeven door een versie van die sleutel in omloop te brengen met mijn handtekening erop. Ik teken voor mijn vertrouwen in (de validiteit van) de sleutel van V; niet voor de betrouwbaarheid van de persoon V. Zulk vertrouwen kan zich via transitiviteit voortplanten. Iemand anders die mij vertrouwt, maar die V niet zelf kent, kan zo toch vertrouwen hebben in de publieke sleutel waarvan beweerd wordt dat deze bij V hoort, door te verifiëren dat mijn handtekening erop echt is. PGP kan die handtekeningen controleren; PGP kan natuurlijk niet nagaan wie welke personen vertrouwt.
Om de veiligheid van PGP te onderzoeken heeft Sieuwert een aantal dingen gedaan:
In het PGP schema lijken geen fouten of zwaktes te zitten. De extra complexiteit m.b.t. sleutelbeheer, waaronder ook recentere uitbreidingen als Additional Decryption Keys (ADK), bemoeilijkt zo'n controle echter. De enige bugs die zijn gerapporteerd betreffen fouten in implementaties (en die zijn telkens snel verholpen, zoals de zogenaamde ADK bug, die vanaf versie 6.5.8 verholpen is).
Sieuwert heeft de broncode van de Zimmermann-familie van PGP implementaties geïnspecteerd. Dit werd bemoeilijkt door allerlei voorzieningen m.b.t. het gebruikers-interface. Tot en met versie 2.6.x is er alleen een command-line interface (en geen mogelijkheid tot ADK). Latere versies hebben een GUI en dat vergt heel wat extra code waar van alles in schuil kan gaan.
Sieuwert heeft bij het inspecteren van de broncode daarom met name gelet op de volgende "gevoelige" zaken (waarvan bekend is dat er bij andere cryptografische systemen wel eens fatale fouten bij gemaakt zijn):
Die random number generator (RNG) is belangrijker dan menigeen zou denken. Twee nieuwe gebruikers die ieder een vers PGP programma gebruiken om hun eigen sleutelpaar te maken, moeten natuurlijk ongecorreleerde sleutels verkrijgen. Daartoe moet de uitvoer van de RNG volkomen onvoorspelbaar en onreproduceerbaar zijn, in tegenstelling tot bijv. het gebruik van RNGs in statistische simulatoren, waar andere eisen aan worden gesteld. Voor cryptografische RNGs is met name initialisatie (seeding) moeilijk.
Ook bij het vercijferen van berichten speelt die RNG (helaas) een belangrijke rol. Omdat public-key vercijfering nogal rekenintensief is, gebruikt PGP dit niet voor het vercijferen van het bericht zelf, maar alleen voor het vercijferen van een geheime berichtensleutel (session key, die i.h.a. veel korter zal zijn dan de te vercijferen berichten. Die berichtensleutel wordt gebruikt voor het vercijferen van het bericht via een veel sneller symmetrisch crypto-algoritme (zoals DES en AES), waarbij verzender en ontvanger dezelfde sleutel moeten gebruiken. De berichtensleutel wordt per bericht aangemaakt en dient eveneens onvoorspelbaar en onreproduceerbaar te zijn door onbevoegden.
Sieuwert meldt dat hij bij het lezen van PGP broncode geen ernstige ongeregeldheden is tegengekomen. Zie zijn verslag voor details.
Door experimenteren heeft Sieuwert wel een nieuwe fout gevonden in PGP implementaties. Het betreft hier een probleem rond de validiteit van publieke sleutels waaraan meer dan een User ID is gekoppeld. Er zijn PGP implementaties die soms ten onrechte rapporteren dat een sleutel valide is, omdat een van de gekoppelde user IDs valide is (wegens een vertrouwde handtekening), maar niet de User ID die je in gedachte had. Het gaat feitelijk om een fout in het gebruikers-interface waar sprake is van validiteit van een sleutel, zonder duidelijk te maken m.b.t. welke User ID. Het volgende scenario illustreert de Otterloo aanval:
Dit is ondertussen in nieuwere implementaties van PGP verholpen. In oudere versies kun je zelf ook wel betere controles doen, maar je moet dan wat argwanender zijn ingesteld.
De PGP standaard is gebaseerd op sterke cryptografische algoritmen. PGP implementaties bevatten wel foutjes, en voor zeer korte tijd ook wel veiligheidsproblemen, maar niets dat echt ernstig is. Toch zijn zowel de standaard als de implementaties ervan behoorlijk ingewikkeld geworden door allerlei uitbreidingen (denk aan ADK en GUI). Dit bemoeilijkt controle nodeloos.
Sieuwert laat niet na om nog eens te benadrukken dat zonder broncode het praktisch ondoenlijk is om veiligheid van software serieus te onderzoeken. In feite heb je ook nog de ontwerpdocumentatie nodig.
Uit de Zimmermann-familie van PGP implementaties beveelt Sieuwert het gebruik van versie 2.6.x aan (geen GUI, geen ADK) en 6.5.8 (wel GUI, wel ADK, geen ADK bug, wel de Otterloo onhebbelijkheid). Van beide versies is de broncode vrij beschikbaar. Daarnaast is GNU Privacy Guard (GPG) een goede alternatieve implementatie (i.h.a. zonder GUI).
Na afloop van de lezing is er nog een heftige discussie rond veiligheid en openheid:
De meningen in de zaal liggen nogal verdeeld en de tijd is te beperkt om de zaken voldoende toe te lichten. Overigens zijn ook de meningen hierover in de industrie verdeeld. Laat ik in dit verslagje toch nog een poging doen wat extra inzicht te verschaffen.
In de professionele crypto-gemeenschap is men al lang overtuigd van het principe van Kerckhoffs uit 1883:
De veiligheid van een crypto-systeem moet niet afhangen van het geheimhouden van het crypto-algoritme. De veiligheid mag alleen afhangen van het geheimhouden van de sleutel.
Uit de praktijk is keer op keer gebleken dat de gebruikte cryptografische algoritmen altijd uitlekken. Denk bijvoorbeeld aan GSM en DVD. Verder is het ook zo dat goede cryptografische algoritmen zeer moeilijk te ontwikkelen zijn. Voornoemde cryptografische algoritmen van GSM en DVD zijn inderdaad "gebroken". Vandaar dat grondige analyse door crypto-experts een noodzaak is. Hiervoor is openheid nodig. De nieuwe Advanced Encryption Standard (AES) is bijvoorbeeld geheel in openbaarheid tot stand gekomen. "Security by obscurity" heeft nog nooit gewerkt.
Of de broncode van implementaties ook openbaar moet zijn, ligt natuurlijk weer iets anders. Een fout in de implementatie van een sterk crypto-algoritme kan zwaktes introduceren. Dat wil je de tegenstander niet graag op een presenteerblaadje geven. Toch is ook hier in de praktijk telkens weer gebleken dat gesloten implementaties meer fouten bevatten dan de open implementaties.
Ook het onderdrukken van meldingen over zwaktes in cryptografische systemen heeft in de praktijk geen goede naam gemaakt. Leest u daar maar over in de nieuwsbrief Crypto-Gram (zie hieronder).