image

Column: De implosie van PKI

dinsdag 13 september 2011, 10:21 door Peter Rietveld, 12 reacties

Dinsdag aanstaande zal patch Tuesday van Microsoft de laatste Diginotar-certificaten opruimen. De Nederlandse overheid is zeker dat haar systemen daar inmiddels klaar voor zijn en dat ze een meltdown afgewend hebben, na een hele drukke week voor de beheerders. We gaan het meemaken.

Het bericht maakt duidelijk dat de systeemcrisis van Diginotar vrijwel voorbij is. De vertrouwenscrisis echter, die woekert voort. En terecht, want er is veel meer aan de hand.

Voor de meeste mensen is de PKI-crisis net zoiets als wat ooit de Y2K-crisis was: iets ongrijpbaars met computers en het is allemaal heel gevaarlijk. Deze vertrouwenscrisis gaat heel diep. En niet zo verwonderlijk, gegeven de voorgeschiedenis; eerder zouden de OV-chipkaart en het EPD ook heel veilig zijn en bleken dat uiteindelijk toch niet. Veel mensen stellen de overheid per definitie gelijk aan mislukte ICT. Dat is dan wel weer heel kort door de bocht. We zien nu dat de overheid onderhand beter wordt in dit soort situaties; Donner heeft het keurig gedaan, toen de crisis eenmaal de aandacht van de top in Den Haag had.

Helemaal onder controle is het probleem met de ‘comodohacker’ voorlopig nog niet. Zaterdagochtend meldde Globalsign dat er daadwerkelijk één van haar systemen gekraakt is. Maar, luidt het persbericht, het gaat alleen om de webserver, de PKI-servers in het netwerk zouden niet getroffen zijn. Nu ja, we zullen zien. Hoewel de zaak onderzocht is door specialisten moeten we niet vergeten dat zelfs FOX-IT niet onfeilbaar is. Daarbij; met drie succesvolle hacks (Comodo, StartSSL en Diginotar) en mogelijk een vierde in vier maanden tijd, is het patroon gevestigd en de aanvaller niet gegrepen. Er komen er vast nog meer.

De huidige vertrouwenscrisis zal overigens nog veel dieper gaan. Niet omdat burgers nog niet gerustgesteld zijn, maar omdat de IT-sector zelf de schade begint te ontdekken. En dat sijpelt vanzelf door: met een paar honderdduizend IT-ers kent iedere burger er wel een paar. En de burgers zijn erg ontvankelijk voor horrorverhalen over onveilige technologie.

Hoe dat zo? Vanwege Diginotar en Globalsign zijn grote organisaties begonnen met het in kaart brengen van hun afhankelijkheden van certificaten. En wat blijkt: er zit nog veel meer poep op de ventilator. Het dossier PKI bevat nog een paar nare verrassingen. Ten eerste blijkt het zeer lastig om alle certificaten te vinden. Het is uitgesloten dat je de boel veilig kunt houden als je niet weet wat je gebruikt en waar het zit. Ten tweede is het vervangen heel veel werk waar je alleen in echte noodsituaties toestemming voor krijgt. Oftewel: de gewone IT-beheerder voelt wel aan dat wat we nu meemaken een eenmalige exercitie is, terwijl een structurele oplossing geboden is.

Maar de derde bevinding is de belangrijkste: veel beveiligingsfuncties van certificaten worden helemaal niet gebruikt. Wat zeg u? Ja, zij zijn niet in gebruik.

Ten koste van de beveiliging
In feite is een certificaat een digitale sleutel, die door een slot – een samenwerking tussen de server, de client en de PKI-infrastructuur – op echtheid gecontroleerd wordt. En waar lopen de controleurs nu tegenaan?

De controles die ‘het slot’ kan doen, staan vaak uit. Zo zie je dat sleutels die al lang verlopen zijn of ingetrokken zijn, nog steeds werken. De voorgespiegelde meltdown van overheidssystemen die nu voorkomen zou zijn, lijkt met dit in gedachten dan ook wat overtrokken. De verklaring van waarom de controles uit staan is simpel, omdat het intrekmechanisme, CRL of OCSP, niet werkt of botweg uitgeschakeld is.

De verklaring voor het niet werken is eenvoudig: de machine moet zelf een verbinding met internet kunnen opbouwen. Bij webservers is dat vanzelf geregeld, maar bij Server Oriented Architectures (SOA’s) en infrastructurele voorzieningen als proxies, federatieservers en loadbalancers wil je helemaal niet dat de machines naar ‘buiten’ kunnen. Het PKI-mechanisme voorziet hier niet in; het huidige PKI is voor dit soort systemen feitelijk ongeschikt. Toen PKI nieuw was, bestonden load balancers, proxies en SOA’s nog niet, maar nu heeft iedere organisatie wel wat van die spullen in huis.

De verklaring voor het uitschakelen ligt in het verlengde van het voorgaande. Als een PKI-implementatie de controles van echtheid daadwerkelijk uitvoert, dan zal het systeem niet werken. Daarom worden de beveiligingsfuncties uitgeschakeld, anders werkt het systeem niet. Dat de beveiliging dan ook niet werkt, is veel mensen niet duidelijk of is onder tijdsdruk genegeerd. Het werkt, en daar gaat het om. Alleen, ten koste van de beveiliging.

Dat het PKI-echtheidsmechanisme niet bruikbaar is, wordt onderstreept door Google en Microsoft die eigen, hard-coded mechanismen gebruiken in plaats van het officiële om certificaten in te trekken. Dat maakt overigens de root-certificaten van Microsoft en Google de belangrijkste digitale bestanden ter wereld; als daar wat mee mis gaat is er geen herstel mogelijk. Zowaar geen fijn idee.

Er zijn nog meer toepassingen met PKI die op voorhand niet voorzien zijn, of niet voldoende doorzien. Daarbij gaat het vooral om ingebedde certificaten. Zo zijn er in smartcards en allerlei andere hardware devices certificaten en de bijbehorende algoritmes ingebouwd. Nu kunnen de certificaten in veel gevallen wel vervangen worden, met heel veel moeite, maar de toepassing eromheen (zoals in de chip van de smartcard) is vaak hardcoded. Dan zit er niets anders op dan alle kaarten te vervangen. Je begrijpt dat dat niet snel zal gebeuren – vergelijk maar met de gekraakte crypto in de OV-chipkaart. Hebben we al nieuwe? Nee, natuurlijk niet, dat is een hele grote operatie.

Als laatste lopen we nu aan tegen een massale inzet van self-signed certificaten. In een aantal gevallen is dat op zichzelf prima te rechtvaardigen – mits het beheer geregeld is, maar bij de meeste organisaties is dit een hele nare verrassing. Het beheer is namelijk niet geregeld en de chaos is compleet.

Zelfregulering
De wereld van PKI is opgebouwd uit enkele honderden organisaties die in meer of mindere mate onder toezichthouders vallen. In ons land valt het toezicht blijkbaar toe aan de OPTA, die dat weer gedelegeerd heeft aan de markt. Omdat het toezicht per land anders is en PKI internationaal, is het PKI-bouwwerk vooral afhankelijk van zelfregulering door de verschillende deelnemende commerciële ondernemingen. De gedachte onder deze zelfregulering is dat de RootCA’s wel gek zouden zijn als ze hun zakies lieten versloffen, omdat ze anders hun klanten zouden verliezen. Dat dit geen werkende garantie is, is nu door Diginotar overduidelijk aangetoond; sommige RootCA’s zijn gek. Het was ook een onjuiste aanname: een falende RootCA wordt niet gecorrigeerd door haar eigen klanten, want die zien het probleem in de praktijk niet. En de falende CA wordt niet gecorrigeerd door de concurrentie, want, eh, dat is de concurrentie. In het Diginotar-geval is de falende CA gecorrigeerd door de grote browserbouwers en die nemen nu het voortouw, maar de bron van het falen blijft.

Backwards compatibility
Cryptografie is per definitie (vanwege de wet van Moore) gevoelig voor veroudering. Bovendien bestaan er geen onfeilbare algoritmes. Bovenal omdat software niet werkt met theoretische algoritmes, maar met feitelijke implementaties. Daarom moeten sleutellengtes en gebruikte technieken met enige regelmaat, maar soms per direct aangepast worden. Dit is vanaf het allereerste begin van PKI een vereiste geweest en staat te lezen in alle leerboeken. Bij de huidige inspectie blijkt dat te kleine sleutels en sleutels die gebruik maken van technologie die al lang in de ban is gedaan, nog steeds in gebruik zijn. En de reden die vermeld wordt is backwards compatibility. Het systeem ondersteunt vanwege backwards compatability ook sleutels die niet meer zouden mogen werken. Oftewel: het werkt maar ten koste van de beveiliging.

Zo zouden CA’s onderhand geen intermediate en end-entity certificaten met RSA key size kleiner dan 2048 bits moeten uitgeven. Bovendien zouden CA’s met root certificates kleiner dan 2048 bits RSA key zelf moeten stoppen met het uitgeven van intermediate and end-entity certificates van deze roots. De meesten hebben dat wel meegekregen. Maar ernaar gehandeld hebben ze zeker niet allemaal. En wat gebeurt er dan? Inderdaad: helemaal niets.

Daar zijn nog ergere voorbeelden van: eind 2008 is een zeer gedetailleerde en zeer dodelijke aanval op PKI gepubliceerd, die gebruik maakte van collissions in MD5. Het blijkt nu dat er, ruim drie jaar later, nog steeds certificaten met MD5 in gebruik zijn. Als je kijkt welke certificaten op je machine staan, zul je meerdere root certificaten met MD5-RSA tegenkomen , zoals de "Thawte Premium Server CA" uit 1996: deze zouden geen probleem moeten zijn omdat ze uitgegeven zijn voordat MD5 gekraakt is. De gedachte is dat als deze gekraakt zouden zijn, dat dan wel bekend zou zijn geworden. Wellicht is dat zo.

Waar je voor moet oppassen zijn nieuwere certificaten met MD5. Niemand moet die accepteren, bij wijze van zelfreinigend vermogen. Maar dat vermogen ontbreekt ten ene male – want wie inspecteert nu ieder certificaat en weet wat al die waardes betekenen? Bovendien kun je dit als gebruiker helemaal niet: je browser of je besturingssysteem accepteert namens jou.

Ook hebben we een probleem gehad met debian OpenSSL: alle RSA & DSA keypairs die met OpenSSL op debian zijn gemaakt tussen de release van 17 september 2006 en de update van 13 mei 2008 zijn eenvoudig te raden. Zijn de certificaten met deze keypairs allemaal weggegooid? Waarom zouden ze? En voor de gebruiker: hoe kun je zien hoe waarmee en op welk platform een certificaat gemaakt is? Dat kun je niet.

Gelukkig is Mozilla recent gestopt met het accepteren van certificaten met MD5, maar andere browsers en zeker de oudere, accepteren ze nog gewoon. Als je vervolgens bedenkt dat de oudste browsers vooral bij de grootste organisaties voorkomen (Internet Explorer 5.5 en 6 komen nog steeds voor bij banken en de overheid) dan zou je je toch zorgen kunnen gaan maken.

Al eerder is vastgesteld dat een ander essentieel mechanisme, de PathLenConstraint, door Diginotar niet gebruikt wordt. Nu we met z’n allen de boel eens goed bekijken, blijkt dat dit mechanisme hoogst zelden gebruikt wordt. Dit mechanisme zou ook de angel uit de MD5-aanval gehaald hebben, net als uit de Diginotar-hack. Maar gebruiken? In 2008 niet en in 2011 natuurlijk evenmin; want het beperkt de RootCA in de commerciële mogelijkheden. Als je de PathLenConstraint op 4 zet, wat een goede waarde zou zijn, kan niet iedere CA zomaar oneindig van alles uitgeven. Dan zouden de klanten duurder uit zijn en de winst van de CA’s dus uiteindelijk dalen.

Gegeven het voorgaande is duidelijk dat de sector alleen tandeloos intern toezicht heeft en zelfreinigend vermogen ontbeert om het vertrouwen dat ze opeist, te verdienen.

Extern toezicht
Nu is er niet alleen intern toezicht, maar ook extern. Het toezicht door PWC in opdracht van de OPTA blijkt alleen het management van de organisatie te toetsen en niemand heeft zich daar druk over gemaakt. Een staaltje zinloze bureaucratie zonder weerga.

Nogmaals dan: computerbeveiliging gaat over het beveiligen van computers, dat gaat over techniek en alleen indirect over procedures, processen en protocollen. Mensen die geen kennis hebben van de techniek van beveiliging kunnen geen goede beslissingen nemen over de beveiliging als geheel.

Naast deze feiten is er een aantal hardnekkige geruchten die ook al niet helpen. Zo wordt er openlijk gesteld dat Diginotar gestraft is met de internetdoodstraf, omdat het maar een kleine CA is. Maar, zo gaat het verhaal verder, niemand zal het in z’n hoofd halen om één van de grote RootCA’s aan te pakken. Simpelweg omdat de schade in dat geval te groot zal zijn. En inderdaad: de belangrijkste RootCA’s, zoals Verisign, zijn daadwerkelijk too big to fail. Een scherpe en zeer geloofwaardige observatie. De droom van PKI is afhankelijk van een onbreekbare en onfeilbare top van de hiërarchie. En dat, weten we met de kennis van nu, is onmogelijk.

Door Peter Rietveld, Senior Security consultant bij Traxion - The Identity Management Specialists -

Laatste 10 columns


Meer columns van Peter Rietveld.
Reacties (12)
13-09-2011, 12:18 door Bitwiper
De spijker op z'n kop, Peter!

Echter, dat root certificates een md5 (of zelfs md2) hash gebruiken is m.i. geen probleem. Wel een probleem is dat in de certificate stores op onze computers veel root certificaten zitten die nog vele jaren geldig zijn, maar een RSA key lengte van slechts 1024 bits gebruiken.

Over procedures en protocollen: hoewel het om "archived content" gaat is het de vraag of er ondertussen veel aan is verbeterd, in http://technet.microsoft.com/en-us/library/cc751157.aspx lees ik:
Door Microsoft, Updated: January 15, 2009: Microsoft Root Certificate Program
[...]
5. Send your Root Certificates. Send your root certificate(s) as an email attachment to Microsoft, at casubmit at microsoft·com. It is best to send .cer or .der files packaged in a .zip format to avoid Microsoft’s mail filters.
[...]
(de verhaspeling van het e-mail adres is van mijn hand). Je mag hopen dat ze na ontvangst nog even het juiste telefoonnummer bellen en de thumbprints checken, voordat ze overgaan tot het pushen van dergelijke root certificates...

Nu we toch over de vloer aan het rollen zijn: dat het cerificaten-uitgifteproces aan alle kanten rammelt bewijst notabene Verisign zelf, met een door Ben Edelman in 2005 aangetroffen code signing certificaat, met als subject "CLICK YES TO CONTINUE" (zie http://www.benedelman.org/news/020305-1.html).
13-09-2011, 12:55 door Anoniem
Over de eenvoudig te raden certificaten van Debian, een bestaat een blacklist lijst van deze certificaten en verschillende servers testen hierop, dus als je nog eentje heb liggen wordt ie toch niet gebruikt. Niet onfeilbaar, maar de meeste slechte certificaten zijn inmiddels wel de wereld uit geholpen.

Er zijn middelen om het structuur te verbeteren, bijvoorbeeld certificaten kunnen door meerdere roots getekend worden, maar dit wordt niet gedaan. Maar uiteindelijk zal DNSSEC dit probleem gewoon goed oplossen.
13-09-2011, 13:08 door Anoniem
Door Bitwiper: De spijker op z'n kop, Peter!

Echter, dat root certificates een md5 (of zelfs md2) hash gebruiken is m.i. geen probleem. Wel een probleem is dat in de certificate stores op onze computers veel root certificaten zitten die nog vele jaren geldig zijn, maar een RSA key lengte van slechts 1024 bits gebruiken.

RSA-1024 is nog steeds ruim buiten bereik van een enigzins voorstelbare aanval erop.
Het gaat bij factorisatie niet alleen om CPU cycles, maar ook om de benodigde hoeveelheid geheugen in zowel de (paralleliseerbare) zeef stap, als in de afsluitende lineaire algebra stap.
De lineaire algebra stap is heel slecht paralliseerbaar, en wordt gedaan op supercomputers of strak gekoppelde clusters;
Voor RSA-1024 liggen die benodigde resources nog behoorlijk buiten bereik.
13-09-2011, 15:40 door Anoniem
Kromme tenen krijg ik hiervan. De afgelopen weken heeft iedereen zich tot expert ontpopt lijkt wel, zo ook Peter Rietveld.

Je schrijft letterlijk: "Nogmaals dan: computerbeveiliging gaat over het beveiligen van computers, dat gaat over techniek en alleen indirect over procedures, processen en protocollen. "

Met alle respect hoor, maar iemand die dat schrijft heeft er echt helemaal niets van begrepen. Computerbeveiliging gaat over procedures, processen en protocollen. Als dat goed wordt geïmplementeerd en bewaakt dan zit je goed. Techniek is indirect van belang, zoals dat altijd is geweest.

Jammer.
13-09-2011, 17:39 door Anoniem
Maar waarom hebben we dan al die tijd in vredesnaam die 1024 bits keys gebruikt?
Terwijl we net zo gemakkelijk de 4096 bits hadden kunnen gebruiken?
Kom me niet aan met de praat dat dat gedaan is vanwege de processing tijd, misschien dat dat in het begin wat had uitgemaakt, maar volgens de Wet van Moore neemt de processing telkens met een factor twee toe, dus die sleutellengte is op den duur volledig oninterressant, gewoon wat zwaarder zetten, zoals in de GPG/open source wereld gebruikelijker is.

Caroline
13-09-2011, 19:48 door [Account Verwijderd]
[Verwijderd]
13-09-2011, 21:32 door Anoniem
Door Anoniem:
Kromme tenen krijg ik hiervan. De afgelopen weken heeft iedereen zich tot expert ontpopt lijkt wel, zo ook Peter Rietveld.

Je schrijft letterlijk: "Nogmaals dan: computerbeveiliging gaat over het beveiligen van computers, dat gaat over techniek en alleen indirect over procedures, processen en protocollen. "

Met alle respect hoor, maar iemand die dat schrijft heeft er echt helemaal niets van begrepen. Computerbeveiliging gaat over procedures, processen en protocollen. Als dat goed wordt geïmplementeerd en bewaakt dan zit je goed. Techniek is indirect van belang, zoals dat altijd is geweest.

Toch jammer dat je het niet snapt, zover beveiliging gaat ben ik blij dat iemand tenminste nog denkt aan het hoofddoel namelijk de beveiliging, Neemt niet weg dat de protocollen procedures en processen nodig zijn, maar om dat nu een hoofddoel te noemen. zodra die ingeregeld zijn is het ineens beveiligd?

Je kan nog z'n goede p- p- en p hebben ingericht, als je er niet bij nadenkt wat het doel is bereik je dat ook niet, of loop je het eigenlijke doel voorbij.
Het zou mooi zijn dat de papieren veiligheid bereikt door alleen de door jou benoemde dingen te behalen is. hoewel waarom hebben we nog mensen in de techniek nodig dan? als we alles met papier afdekken.

Kortom ga eerst eens nadenken over wat je wil en hoe je het wil, en doe daarna het papierwerk. Volgens mij kan dat toch echt niet zonder techniek.

Overigens "het principe van PKI is prima" ook z'n leuke, het principe PK is op zich prima, helaas is de infrastructuur hiervan niet zo prima. maar ik ken ook geen beter alternatief Eigenlijk is het toch onbegonnen werk om met certificaten heen en weer te fietsen om zo op de meest onmogelijke plaatsen te "installeren" en bij te houden waar en tot wanneer je een certificaat (betaald) hebt.
Om een stukje uit de text van Peter te halen "Bij webservers is dat vanzelf geregeld, maar bij Server Oriented Architectures (SOA’s) en .. niet in"
Hoe kan je certificaten op echtheid beoordelen als je ze niet kan controleren. Wil je wel afhankelijk zijn van sommige rootCA's? Op dit moment kan je niets anders, of je moet zelf al je machines langsgaan en rootCA's gaan disables (om nog maar niet te spreken van cross signing van de RootCA's) welke programmatuur gebruikt welke CA's. Ik weet het niet.

Om nog maar niet te spreken over "black boxen" binnen je netwerk, gebruiken die certificaten? zijn ze bijgewerkt? welke rootCA's vertrouwd hij? Ik zou het niet weten. Maar binnen de architectuur van PKI zou je dat eigenlijk wel moeten.
Ondanks dit is hiervoor (bij mijn weten) geen goede oplossing en moeten we het doen met een techniek die hiervoor op deze manier niet bedoeld is. Tevens onvoorwaardelijk vertrouwen hebben in de Root's, omdat we niets anders kunnen.
14-09-2011, 08:09 door Anoniem
Toch jammer dat je het niet snapt, zover beveiliging gaat ben ik blij dat iemand tenminste nog denkt aan het hoofddoel namelijk de beveiliging, Neemt niet weg dat de protocollen procedures en processen nodig zijn, maar om dat nu een hoofddoel te noemen. zodra die ingeregeld zijn is het ineens beveiligd?
Je denkt echt al een IT'er, helaas. Zonder protocollen, processen en procedures kun je technisch regelen wat je wilt maar op basis waarvan? De techniek is tegenwoordig het probleem niet, tegenwoordig kan ieder "aapje" dat wel inregelen.
Maar waar het begint is wat zijn de eisen van de business, het proces, welke risico's er zijn en hoeveel risico's er gelopen mag worden.
Daar komt nog geen spatje techniek bij kijken, die komt pas aan het einde van de keten. Security architetctuur dus.
Waar het bij veel organisaties juist fout gaat is dat men volledig vanuit de techniek denkt i.p.v uit risico's en processen.
Uiteraard is de te gebruiken techniek van belang maar zonder te weten wat deze techniek moet beveiligen heb je er niet zo heel veel aan. Dat was ook het probleem bij zowel Comodo als Diginotar, alle techniek en kennis daarvan in huis maar geen goede risico analysen en een juiste (proces)sturing daarop
Bij veel overheidsinstanties zie je dat ook fout gaan, risico analysen vinden nauwelijks plaats en men focust zich vooral op signalen uit de markt. Zo ligt momenteel heel erg de focus op het vervangen van certificaten, risico analysen worden gemaakt vanuit de focus op certificaten maar velen vergeten de rest van de keten mee te nemen en lopen daardoor nog een veel groter risico. De volgende klap lijkt haast onvermijdbaar.
14-09-2011, 13:08 door Anoniem
De verklaring voor het niet werken is eenvoudig: de machine moet zelf een verbinding met internet kunnen opbouwen. Bij webservers is dat vanzelf geregeld, maar bij Server Oriented Architectures (SOA’s) en infrastructurele voorzieningen als proxies, federatieservers en loadbalancers wil je helemaal niet dat de machines naar ‘buiten’ kunnen.

Heel jammer. Nee je wilt ook niet dat je webservers een verbinding naar 'buiten' kunnen maken. Connecties NAAR de webserver van 'buiten' zijn OK, maar connecties VAN de webserver naar 'buiten' een no-go.
15-09-2011, 14:17 door Jan-Hein
Door Hugo: Leuk artikel, maar het is wel een beetje populaire praat. Het principe van PKI is prima. Sterker nog, er is voorlopig geen bruikbaar alternatief. Op de een of andere manier moet je werken met een derde, vertrouwde partij om voor iedereen beveiligde verbindingen mogelijk te maken. Dat de beveiliging van DigiNotar, op z'n zachtst gezegd, niet op orde was zegt helemaal niks over het concept van een PKI. Zelfs het meest geniale ontwerp faalt als het niet goed geimplementeerd wordt. Terwijl we tijdens deze hele DigiNotar storm allemaal het hardst proberen te roepen hoe slecht het PKI concept is, zouden we eigenlijk moeten roepen hoe belangrijk een goede beveiliging is. Dat is de enige les die we uit dit hele voorval kunnen trekken.
Het alternatief voor een PKI is een LidoKey infrastructure.
Daarin bestaat geen centrale autoriteit, en alle encryptie is symmetrisch.

De LidoKey is ontworpen als een vervanging van de klassieke username-password authenticatie.
Het ontwerp behoudt de voordelen van dat concept (gratis, onafhankelijk van leveranciers) en voegt de veiligheid van 2 factor authenticatie toe, plus het gemak van een keyring die alle relaties van de eigenaar moeiteloos hanteerbaar maakt, zoals de password lijstjes nu proberen.

Gebruik van LidoKeys creeert een netwerk van onderling samenwerkende nodes die elkaar voortdurend controleren op integriteit.
Daardoor wordt zonder enige vorm van centrale regie een identiteitswisseling zo snel mogelijk gesignaleerd en gerepareerd.
De gebruikers van het netwerk zijn uitsluitend van hun directe communicatiepartner (relatie) afhankelijk om in perfecte privacy te interacteren: mutual assured privacy als subclass van MAD.

Ik heb het prototype van de benodigde software als open source gepubliceerd op www.jan-hein.info/lkmap.html, en op www.pimn.nl beschrijf ik in blog "Single Sign On op basis van een LidoKey infrastructure" hoe een SSO als DigiD zou kunnen worden veranderd.
Er hebben al vele experts naar het ontwerp gekeken, en iedereen weet dat het werkt.
Het prototype bewijst dat ook.

Om het ontwerp en de code te begrijpen is gespecialiseerde kennis nodig.
Indien gewenst kan ik nadere toelichting geven.

Met vriendelijke groet,
Jan-Hein van der Burg.
www.Jan-Hein.info
19-09-2011, 15:42 door Anoniem
Het is een degelijk stuk waarvoor Chapeau. Er zijn basaal twee hele grote gemene delers bij de overheid die aardig worden gebagatelliseerd. Tenminste, ik vind dat en met mij zeker flink wat anderen. Er wordt hier slechts gesproken van enkele debacles zoals Diginotar, de chip op de OV kaart en bijvoorbeeld het EPD. Ik haal graag mijn schouders hierbij op want dat is niet het werkelijke probleem.

Het echte probleem ligt hem in het gegeven dat er mensen zijn, die zichzelf IT manager of 'bestuurder' noemen, in elk geval zichzelf een bepaalde mate van autoriteit aanmeet die voorts geen enkele notie hebben van de basics van 'decent' IT laat staan IT management of de meriten en ketens die werken binnen de IT. Een flagrant voorbeeld, het artikel haalt het al aan, een fossiel genaamd Donner, totaal niets uitstaande met IT, die dan vervolgens de crisis leid.

Op dat moment heb je pragmatici en lineair mensen nodig die weten waar het probleem zich bevind en niet iemand die van een blaadje en met een souffleursdopje in het oor, de wereld verteld wat en waar het allemaal mis is gegaan en niet met eenvoudige oplossingen wist te komen. Hij wijdde in elk geval slechts uit dat men 'hinder' zal ondervinden etc etc.

Dieper ligt er een groter probleem dat namelijk aantoonbaar de meer dan 75% van de IT projecten bij de overheid falen. Klein en groot. Klaarblijkelijk, en dat is een pijnlijke constatering, lopen er erg veel mensen rond die graag met een vork schrijven, wetende dat de overheid gewoon geen idee heeft van decent IT management, daarmee IT integraal in diskrediet brengend, maar ook [top] ambtenaren die menen op de juiste plaats te zitten waardoor zij, gespeend van kennis van zaken, groen licht geven in complexe materie's die zij zelden beheersen laat staan begrijpen.

Nu weet ik niet hoe u er als IT professional en lezer[es] zelf over denkt, ik weet niet wat erger is. Wetende dat de minimale requirements voor ontwikkeling, implementatie en beheer klaarblijkelijk niet schijnt te leven binnen de overheid en de IT professionals aldaar werkzaam, of gerbuik makend van de onnozelheid/onwetendheid van individuen werkzaam binnen de overheid, niets van IT begrijpend maar wel doen alsof.

- EPD
- C2000
- OV Chipcard
- Diginotar

en uiteraard al die andere projecten en trajecten die hopeloos faalden omdat men gewoonweg niet weet hoe om te gaan met IT. Sec wijs ik in deze naar twee kampen.
21-09-2011, 15:20 door Anoniem
Ik weet niet wat Jan-Hein van der Burg op de Universiteit Twente gedaan heeft al die jaren, maar zijn werk is niet bepaald van universitair niveau. De amateuristische beschrijving van zijn 'LidoKey' infrastructuur zit vol spelfouten en ambiguiteit, en heeft niets met degelijk onderbouwd security onderzoek te maken.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.