Heeft het CA model zijn langste tijd gehad?

Update 13 – Actueel-DigiD – herfst 2011

Ik denk niet dat het iemand ontgaan zal zijn, maar ik wil toch even stilstaan bij een recente gebeurtenis die wereldwijd een ware tsunami heeft verspreid over het internet. Een schokgolf ondertussen die nog steeds niet helemaal lijkt uitgedoofd. Wat kunnen we leren van diginotar?

Wat is er eigenlijk gebeurd? De feiten zoals die er nu liggen, geven aan dat initieel een relatief kleine Nederlandse Certificate Authority (hierna CA te noemen) het slachtoffer is geworden van een digitale inbraak, waarbij de misdadigers zodanig toegang hebben kunnen verkrijgen tot de systemen dat deze persoon of personen zelf willekeurige certificaten konden laten ondertekenen door Diginotar. Deze werden daarna door alle bekende browsers als valide gezien. Hierdoor werd het potentieel mogelijk om, indien verkeer van en naar de werkelijke server kon worden omgeleid via een tussenliggend systeem (een zogenaamde proxy), beveiligd verkeer af te luisteren en/of te wijzigen. Nader onderzoek heeft uitgewezen dat deze valse certificaten uiteindelijk gebruikt zijn tegen Iraanse onderdanen. Niets wijst erop dat Nederlandse internetgebruikers slachtoffer zijn geworden van dit misbruik. Bijkomend saillant detail is dat Diginotar de betreffende inbraak, nadat deze is opgemerkt, nog enige tijd geheim heeft getracht te houden.

Diginotar

Deze opeenstapeling van blunders heeft er natuurlijk voor gezorgd dat het vertrouwen in deze CA aanzienlijke schade heeft opgelopen, en er gaan op het moment van schrijven al stemmen op om na te gaan of Diginotar hiervoor verantwoordelijk kan worden gesteld. Iets dat uiteindelijk kan leiden tot aanzienlijke claims, aangezien alle klanten (bedrijfsleven en overheid) van dit bedrijf nu op korte termijn al hun certificaten hebben moeten wijzigen om het vertrouwen in de verschillende websites weer te herstellen.

Naast dit incident is ondertussen ook duidelijk geworden dat GlobalSign (de op 4 na grootste CA) ook het slachtoffer is geworden van dezelfde criminelen en dat deze persoon of personen ook verantwoordelijk zijn geweest voor de problemen van Comodo (de nummer 2 CA) begin dit jaar.

Goede beveiliging is niet iets dat je nadien aan een product kunt toevoegen
Laksheid
Wat ik met dit artikel wil bereiken, is niet een volledige analyse van hetgeen heeft plaatsgevonden; daar is al een rapport over in de openbaarheid gebracht. Ik wil hier juist inzoomen op twee aspecten die me zijn opgevallen. Allereerst de laksheid die schijnbaar heerst bij deze CA’s. Bij elk van deze organisaties hebben crackers toegang kunnen krijgen tot de belangrijkste systemen van de CA, maar is dit niet tijdig opgemerkt en zijn er ook onvoldoende snel mitigerende acties ondernomen om de geïdentificeerde problemen op te lossen. En dan heb ik het dus niet eens over proactieve acties die, zeker door dergelijke organisaties wiens product feitelijk alleen uit vertrouwen bestaat, noodzakelijk zijn om een organisatie voldoende veilig te houden.

We zien in alle gevallen dat er op papier wellicht wel het een en ander wordt gedaan aan informatiebeveiliging, maar dat het proces absoluut onvoldoende blijkt om de veiligheid van de belangrijkste systemen in voldoende mate te garanderen. Het heeft er alle schijn van dat informatiebeveiliging ook niet als een proces is ondergebracht in de organisatie, maar dat het een regelmatig terugkerend project was dat erop was gericht om aan de wensen en eisen van een auditpartij te voldoen. Een instelling die niet kan werken.

Informatiebeveiliging is noodzaak
De eerste les die hieruit geleerd moet worden is dat informatiebeveiliging tegenwoordig een noodzaak is en procesmatig in en door een organisatie moet zijn belegd. Daarnaast kan het niet zo zijn dat dergelijke incidenten waarbij vertrouwelijke informatie die voor gebruikers van cruciaal belang is, zo lang onder de pet wordt gehouden. Ik ben dan ook een groot voorstander van het instellen van een meldplicht waardoor deze misstanden aangepakt kunnen worden.

En dan het CA model. Is dat nog wel van deze tijd? Ook hierop moet ik denk ik negatief antwoorden. Sterker nog het hele model is al vanaf het begin wankel. Laat me dat eens verduidelijken. Het model is erop gebaseerd dat je bij een centrale autoriteit gaat vragen of je een bepaald systeem waar je mee wilt gaan communiceren wel kunt vertrouwen. Je legt jouw vertrouwen dus volledig in handen van een of ander bedrijf dat je verder ook niet kent en gaat er dan maar van uit dat alles wat ze je voorschotelt klopt. Zeg nu zelf, als je dit leest dan voelt dat op zijn minst vreemd. Of zou je dit in het werkelijke leven ook zo doen? Je wilt iets kopen bij een winkel in een onbekende stad en belt even met een voor jouw onbekende organisatie (zeg de KvK in het land waar je je bevindt) om je te vertellen of je het betreffende bedrijf wel kunt vertrouwen. Op zich lijkt het me dan ook niet verwonderlijk als uit onderzoek is gebleken dat het gehele autorisatiemodel dat in X.509 is ondergebracht een beetje als een afterthought is toegevoegd. Initieel ging het eigenlijk alleen om het beveiligen van de onderlinge communicatie door middel van SSL. Dat het wellicht ook handig zou zijn om na te kunnen gaan dat je ook werkelijk met de juiste andere partij sprak was iets dat daarna pas als een goed idee werd toegevoegd. En zoals elke beveiligingsexpert je zal vertellen: “Goede beveiliging is niet iets dat je nadien aan een product kunt toevoegen.”

Vertrouwen bij de cliënt leggen
Hoe zou het dan wel kunnen werken? Allereerst denk ik dat het vertrouwen weer neergelegd moet worden bij de persoon die dat het beste kan beoordelen en dat is de cliënt zelf. Nu kun je daar natuurlijk tegen inbrengen dat de gemiddelde gebruiker toch zal blijven klikken op elke (fout)melding die getoond wordt zonder deze te lezen, zolang de achterliggende pagina maar geladen kan worden, maar ook het huidige model staat dit toe en het betreft hier denk ik ook niet de gebruiker die we willen en moeten beschermen. Er is nu eenmaal geen mogelijkheid om tegen domheid te beschermen. Een systeem dat nu in bèta is en juist de nadruk legt om het vertrouwen weer terug te leggen bij de gebruiker, en dit proces zodanig inricht dat het naadloos kan aansluiten bij de huidige structuur (dus met gebruik van CA’s), is Convergence (http://convergence.io/). Door het op de juiste wijze gebruiken van, over het internet verspreide notaries kunnen de browsers die hiervan gebruik maken, van verschillende partijen en via verschillende paden over het internet opgehaalde, certificaten verzamelen en met elkaar vergelijken. Op basis van gebruikersinstellingen kan dan het certificaat vertrouwd worden als dit van een of meer notaries overeenkomt met het certificaat dat vanaf het systeem zelf is verkregen. Pas als dat vertrouwen er is zal de browser een beveiligde verbinding opzetten, waarna de overige communicatie kan plaatsvinden. Naast het feit dat dit systeem een toevoeging is aan het huidige model, zal dit systeem ook werken met zogenaamde self-
signed certificaten. Hierdoor zou uiteindelijk het huidige model waarbij CA’s erg veel macht in handen hebben gekregen geheel of gedeeltelijk kunnen worden afgebroken.

Hans (J.C.G.) Van de Looy, partner, principal Security Consultant


@Secura 2017
Disclaimer  /  Privacy policy  /  Sitemap / Inloggen
Webdesign Studio HB / webdevelopment Medusa