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﮳talleerd.
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://infoworld.com/articles/hn/xml/01/03/22/010322hnmicroversign.xml;
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.
