Home Research Education Publications Activities Resources About Me

Veiligheid door Openheid - tot aan de Bron

Jaap-Henk Hoepman

Inleiding

Stel, u bent op reis in het buitenland en u voelt zich plotseling onwel. U komt terecht bij iemand die zich als arts uitgeeft en u krijgt van hem het dringende advies de pillen te slikken die uit een of andere bureaulade te voorschijn komen. U vertrouwt het niet helemaal en vraagt om de bijsluiter. Die blijkt er niet te zijn. Men verzekert u dat deze pillen u veel goed zullen doen. Wat doet u?...

Als het om software gaat, blijken we over het algemeen heel erg goed van vertrouwen te zijn: we geloven de producent van de software op zijn woord en gebruiken de software voor de meest kritische toepassingen, zonder maar een moment stil te staan bij de risico's die we lopen en de hoogte van het vertrouwen die we in de producent stellen.

Kan het ook anders? Als we de bovenstaande analogie volgen, wel degelijk. We zouden om de bijsluiter moeten vragen. We zouden moeten eisen te weten hoe de software is samengesteld. Met andere woorden: de source code zou openbaar gemaakt moeten worden.

In de rest van dit artikel gaan we in op de vraag of open source software inderdaad veiliger is dan closed source software.

Openheid: hoe ver moet je gaan?

Het mag in eerste instantie vreemd lijken om de grootst mogelijke openheid na te streven bij de ontwikkeling van software met een kritisch beveiligingsdoel. Immers, hoe minder de aanvaller weet van het systeem, hoe lastiger het is om het systeem aan te vallen. Dat is de reden dat door de eeuwen heen beveiligingsapparatuur in de grootst mogelijke beslotenheid ontwikkeld wordt. Denk bijvoorbeeld aan communicatieapparatuur voor het leger of aan de ontwikkeling van de beveiliging van gsm.

Echter, al in 1883 formuleerde de Vlaming Auguste Kerckhoffs het fundamentele principe dat zelfs als een deel van de communicatiemiddelen in handen van de vijand valt, het nog steeds mogelijk moet zijn om veilig te communiceren. In een modernere formulering: de veiligheid moet afhangen van de kwaliteit (en de geheimhouding) van de sleutel en níet van het geheim houden van het gebruikte cryptografische algoritme. Tegenwoordig wordt Kerckhoffs' principe wat algemener geïnterpreteerd, namelijk als de eis dat bij het ontwerp van een beveiligingssysteem ervan uitgegaan moet worden dat de vijand dit ontwerp kent, terwijl het nog steeds 'onmogelijk' moet zijn om in dat systeem in te breken.

In Kerckhoffs' dagen was er geen essentieel verschil tussen het ontwerp van een systeem en de implementatie daarvan. Dat is nu wel anders. Ontwerpen van computer programma's zijn veel complexer. Bovendien is het onmogelijk om zo'n ontwerp foutloos te implementeren. Alle software bevat wel een aantal bugs. De vraag is dan of Kerckhoffs principe ook moet gelden voor de broncode van software. Met andere woorden: moet veilige software open source zijn, of juist niet? Dit is op dit moment een actueel punt van discussie. We zullen in de rest van dit artikel op de voors en tegens ingaan.

Geslotenheid, immers: informatie is (over)macht...

Er zijn een aantal argumenten die pleiten voor het geheim houden van de broncode van een programma.

Het belangrijkste argument is wel dat door het openbaar maken van de source een aanvaller eenvoudig op zoek kan gaan naar de onafwendbaar aanwezige bugs (zoals buffer overflows) in het programma, en zo de beveiligingsmaatregelen kan omzeilen. Daar waar in het ontwerp aanwezige fouten nog door grondige reviews of door middel van tools gevonden en hersteld kunnen worden, is dit voor de sourcecode van software in de nabije toekomst zeker niet het geval.

Bovendien is de aanvaller onevenredig in het voordeel: daar waar de aanvaller maar één zwakke plek hoeft te vinden voor een succesvolle aanval, moet de verdediger alle zwakke plekken herstellen om zo'n aanval te voorkomen.

Ook al is de broncode openbaar, dan geeft dat nog geen garantie dat de corresponderende executable geen bugs of back doors bevat. Lang niet altijd heeft de gebruikers de beschikking over alle tools of libraries om de software zelf te compileren, en zal dan alsnog moeten vertrouwen op een derde partij. Bovendien kan de compiler zelf ook nog bugs bevatten of met opzet backdoors meecompileren.

Het openbaar maken van de source garandeert ook helemaal niet dat voldoende gekwalificeerde mensen de source code controleren. Er zijn genoeg open source projecten te vinden die na een korte periode van veel programmeeractiviteit weer in de vergetelheid zijn beland.

Tenslotte geldt dat het ook relatief eenvoudig is om back doors toe te voegen aan een niet strikt geleid open source software project. Zo werd zelfs in de Linux kernel in November 2003 een backdoor ontdekt.

Maar hoeveel macht is dat eigenlijk...

Laten we de bovengenoemde argumenten tegen open source (of voor closed source, zoals u wilt) eens nader bekijken.

Het laatste argument geld natuurlijk net zo goed voor closed source software. Zelfs pakketten als Microsoft Office bevatten zogenaamde "easter eggs" waarvan lang niet altijd duidelijk is of het hogere management daarvan op de hoogte was. Sterker nog, als de source openbaar is kunnen software projecten niet meer zo eenvoudig wegkomen met slecht project management en kwaliteitscontrole.

Wat betreft het eerste argument: het blijkt uitermate lastig te zijn de source code van software lang geheim te houden. Sofware van stemmachines, en recentelijk zelfs van Windows NT, zijn openbaar geworden. Het geclaimde voordeel voor de verdediger is dus slechts van korte duur.

Zelfs zonder de beschikking te hebben over de source kunnen aanvallers vrij eenvoudig, door middel van bijvoorbeeld debuggers en disassemblers, bugs en zwakheden in software vinden. De verdedigers daarentegen kunnen, zonder beschikking te hebben over de hele source, niets doen om deze bugs te verhelpen. Alleen de producent van de closed source software kan dergelijke patches of updates distribueren. Dat kan soms lang duren, en in het geval van al wat oudere (zgn legacy) software gebeurt het al helemaal niet.

We zien dat het gesloten houden van de source de verdediger veel meer schaadt dan de aanvaller: de aanvaller vind de zwakheden toch wel met redelijk gemak, terwijl de verdediger zonder enige vorm van verweer hulpeloos moet toezien.

Informatie is macht: Openheid!

Het belangrijkste argument vóór open source is wel dat het gebruikers in staat stelt om zelf de veiligheid van de software te bepalen (of om andere partijen hiervoor in te huren).

Als er een bug gevonden is, kan de gebruiker die zelf herstellen. Als de patch vervolgens via bijvoorbeeld een website gedistribueerd wordt, kunnen alle andere gebruikers deze patch gebruiken om hun eigen systemen ook te herstellen. Deze gebruikers zelf vinden misschien weer andere bugs: het netwerk effect in optima forma. Of in de woorden van Linus Torvalds: "Given enough eyeballs, bugs are shallow".

Mocht een gebruiker de bug niet zelf kunnen herstellen, dan stelt het beschikbaar zijn van de source hem in ieder geval in staat om efficiënter en duidelijker over de bug te communiceren: gebruiker en ontwikkelaar hebben de dezelfde "frame of reference", nl. de source code. Ook dit zorgt ervoor dat bugs sneller opgelost kunnen worden.

Ook zijn er tools die, gegeven de source code, extra beveiligingsmaatregelen aan het programma toe kunnen voegen. Zo zijn er utilities die run-time checks tegen bijvoorbeeld buffer overflows implementeren. Zonder de source code zijn dergelijke utilities onbruikbaar.

Als de source code beschikbaar is, kan de gebruiker ook beslissen om bepaalde delen van de software niet te gebruiken en daarom ook niet te compileren. Dit verlaagt de complexiteit van het systeem, wat weer de veiligheid verhoogt.

Conclusies

Ondanks de bezwaren die over het algemeen worden opgeworpen, zien we dat het openbaar maken van de source de veiligheid van de software wel degelijk ten goede komt. Ten eerste omdat gebruikers de software zelf op zijn merities kunnen beoordelen. Ten tweede omdat gebruikers zelf fouten in de software kunnen herstellen, zonder hiervoor afhankelijk te zijn van de producent.

Dr. Jaap-Henk Hoepman is senior onderzoeker security en cryptografie aan de Radboud Universiteit Nijmegen.

Dit artikel is verschenen in Livre, 12, juni 2005.  


Last Version -
(Note: changeover from CVS to dotless svn version numbers on Jan 19, 2008, and changeover to GIT versioning on May 30, 2013.)
Maintained by Jaap-Henk Hoepman
Email: jhh@cs.ru.nl