Frank Brokken
f.b.brokken@rc.rug.nl
Wie wel eens een psychologisch onderzoek heeft ondergaan kent vast wel van
die testjes waarin je wordt gevraagd aan te geven welk element 'niet in de rij
thuishoort'. Een eenvoudige: Welk element hoort niet thuis in de volgende rij:
1. a; 2. e; 3. k. Dat is natuurlijk eenvoudig: alleen 'k' is geen klinker, dus
die hoort niet thuis in de rij.
Moeilijker is: 1. American Express; 2. Master Card; 3. Visa. Hier hebben we
drie creditcards, alle drie Amerikaanse firma's en alle drie redelijk veel in
gebruik. In zo'n situatie ga je zoeken naar een verschil. Bijvoorbeeld, Master
Card en Visa worden vaak beide geaccepteerd, waar American Express een iets
kleiner verspreidingsgebied lijkt te hebben. Maar dergelijke items moet je
eigenlijk altijd interpreteren in de context waarin ze worden aangeboden.
Wordt het daar makkelijker van? De context van deze column is 'security'.
Welke creditcard valt er dan buiten? Ik stel het antwoord op die vraag nog
even uit.
Als de creditcards nou bankpassen zouden zijn geweest: in de Volkskrant van
maandag 2 juni 2002 stond het volgende kopje: 'Banken kennen nog geen regels
tegen pinfraude'. Waarna volgde:
"... een nieuwe vorm van pinpasfraude noopt consumenten tot
voorzichtigheid bij het geven van hun pinpas aan een winkelbediende...."
Het blijkt dat de 'bad guys' in staat zijn snel een kopietje van je bankpas te
maken. Daarna kijkt men af welke pincode je intypt en je bent de sigaar: je
rekening wordt geplunderd. Of moet je er maar op vertrouwen dat dat niet
gebeurt? 'Vertrouwen' is een glibberig begrip.
Pretty Good Privacy
Eerder is in Pictogram al aandacht geschonken aan het begrip 'vertrouwen'
bij het toepassen van 'Pretty Good Privacy' (PGP) om de authenticiteit van de
afzender van e-mail vast te kunnen stellen. Even samenvattend:
1. Alleen de eigenaar van een 'private PGP key' kan e-mail met die sleutel
signeren.
2. Een e-mail die gesigneerd is met een 'private PGP key' moet dus door de
eigenaar ervan zijn verstuurd.
Er zijn twee manieren om de authenticiteit van een PGP-gesigneerde e-mail
na te gaan:
a. Je kent de afzender persoonlijk, en hebt zijn/haar 'public key' persoonlijk
van hem/haar gekregen.
b. (Nu komt het) je vertrouwt een tussenpersoon. De tussenpersoon dient
dan te hebben gecontroleerd of een public key ook feitelijk bij een bepaalde
persoon hoort.
Als je de afzender dan al niet persoonlijk kent, dan moet er toch op
z'n minst een vertrouwensbasis zijn tussen jou en de tussenpersoon.
Binnen de RUG is Frans Velthuis (f.j.velthuis@rc.rug.nl) de Certificate
Authority van de RUG voor het signeren van de public PGP-keys van haar
medewerkers: wanneer Frans een public PGP-key signeert mag je aannemen dat hij
gecontroleerd heeft dat de relatie tussen een public key en diens eigenaar ook
feitelijk bestaat.
Tot zover gaat het vertrouwen. Het heeft dus niks te maken met de inhoud
van de PGP-gesigneerde e-mail die we vervolgens ontvangen. Daar kan nog steeds
de grootste onzin in staan.
Nu gaan we een stapje terug, naar de creditcards. Welke creditcard hoort er
niet bij? Het antwoord is 'Master Card'. Dat is het goede antwoord in de
context van deze column over security, omdat Master Card geen Certificate
Authority is voor het signeren van webpagina's en de andere twee (American
Express en Visa) wel (zie figuren 1 en 2).
Certificate Authorities
Zowel Netscape als Internet Explorer komen met een groot aantal Certificate
Authorities die wij, gebruikers, kennelijk worden geacht te vertrouwen.
Binnen Internet Explorer komen die Certificate Authorities als volgt in beeld:
Extra -> Internet Opties -> Inhoud -> Certificaten ->Vertrouwde
rootcertificaat-autoriteiten.
Een voorbeeld van wat Internet Explorer dan zoal accepteert is te zien in
figuur 3.
Netscape biedt een vergelijkbare verzameling a-priori geaccepteerde
Certificate Authorities: Klik op het slotje links onder in Netscape en dan, in
het geopende security window op Signers (onder Certificates).
Van de lijst die dan zichtbaar wordt weet Netscape mij te vertellen dat dat
Certficate Authorities zijn die ik accepteer.
Vergelijkbaar met de 'vertrouwde rootcertificaat-autoriteiten' van Internet
Explorer zijn dit organisaties die websites kunnen certificeren. Pagina's die
van dergelijke websites worden gedownload worden zonder verdere controle of
waarschuwing aan de gebruiker door de webbrowser geaccepteerd.
Dat lijkt op het vertrouwen dat wordt gesteld in de tussenpersoon
bij PGP's gesigneerde 'public keys'. Maar de zaak ligt hier iets anders: de
rootcertificaat-autoriteiten zijn firma's, en zijn (voor mij althans) geen
vertrouwde tussenpersonen. Deze firma's certificeren een website voor een
bepaald bedrag en zolang de vergoeding wordt betaald, wordt uw website door
hen gecertificeerd.
Het kan anders: voor de RUG is Frans Velthuis ook de Certificate Authority
voor het signeren van RUG-websites. Net zoals hij dat bij PGP-sleutels doet,
controleert hij ook bij te signeren webcertificaten de authenticiteit van de
eigenaar. Maar de eerder genoemde firma's doen dat niet altijd. Voor hen
geldt: signeren is betalen. Dat kan tot onplezierige consequenties leiden.
In de Volkskrant van dinsdag 11 juni 2002 wordt Richard Purcell, corporate
privacy officer van Microsoft aan het woord gelaten. Purcell heeft een
belangrijke rol in Microsoft's trustworthy computing campagne, die tot
doel heeft de software van Microsoft veiliger te maken. Maar volgens hetzelfde
artikel ontdekken hackers nog vrijwel dagelijks fouten in de programma's van
Microsoft. Da's niet nieuw. Evenmin nieuw is dat er regelmatig patches
voor de geproduceerde software verschijnen. In hetzelfde artikel: "We
zullen tot aan het einde van dit jaar patches blijven uitbrengen om de
software te repareren". Gelukkig.
Die patches komen van websites van Microsoft. Tenminste, als het goed is. De
authenticiteit van die websites wordt gegarandeerd doordat een Certificate
Authority de desbetreffende website heeft gesigneerd. De patch kan worden
gedownload en geïnstalleerd.
Op 22 maart 2001 werd bekend dat VeriSign, een van de primaire firma's die
websites certificeert, zelf in de val was gelopen en een certificaat op naam
van Microsoft had uitgegeven aan iemand die zich voordeed als een medewerker
van Microsoft. Zie ook:
http://www.internetnews.com/dev-news/article/0,,10_721571,00.html
http://www.cert.org/advisories/CA-2001-04.html.
Zoals vermeld in het bewuste artikel, kon deze persoon vervolgens software
(patches) verspreiden op naam
van Microsoft zelf.
Point of no return
Doordat de webbrowser de website waarvan de software kan worden gedownload
als authentiek beschouwt (want gesigneerd door VeriSign), zal de webbrowser
verdere waarschuwingen achterwege laten. De nu nietsvermoedende gebruiker zal
de software dan ook waarschijnlijk zonder meer installeren.
Nu is het installeren van software een handeling waarbij de gebruiker
(meestal) nog zelf een laatste stap moet ondernemen, maar de gebruiker is op
dit moment vermoedelijk al voorbij een point of no return: de
informatie is immers al gegeven dat het nodig is om software te downloaden, en
de webbrowser opent geen waarschuwingsschermen meer waarin staat dat er
software wordt gedownload van een niet-vertrouwde website.
Maar ook zonder dat software expliciet wordt gedownload: sommige webpagina's
bevatten zelf korte programma's (Java Applets). Gewoonlijk zijn deze applets
in hun mogelijkheden sterk beperkt. Die beperkingen kunnen worden opgeheven
doordat middels een certificaat wordt aangegeven dat het desbetreffende
programma kan worden vertrouwd, en bijvoorbeeld toegang kan krijgen tot de
bestanden op de lokale harddisk. Ook hiervoor geldt (zie bijvoorbeeld het
hierboven genoemde Microsoft root-certificaat in Internet Explorer (figuur
fig_3.jpg)) dat Certificate Authorities dergelijke programma's kunnen
certificeren.
Inmiddels heb ik zelf bepaald welke Certificate Authorities ik in mijn
Netscape en Internet Explorer wens te accepteren: de lijst van Certificate
Authorities kan door de gebruiker zelf worden ingekort of uitgebreid. Ik raad
iedereen aan die lijst eens langs te lopen om zo zelf te bepalen welke
organisaties als autoriteit al dan niet zouden moeten worden geaccepteerd. Het
vervelende is alleen dat bij elke nieuwe versie van de webbrowser een verse
lijst van Certificate Authorities wordt meegeleverd waarvan Netscape of
Microsoft vindt dat ik die accepteer.
Maar wellicht kan deze service binnen de RUG eenvoudig door de ICT-afdelingen
worden gegeven? Het moet een kleine moeite zijn om de Internet Explorers en
Netscapes die via servers van de RUG beschikbaar worden gesteld te voorzien
van een opgeschoonde lijst van Certificate Authorities. Dan daar meteen het
root-certificaat van de RUG zelf aan worden toegevoegd. Van Frans weten we
tenminste dat hij feitelijk controleert wat de identiteit van een webmaster
is.
