Open source software: bron van vertrouwen?

Jaap-Henk Hoepman en Bart Jacobs

Open source-software kan niet alleen leiden tot minder kosten, maar ook tot meer veiligheid en vertrouwen, menen Jaap-Henk Hoepman en Bart Jacobs. Zij gaan in op de voors en tegens van open source-software voor kritische programmatuur. 'Er is terecht sprake van zorg over het gebrek aan openheid over software, die om een zorgvuldige discussie vraagt.'

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?

Deze kwestie is bedoeld als analogie. De opgevoerde pillen kunnen vergeleken worden met computerprogrammatuur (software), waarvan de samenstelling (de broncode) niet bekend is. Het gebruik van deze pillen/software kan ingrijpende gevolgen hebben en kan uw 'systeem' diepgaand beïnvloeden. Daarom zoekt u een basis voor vertrouwen. Duidelijkheid over de precieze samenstelling zou die basis kunnen vormen, tenminste ingeval u voldoende onderlegd bent om die te kunnen interpreteren en beoordelen. Ook zou u tevreden kunnen zijn wanneer u de fabrikant kent en vertrouwt of wanneer u zeker weet dat een deskundige en onafhankelijke keuringsinstantie de pillen (en de bijsluiter) beoordeeld heeft.

Zoals iedere vergelijking gaat ook de bovenstaande maar in beperkte mate op. Zo worden pillen vooral ingenomen in ongebruikelijke situaties, namelijk bij ziektes, om de normale stand van zaken te herstellen. Computerprogramma's daarentegen worden in principe in normale situaties geïnstalleerd. En 'bijsluiters' zijn niet standaard bij software. Hooguit enige documentatie, waarin vaak vooral het gebruik en niet zozeer de samenstelling wordt uitgelegd. De belangrijkste vraag in de vergelijking wordt hierdoor echter niet aangetast: hoe kunnen wij software vertrouwen waarvan de source-code (broncode) niet bekend is?

Open versus gesloten

Veel commerciële softwareproducenten verkopen hun programmatuur niet als open source-code, maar als zogenaamde gesloten, executeerbare code, die door compilatie uit de broncode verkregen wordt. De technische details worden in het kader 'Open standaards en open source' uitgelegd. Deze executeerbare Open standaards en open source
 
Open source-software wordt vaak in één adem genoemd met open standaards. Het gaat hier echter om twee verschillende zaken. Standaards zijn in het algemeen belangrijk om uitwisseling en communicatie te vergemakkelijken. Er zijn bijvoorbeeld standaardmaten voor schroeven en moeren. Hierdoor is het duidelijk wat voor gereedschap (zoals moersleutels) nodig is. Verschillende partijen kunnen eigen implementaties van de standaard produceren, waardoor er keuzevrijheid is en bijbehorende marktwerking. Monopolievorming wordt voorkomen. code bestaat uit machine-instructies op zeer laag niveau en is voor mensen zeer moeilijk te begrijpen. De broncode daarentegen is voor informatici redelijk begrijpelijk. Deze code is intellectueel eigendom van de producent en wordt dus vaak om concurrentieredenen niet vrijgegeven. Immers, indien de broncode beschikbaar is zou de concurrent daar goede ideeën uit kunnen opdoen, of zelfs cruciale delen eruit kunnen kopiëren om voor eigen voordeel aan te wenden. Dat laatste zou trouwens wel een overtreding van de auteurswet vormen. Een mogelijk betere bescherming van software wordt geboden door octrooien, waardoor eventuele openbaarmaking niet schadelijk hoeft te zijn.

In het Engels spreekt men van proprietary-software wanneer toestemming nodig is voor gebruik, verspreiding of aanpassing. Hier zullen we dat software 'in eigendom' noemen, met 'vrije' software als tegengestelde. In theorie is het mogelijk dat open source-software in eigendom is, maar in de praktijk komt dat niet vaak voor. Open source-programmatuur is meestal vrij. Open source betekent echter niet noodzakelijk gratis. We zullen een aantal mogelijke combinaties bekijken en twee bekende voorbeelden noemen. Het besturingssysteem Linux is open source, vrij en gratis, maar Microsofts Windows is gesloten source, dus in eigendom, en daarvoor moet de gebruiker betalen.¹

Op de meeste computers 'draait' software van Microsoft, bijvoorbeeld in de vorm van het besturingssysteem Windows, de tekstverwerker Word of de webbrowser Internet Explorer. Zoals vermeld is deze software niet open source. Er is in grote lijnen bekend wat deze software doet, maar de precieze samenstelling is onbekend. Het is onwaarschijnlijk, maar het zou bijvoorbeeld kunnen dat er in deze software 'achterdeurtjes' ingebouwd zijn waardoor Amerikaanse spionagediensten mee kunnen kijken bij willekeurige gebruikers. Dit is nooit aangetoond en wordt hier enkel als mogelijkheid genoemd om de implicaties van dit gebrek aan transparantie duidelijk te maken.

Velen van ons, individueel en collectief, zijn sterk afhankelijk geworden van systemen waarvan wij de precieze werking niet kennen. Voor de meeste huis-, tuin- en keukentoepassingen maakt dit ook niet zo veel uit, maar voor andere toepassingen, bijvoorbeeld in het bestuur van landen of ondernemingen, is dit toch verontrustend. Kunnen wij bijvoorbeeld zeker zijn van de juistheid van de uitslag - en van de vertrouwelijkheid van onze stemmen - bij elektronische verkiezingen die door gesloten broncode gereguleerd worden? Kunnen internationaal opererende bedrijven erop Broncode en compilatie
 
Een computerprogramma is een lijst van instructies die een computer vertelt wat te doen. Deze instructies moeten voor een computer begrijpelijk zijn en dus uiteindelijk uit slechts nullen en enen bestaan. Mensen zien liever instructies op een hoger abstractieniveau. De zogenaamde broncode van programmeertalen bestaat uit zulk abstractere instructies, van de vorm 'if [...] then [...] else [...]' of 'while [...] do [...]'. Een compiler is een speciaal computerprogramma (een 'meta'-programma) dat zulke broncode vertaalt naar zogenaamde executeerbare code (nullen en enen) die de computer direct begrijpt. De bekende .exe-files zijn het resultaat van zo'n compilatie. vertrouwen dat er geen economische spionage plaatsvindt via oneigenlijke toegang tot de door hen gebruikte computersystemen?

Gedurende de laatste jaren zijn steeds meer overheden (op allerlei niveaus), bedrijven en particulieren ontevreden geraakt over het hierboven geschetste gebrek aan openheid. Zo heeft het Nederlandse parlement ongeveer een jaar geleden, op 20 november 2002, de motie-'Vendrik' aangenomen waarin de overheid wordt opgeroepen het gebruik en de verspreiding van open source-software en open standaards in de publieke sector actief te stimuleren. Dit heeft geleid tot www.ososs.nl. Dezelfde ontwikkelingen spelen internationaal, bijvoorbeeld in de stad München, waar het gemeentebestuur besloten heeft geheel over te stappen op open source, en in vele andere landen, ook in de Derde Wereld.

Hier is terecht sprake van zorg, die om een zorgvuldige discussie vraagt. Immers, het gaat om de inrichting van de ict-infrastructuur waar iedereen in steeds sterkere en indringendere mate van afhankelijk wordt. De materie wordt vaak toegespitst op een Linux-Windowscontroverse, waardoor de relevante onderwerpen niet optimaal, en vaak emotioneel beladen, in beeld komen. In dit stuk zoeken we een breder verband. We zullen in een apart kader ingaan op het relatief oncontroversiële punt van open standaards en in de tekst hieronder open source nader bespreken. We zullen daarbij eerst economische argumenten onderscheiden en daarna dieper ingaan op de beveiligingsaspecten van open source - aansluitend bij onze expertise.

Economische motieven

Wanneer software eenmaal als open source beschikbaar is, is het moeilijk, ondanks eventuele auteursrechtelijke claims, gebruik en aanpassingen door anderen te voorkomen. Veel open source-software wordt daarom gratis ter beschikking gesteld. De zogenaamde GNU public license (zie www.gnu.org) waaronder veel vrije software wordt verspreid, bevat zelfs de principiële eis dat alle aanpassingen en uitbreidingen ook open source moeten zijn. Desondanks is er geld te verdienen met zulke programmatuur, bijvoorbeeld via betaalde ontwikkeling, ondersteuning en onderhoud. Inderdaad zijn er verschillende bedrijven op dit gebied actief.

Voor gebruikers heeft vrije software dus als eerste economische voordeel dat er veel gratis beschikbaar is. Om te beginnen zijn er natuurlijk de besturingssystemen zoals Linux en Free BSD, maar daarbovenop ook veel applicatieprogramma's voor velerlei toepassingen (e-mail, webbrowsing, editing, databases, firewalls etcetera). Echter, zoals gebruikelijk, kosten de installatie, configuratie en het onderhoud wél tijd en geld. Of dat al dan niet goedkoper is dan bij proprietary-software hangt af van de beschikbare eigen expertise.

Een volgend voordeel is de onafhankelijkheid van softwareproducenten. Wanneer de broncode voor de klant beschikbaar is, kan deze op ieder moment naar een nieuwe ontwikkelaar gebracht worden om het werk of onderhoud voort te zetten.

Tenslotte kan vrije software makkelijk aangepast en hergebruikt worden, waardoor op ontwikkelkosten bespaard kan worden.

Tegenover deze voordelen staan de (eenmalige) kosten die gepaard gaan met een eventuele overstap. Hierbij gaat het vooral om omscholing en mogelijk om ontwikkeling van nieuwe software. De praktijk lijkt aan te geven dat een geleidelijke overgang naar open source verstandig is, om een organisatie te laten wennen aan nieuwe programmatuur. Dit wordt nu bijvoorbeeld bij de gemeente Amsterdam in de praktijk geprobeerd.

Beveiligingsaspecten

In de wereld van beveiliging is openheid een controversieel onderwerp. Is het bijvoorbeeld beter wanneer een slotenmaker de bouw en werking van zijn sloten geheimhoudt, of wanneer hij die juist openlijk bekendmaakt? Geslotenheid heeft als voordeel dat een inbreker niet gemakkelijk aan informatie over de werking van het slot kan komen. Het idee achter openheid is dat de kwaliteit van de sloten af moet hangen van de kwaliteit van de sleutel (bijvoorbeeld aantal gleufjes) en niet van obscuriteit. Bij openheid kan iedereen in principe voor zichzelf beoordelen of het mechanisme goed gemaakt is en geen verborgen ingangen bevat. Dezelfde vragen spelen op het gebied van veiligheid van software. Ze zijn echter subtieler omdat software zeer complex is én er een duidelijker onderscheid is tussen ontwerp en implementatie.

Open source-software kan naar onze mening niet alleen tot minder kosten maar ook tot meer veiligheid² en vertrouwen leiden. We zullen hier nu nader op ingaan en de voors en tegens van open source-software voor kritische programmatuur de revue laten passeren. We beginnen met de vraag hoe de veiligheid van programma's door middel van openheid vergroot kan worden. Vervolgens bespreken we hoe het vertrouwen in systemen vergroot kan worden. We eindigen met een discussie over de (controversiële) rol van open source hierin.

Veiligheid

Het mag in eerste instantie vreemd lijken om de grootst mogelijke openheid na te streven bij de ontwikkeling van software (of meer in het algemeen willekeurige producten of systemen) 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 gebruikte mechanisme. Uit militair opzicht is dit natuurlijk erg belangrijk: het is immers niet te voorkomen dat bij een militair conflict enkele van dergelijke apparaten in handen van de vijand vallen. En je wilt niet dat dan alle overgebleven apparaten op stel en sprong vervangen moeten worden. 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 het geval van communicatieapparatuur bijvoorbeeld wordt dat gedaan door gebruik te maken van geheime communicatiesleutels die regelmatig gewisseld worden.

De ontwikkeling van mobiele telefoonnetwerken is in dit verband een interessant voorbeeld. De beveiliging van gsm (het tweede generatie mobiele netwerk) vond in het grootste geheim plaats. Daartoe ontwikkelde de ETSI SAGE (Security Algorithms Group of Experts) zelf nieuwe cryptografische protocollen. Na verloop van tijd echter lekten deze protocollen uit. Dat is ook niet zo verwonderlijk: alle fabrikanten van mobiele telefoons en/of sim-kaarten moesten op de hoogte zijn van deze protocollen. Niet lang na het openbaar worden van deze protocollen werden de eerste zwakheden gevonden. Inmiddels kan de beveiliging van gsm ternauwernood adequaat genoemd worden. Gelukkig hebben de telecomoperators uit deze ervaring lering getrokken. De beveiliging van umts (het derde generatie mobiele netwerk) wordt gebaseerd op bestaande cryptografische protocollen en vindt bovendien plaats in alle openheid.

Merk op dat openheid van het ontwerp an sich de veiligheid verlaagt. Echter, omdat de ontwerpers ervan uitgaan dat het ontwerp openbaar zal zijn, zullen ze een systeem moeten ontwerpen dat veiliger is dan een systeem waarbij ze daar niet van uitgaan. Het gaat dus om de ontwikkelmethode die vanwege de openheid gevolgd wordt.

Openbaar maken van het ontwerp heeft nog een voordeel: het stelt iedereen in staat om zijn eigen oordeel te vellen over de veiligheid van het ontwerp en om eventuele verbeteringen te suggereren. Dit is een leidend principe in modern beveiligingsonderzoek. Het mooiste voorbeeld hiervan is wel hoe het Amerikaanse National Institute of Standards and Technolgy de opvolger van DES, de Advanced Encryption Standard (AES) (zie ook kader 'Open standaards en open source'), selecteerde. AES kwam tot stand door een open competitie tussen verschillende teams van cryptografen die ieder een eigen systeem hadden ontwikkeld. Allen probeerden de zwakheden in de systemen van anderen aan te tonen en uit hun eigen systemen te verwijderen. AES zal in de toekomst voor een groot aantal kritische toepassingen (zoals in de bankwereld) gebruikt gaan worden.

Openheid zorgt er dus voor dat het ontwerp a priori veiliger is (omdat de ontwerpers ervan uit moeten gaan dat de aanvallers het ontwerp ook kennen) en ook makkelijker en sneller nog veiliger gemaakt kan worden (omdat een grote groep onafhankelijke experts verbeteringen kunnen suggereren).

Vertrouwen

Veiligheid alleen is niet voldoende. Belangrijk is ook dat anderen overtuigd zijn van de veiligheid van het systeem. Met andere woorden: dat men het systeem kan vertrouwen. Zoals al eerder genoemd, is dit van groot belang bij het gebruik van stemmachines voor elektronische verkiezingen.

Vertrouwen is een subjectieve maat. Het vertrouwen in een systeem kan op verschillende manieren verhoogd worden. Belangrijk is bijvoorbeeld dat het systeem er betrouwbaar 'uitziet'. Of dat het gemaakt is door een betrouwbare fabrikant. Goedkeuring door een bekende organisatie als de Consumentenbond of TNO helpt ook, evenals objectieve informatie over het systeem.

Goedkeuring wat betreft de veiligheid van een systeem kan verkregen worden door een zogenaamde evaluatie. Een bekende evaluatiemethodiek bij beveiliging is de Common Criteria-methode. Door een dergelijk keurmerk wordt het vertrouwen in een systeem hoger. Nog beter zou zijn als het evaluatierapport zelf ook openbaar is. Helaas is dat lang niet altijd het geval, zoals bij de evaluatie van de stemmachines. Immers, openbaarheid van het evaluatierapport stelt ook andere partijen in staat zich een oordeel over de evaluatie te vormen.

Tenslotte geldt natuurlijk dat alle objectieve informatie over het systeem van belang is voor het vormen van een oordeel over het systeem. Te denken valt dan, in de context van beveiliging, in ieder geval aan de volgende zaken (naast het evaluatierapport en het ontwerp zelf):

de security policy.

Deze geeft aan welke zaken beveiligd moeten worden, waarom deze beveiligd moeten worden, aan welke eisen de beveiliging moet voldoen en wat er gelogd moet worden;

de bedreigingsanalyse.

Hierin staat precies aangegeven welke aanvallen men verwacht, hoe waarschijnlijk men die acht en hoe groot de potentiële schade van zo'n aanval kan zijn.

Natuurlijk is het zo dat slechts een kleine groep mensen deze informatie kan beoordelen. Echter, het stelt ieder van deze personen in staat om zich een mening te vormen over de veiligheid van het systeem en deze mening met feiten te staven.

Openbaarheid van de source?

Over de noodzaak van openheid op ontwerpniveau is iedereen in de academische wereld en - in steeds grotere mate - ook het bedrijfsleven en zelfs de militaire wereld wel overtuigd. Dit geldt niet met betrekking tot de vraag of open source (en de daarbij horende ontwikkelmethode) tot veiligere en beter te vertrouwen systemen leidt.

Interessant om op te merken is dat, in de tijd van Kerckhoffs, er eigenlijk geen verschil bestond tussen ontwerp en implementatie: een fout in de ene correspondeerde een op een met een fout in de andere. Voor software is dit niet het geval (zie kader 'Broncode en compilatie' en 'Fouten in software'). Er is een groot verschil tussen het ontwerp (de specificatie) Fouten in software
 
Software wordt geschreven door programmeurs, wiens taak het is instructies voor computers op te stellen. Hierbij moet gedrag vooraf gepland worden. Het blijkt razend moeilijk te zijn en gebeurt eigenlijk nooit zonder fouten. Dit is een algemeen erkend probleem, waarmee velen van ons welbekend zijn (bijvoorbeeld in de vorm van blauwe schermen). Softwarebedrijven spenderen over het algemeen meer geld en moeite aan het testen van hun software dan aan het schrijven ervan. Ook is veel wetenschappelijk onderzoek erop gericht om fouten in software ofwel vooraf te voorkomen, ofwel achteraf te detecteren. Een deel van het probleem is dat het verre van eenvoudig is om in detail vast te leggen (te specificeren) wat goed en fout gedrag is. van een programma, de implementatie door source-code en de daarvan afgeleide executeerbare object-code. Op elk van deze niveaus kunnen fouten en of zwakheden worden geïntroduceerd. En vanwege de complexiteit van de huidige software is de kans op fouten, zelfs op ontwerpniveau, vele malen groter dan in de tijd van Kerckhoffs. De vraag is dus of Kerckhoffs' principe wel of niet van toepassing is op de source-code van een systeem.

Recentelijk leidde een onderzoek van een aantal academici naar de veiligheid van stemmachines van de Amerikaanse firma Diebold die bij verkiezingen in de VS waren gebruikt, tot grote commotie (zie http://avirubin.com/vote/). Door een vergissing van de firma zijn grote delen van de source-code van een stemmachine in de openbaarheid terechtgekomen. De veiligheid van deze stemmachines blijkt schokkend slecht te zijn. De onderzoekers concludeerden onder meer dat open source het ontwikkeltraject voor dit soort machines, en daarmee hun veiligheid, behoorlijk zou verbeteren. Met name omdat op die manier een grote groep wetenschappers en software engineers de source kunnen inspecteren.

Naast de genoemde voordelen van openheid van ontwerp zijn er nog een aantal specifieke voordelen van een open source-implementatie te noemen. Wanneer er een fout gevonden wordt in een closed source-softwareproduct, is men afhankelijk van de fabrikant om de fout te herstellen (het zogenaamde 'patchen'). Dit kan lang duren, en gebeurt soms helemaal niet. Het voordeel van open source is dat, mits men de nodige expertise zelf in huis heeft of kan inhuren, de fout meteen hersteld kan worden.

Bovendien zijn evaluaties volgens bijvoorbeeld de Common Criteria statisch: ze zeggen niets over de veiligheid van een volgende versie van een systeem en ook niets over de bescherming tegen een nieuwe klasse van aanvallen. Een simpele patch van een fout in een eenmaal gecertificeerd systeem maakt het certificaat al niet meer van toepassing en dus waardeloos. Als de source-code van zowel het systeem als de patch openbaar is, zouden de consequenties van de patch voor de veiligheid van het systeem ook zelf beoordeeld kunnen worden.

Ten derde: bij een open source-systeem kan iedereen zelf kan compileren, zelf op zoek kan gaan naar fouten en ook zelf patches hiervoor suggereren. Zeker voor veelgebruikte en kritische systemen is hiervoor een redelijk animo te verwachten (zie bijvoorbeeld OpenBSD). Met het juiste management kunnen hierdoor betrouwbare systemen ontstaan.

Algemeen worden er twee grote nadelen van open source genoemd. Allereerst is er geen enkele garantie dat gekwalificeerde mensen de open source ook inderdaad kritisch zullen bekijken. En al steekt men er nog zo veel energie in, in alle software blijven wel fouten zitten (zie kader 'Fouten in software'). Sommige van die fouten leiden direct tot zwakke plekken in de beveiliging. Daar waar men zelf alle zwakheden moet vinden en afdekken, hoeft een kwaadwillende er slechts één te vinden waarvan misbruik gemaakt kan worden. Dit is een ongelijke strijd.

Echter, gezien de bedroevende staat waarin de veiligheid van closed source-software zich op dit moment bevindt (wat aangetoond is door de genoemde zaak van de Diebold-stemmachines) en het gemak waarmee aanvallers hierin bugs kunnen vinden, zijn deze tegenargumenten naar onze mening minder sterk. Door het openbaar maken van de source krijgen de verdedigers een grotere kans dan nu om de veiligheid van de software beter in te schatten en om de belangrijkste bugs te vinden en eventueel te herstellen. Belangrijker nog, het dwingt de producenten (net als in het geval van het openbaar maken van het ontwerp) ertoe ontwikkelmethoden te gebruiken die programmeerfouten tot het uiterste helpen te voorkomen.

Kortom, naast economische motieven bestaan er naar onze mening ook goede beveiligingstechnische redenen om open source-software te gebruiken. Bovendien kan de openheid bijdragen tot meer vertrouwen in en efficiënter gebruik van software.

Als enig verdedigbaar excuus voor het gebruik van gesloten software voor beveiligingskritische toepassingen met een publieke taak zien wij de combinatie van zowel een open, goed gedocumenteerd ontwerp, security policy en bedreigingsanalyse, als een diepgaande evaluatie door een erkend, onafhankelijk instituut, resulterend in een publiekelijk beschikbaar evaluatierapport. Helaas komt deze combinatie, zover wij weten, tot nu toe niet voor.

Prof. Bart Jacobs is hoogleraar beveiliging en correctheid van programmatuur aan de Universiteit Nijmegen.
Dr. Jaap-Henk Hoepman is senior onderzoeker security en cryptografie, eveneens bij de Universiteit Nijmegen.

Dit artikel is verschenen in I&I, 21 (6), 2003, pp 12-19, Otto Cramwinckel Uitgever.  

---

1. De meeste mensen zijn gewend een computer te kopen waarbij Microsoft-software reeds geïnstalleerd is. De prijs voor deze software is daardoor niet duidelijk zichtbaar. Computers kunnen echter ook zonder die software, voor een lagere prijs, aangeschaft worden. Dit vergt mogelijk enig aandringen bij de fabrikant of winkelier.↩︎

2. We bedoelen hier veiligheid in de zin van beveiligd zijn, dus zoals in het Engelse begrip 'security' en niet in 'safety'.↩︎

---

Last Version - e1e3326.
(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