Is Diginotar aansprakelijk voor de schade uit frauduleuze certificaten?

diginotar-subroot-digid.pngAuw. Iraans verkeer naar Gmail kon worden afgetapt dankzij een door Diginotar goedgekeurd certificaat, zo bleek deze week. Alle grote browsers revoceerden meteen het certificaat van Diginotar, hoewel Firefox later een uitzondering maakte voor DigiD. Na enig getreuzel kwam Diginotar-eigenaar Vasco met een verklaring dat men in juli was gehackt, waarna bleek dat in ieder geval de website al jaren kwetsbaar was. En daarna dook nieuws op dat er nog veel meer valse certificaten in omloop waren, waaronder voor anonimiteitsnetwerk Tor. Heeft Diginotar nu een probleem of niet?

Laten we eens doen of de publiciteit niet al genoeg is om het einde van Diginotar als merknaam in te luiden, en de juridische gevolgen bekijken van deze faal. De wet kent namelijk de nodige bepalingen over certificatiedienstverleners, oftewel personen of bedrijven die certificaten afgeven of andere diensten in verband met elektronische handtekeningen verleent, zoals de Telecommunicatiewet ze definieert.

Toen e-commerce een beetje populair begon te worden, ontstond behoefte aan het zetten van digitale handtekeningen. Waarom is mij volstrekt onduidelijk, handtekeningen zijn namelijk zelden tot nooit nodig in het handelsverkeer. Ja, als je een huis wilt kopen, maar dat is nu net een van de weinige dingen die je niet via een internetdienst kunt doen. Maar goed, er moesten digitale, pardon elektronische handtekeningen komen en daar moest dan een hele infrastructuur bij opgezet worden om te kunnen controleren wie die had gezet. Ik ben daar ooit op afgestudeerd maar ondertussen best wel cynisch over het nut van deze hele poppenkast. Waar is de infrastructuur voor analoge handtekeningen?

Afijn, die infrastructuur oftewel PKI is waar Diginotar een rol in speelde. De opzet van deze infrastructuur is hiërarchisch: we vertrouwen een partij met een certificaat omdat de uitgever van dat certificaat zegt dat dat klopt. En we vertrouwen die uitgever omdat ook hij een certificaat heeft waarvan de uitgever zegt dat het klopt. Enzovoorts, enzoverder tot we bij de wortel van deze hiërarchische boom zijn. (Terzijde: informatici tekenen zulke bomen met de wortel aan de bovenkant. Argh.) Diginotar heeft de positie van root CA, wat zo veel wil zeggen als dat wanneer Diginotar het zegt, het klopt. Gewoon, omdat het kanergens ophoudt. (Overigens geldt dit niet voor DigiD, daar is Diginotar ‘slechts’ sub-root onder de Staat der Nederlanden.)

diginotar-certificaat-faal-auw.pngVertrouwen is dus het fundament waar de dienstverlening van een certificatiedienstverleners op stoelt. Immers, een echt certificaat is op geen enkele wijze te onderscheiden van een per abuis of met kwade trouw uitgegeven certificaat. De enige controle is de elektronische handtekening die erbij staat, maar die zegt niets over de inhoud. Het certificaat waar het allemaal mee begon, vermeldde de sites van Google (*.google.com) maar was in gebruik bij een partij die niet Google was. Dat is fataal voor de goede werking van een PKI.

“Gekwalificeerde” certificaten mag je alleen uitgeven als je geregistreerd bent bij de OPTA (wat Diginotar ook keurig is). Een gekwalificeerd certificaat is een certificaat dat uitgegeven is door een geregistreerde partij die zich netjes aan de regels houdt over betrouwbaarheid, en dat aan een persoon gekoppeld is.

Aan een dienstverlener die dergelijke certificaten uitgeeft, worden zware eisen gesteld door de wet en het daarbij behorende besluit. Zo moet je ETSI TS 101 456 naleven en houdt OPTA toezicht. En de wet (art. 6:196b BW) verklaart de dienstverlener aansprakelijk voor alle schade door onjuist uitgegeven certificaten, tenzij zij kan bewijzen dat zij niet onzorgvuldig heeft gehandeld, of als het certificaat ingetrokken was voordat de schade ontstond, of als het certificaat voor een niet in het certificaat vermeld doel werd aangemerkt.

Alleen: de SSL-certificaten waar het om gaat, zijn geen gekwalificeerde certificaten. Daarmee is die bijzonder strenge aansprakelijkheidsregel niet van toepassing. En dan wordt het lastig, want dan is Diginotar juridisch gezien gewoon een club die iets zegt met een digitale handtekening eronder, en tsja, afgaan op wat mensen zeggen is geen reden om ze aansprakelijk te stellen als ze het fout hadden. Anders heb ik nog wel een leuke claim tegen Astro-TV. Voor aansprakelijkheid is meer nodig: je moet een wettelijke norm geschonden hebben (die in direct verband staat met de schade) of je moet maatschappelijk onzorgvuldig hebben gehandeld, oftewel “dit staat niet in de wet maar vinden we toch dusdanig onfatsoenlijk dat je alsnog schade moet vergoeden”.

Bij die onzorgvuldigheidsnorm wegen altijd de exacte omstandigheden van het geval zwaar. Zo zal bijvoorbeeld meewegen wat de oorzaak van de hack is waarmee deze certificaten gegenereerd konden worden. Was men nalatig in het sleutelbeheer? Of was dit een buitengewoon geavanceerde zero-day hack (à la de RSA phish) die niemand had kunnen opmerken? Heeft Diginotar na het ontdekken van de hack alles gedaan om de gevolgen tegen te gaan, of heeft ze juist zitten treuzelen?

Als blijkt dat ze te weinig hebben gedaan, dan kunnen getroffen Gmailende Iraniërs ze aansprakelijk stellen voor hun schade – alleen zal die lastig aan te tonen zijn. Maar ook andere partijen die getroffen zijn door de onjuist uitgegeven certificaten kunnen dit proberen. Zo zou een webwinkel die zijn SSL-certificaat ongeldig ziet worden omdat Mozilla of Microsoft Diginotar niet meer erkent, omzet kunnen mislopen omdat mensen niet meer durven te bestellen door de foutmeldingen die ze dan krijgen. Gemiste omzet is natuurlijk wel lastig om te onderbouwen, maar zoals uit een zaak tussen TROS Radar en een hondenfokker bleek, kan een deskundige worden opgeroepen die de boeken onderzoekt en inschat wat de omzet of winst zou zijn geweest. In de Radar-zaak werd die op een half miljoen euro geschat.

Arnoud

66 reacties

  1. Is het nu niet hoog tijd voor een “I am paranoid!”-optie in Firefox (en andere browsers)?

    Functionaliteit als volgt: – iedere keer dat een nieuw certificaat wordt ontvangen krijgt de gebruiker hiervan een melding met aanduiding van de CA en de fingerprint van het certificaat; – iedere keer dat een nieuw certificaat wordt ontvangen van een site waar de browser al een certificaat van had wordt de melding nog wat indringender, in ieder geval als het oude certificaat nog lang niet expired is en/of de CA is gwijzigd.

    Aan de hand van de CA en de fingerprint kan de gebruiker zelf proberen te controleren of het certificaat juist is. De gebruiker kan zelf bepalen hoever hij hierbij gaat, en zal dat natuurlijk laten afhangen van de gevoeligheid van de informatie die hij met die site gaat uitwisselen.

    Lijsten met fingerprints van de belangrijkste sites kunnen eenvoudig overal op internet beschikbaar worden gemaakt.

  2. @Piet: Controle aan de gebruiker overlaten werkt niet. Hoe maak je het verschil duidelijk aan de gebruiker? “Let op: uw browsergegevens worden mogelijk onderschept door een kwaadwillende overheid!”? Zo gaat DigID ook geen zieltjes winnen. Laat staan de (financiële) impact die het heeft op normale sites die om een normale administratieve reden van CA wisselen.

    Google ondersteunt inmiddels met Chrome versie 13 het zgn. ‘Public key pinning’, waar een afgeleide van jouw idee in gebruikt wordt. Zie o.a. http://ssl.entrust.net/blog/?p=615 Met public key pinning worden bepaalde fingerprints ge-whitelist. Dit is ook niet ideaal omdat het niet schaalt, maar het is alvast een kleine verbetering.

  3. @George, als de CA kopieen bewaart van de private key dan is dat een veiligheids-risico. Want wat als een boze medewerker deze kopieen gewoon even op een USB stick meeneemt en per opbod verkoopt? Een private key hoort gewoon uniek te zijn. Een CA hoort daar geen kopie van te hebben. Dat is hetzelfde als een autodealer die van iedere auto die hij verkoopt een extra contactsleutel bewaart voor het geval dat… Tja, waarvoor eigenlijk? Het enige nut is dat een medewerker van die dealer vervolgens die sluetels jat en bij alle klanten even langs gaat om hun nieuwe auto’s te jatten. Een CA die een certificaat bewaart? Foute boel! Mocht een klant zijn certificaat kwijt raken dan maak je gewoon een nieuwe. Het gaat niet om kopieen van de public keys die DigiNotar bewaarde, maar kopieen van de private keys. Om public keys maakt niemand zich zorgen.

  4. @Arco, de hamvraag is hoe snel DigiNotar failliet gaat! Vasco heeft DigiNotar ooit gekocht voor 10 miljoen Euro en dat geeft ook ongeveer aan wat het bedrijf uiteindelijk waard zou kunnen zijn. Dat in combinatie met een aansprakelijkheidsverzekering die ze vast hebben en die ook de nodige miljoenen kan ophoesten aan schadevergoedingen (tot een maximum bedrag!) denk ik dat bij een totale schadeclaim van 40 tot 50 miljoen Euro het bedrijf al meteen opgedoekt kan worden. De enige reden waarom Diginotar nog leeft is wegens het onderzoek naar deze hack. Gevolgen voor Vasco? Weinig tot geen, denk ik. Ja, een forse afschrijving omdat ze DigiNotar ooit kochten en nu meteen moeten afstoten. Ze hadden Diginotar nog niet eens een jaar in bezit dus al te verantwoordelijk is Vasco misschien niet. Tenzij Vasco bij de overname ook meteen structurele wijzigingen heeft uitgevoerd waardoor deze hack mogelijk werd! Ook zal sterk worden gekeken naar de rol van Vasco in het hele gebeuren en mogelijk dat een deel van de verantwoording ook naar Vasco kan worden geschoven. Gaat Vasco mogelijk ook failliet. (Sowieso heeft hun reputatie nu een enorme deuk opgelopen.)

  5. @Pandy, voor een man-in-the-middle aanval moet je niet alleen de certificaten vervalsen maar ook de netwerk-verbindingen omleiden naar je eigen servers. Dat kan indien je in de DNS registers het een en ander kunt aanpassen of op de client PC’s de HOSTS kunt aanpassen. Beiden zijn best lastig om uit te voeren, tenzij je de controle hebt over de internet providers in een bepaalde omgeving. Want in dat geval kun je de mensen die aan die ISP’s hangen dus misleiden. Grote kans dus dat dit in Iran is gebeurt maar buiten Iran zal iedereen nog wel redelijk veilig zijn.

  6. @Robert:

    @Piet: Controle aan de gebruiker overlaten werkt niet.
    Ik denk aan een optie speciaal voor de gebruikers die weten wat ze doen en niet volledig willen vertrouwen op de controle die de browser zelf uitvoert (en waar gmail-certificaten van Diginotar vrolijk doorheen fietsen…). De normale gebruiker zal zo’n “I am paranoid!”-optie niet gebruiken. Stop ‘m desnoods weg in de about:config van FF.

    Met mijn optie aangevinkt zouden de (paranoïde) Iraanse internetters op hun scherm een overduidelijke melding hebben gekregen dat gmail is overgestapt op Diginotar als CA.

    Er hoeft niet bij te staan dat er iets mis is, zeker niet als de checks die de browser zelf uit kan voeren niet op een probleem duiden. Gewoon wat informatie die de paranoïde gebruiker in staat stelt om zelf een oordeel te vormen. Nu konden ze dat niet, de browser accepteert ongevraagd een gmail-certificaat van Diginotar.

    Als zelfs maar een klein deel van de gebruikers zo’n optie aan heeft staan, zal een vals certificaat snel door de mand vallen. De reden dat de hele affaire nu aan het licht is gekomen is dat Chrome voor gmail blijkbaar zelf zo’n sanitycheck uitvoert, waardoor een gebruiker onraad kon ruiken.

    (Misschien zijn er al browserextensies die iets soortgelijks doen?)

    @Wim:

    @George, als de CA kopieen bewaart van de private key dan is dat een veiligheids-risico
    George schrijft nu juist dat dat niet gebeurt, omdat de CA die private key nooit in handen krijgt. Het bewaren van een gegenereerd certificaat is dus compleet onschuldig. Sterker nog, iedere gebruiker van de website krijgt die certificaten op zijn computer.

  7. Ik denk aan een optie speciaal voor de gebruikers die weten wat ze doen
    In werkelijkheid zijn dat niet zoveel gebruikers! De meeste gebruikers denken te weten wat ze doen maar in werkelijkheid snappen ze dingen maar half, wat juist een groter risico met zich mee kan brengen! Die mensen van DigiNotar zullen ook wel gedacht hebben dat ze wisten wat ze deden. Geen virusscanners, eenvoudige wachtwoorden, ja, ja… Uiteindelijk is het een bedrijf vol prutsers die meer aandacht gaven aan winst maken en geld besparen dan dat ze daadwerkelijk veilig bezig gingen. Ze gingen voor gemak, niet voor veiligheid…
    George schrijft nu juist dat dat niet gebeurt, omdat de CA die private key nooit in handen krijgt.
    Dat klopt niet helemaal want zonder private key kan een CA geeneens een certificaat genereren. Nu zijn er twee methodes die CA’s toepassen: of de gebruiker maakt zelf een keypaar aan en laat de public key certificeren, of de gebruiker bestelt een compleet keypaar en installeert deze op zijn eigen systeem. In het eerste geval heeft George gelijk. Veel CA’s ondersteunen ook de tweede methode… Voorbeeld, bij StartSSL kun je voor weinig geld certificaten kopen. Een SSL certificaat kun je daar via een eenvoudige wizard aanmaken waarbij je of een wachtwoord opgeeft van 10 letters en/of cijfers of je voert je private key in! Het resultaat is een certificaat, klaar voor gebruik…

  8. Met mijn optie aangevinkt zouden de (paranoïde) Iraanse internetters op hun scherm een overduidelijke melding hebben gekregen dat gmail is overgestapt op Diginotar als CA.
    Maar iedereen kan nu al eenvoudig het certificaat controleren van beveiligde websites! Zo’n beetje iedere browser heeft wel ergens een icoontje met sleutel of zo waar je op kunt klikken als je paranoide bent. Maar om dit nu iedere keer weer handmatig te moeten doen? En dat voor mogelijk iedere kleine wijziging die in een certificaat plaatsvindt? Na enkele malen een vals alarm klikken de meeste gebruikers een dergelijke melding gewoon weg of zetten die optie uit. Veel mensen zijn namelijk gemakzuchtig bezig. Helaas gaat dat wel ten koste van de beveiliging, zoals DigiNotar heeft aangetoond. Daarnaast, een dergelijke Man-In-The-Middle aanval vindt plaats in twee delen. Vervalsen van het certificaat en het omleiden van het Internet-verkeer. En dat laatste gebeurt meestal op locaal niveau, binnen een provider of zoals in dit geval binnen alle providers die de locale regering kan controleren. Het probleem van een dergelijke paniek-knop ontstaat wanneer mensen in Iran opeens die knop gebruiken en opeens weer wereldwijd paniek uitbreekt! (Of de providers vangen ook het gebruik van die knop af en dan wordt er niemand gewaarschuwd. Ze zitten immers in het midden en hebben dus controle over dit dataverkeer!) Een ander probleem is dat er mensen zullen zijn die expres vals alarm zullen roepen over bepaalde sites. Dat is nog het meest vervelende, zeker indien hiervoor malware wordt toegepast om overal valse alarms te genereren. Een dergelijk waarschuwings-systeem gaat dan snel ten onder door die druk.

    Bedenk verder dat geen enkel systeem waterdicht is. Hou er altijd rekening mee dat je internet-communicatie afgeluisterd kan worden en sta dan ook stil welke risico’s je vervolgens loopt. En in de praktijk valt dat vaak best mee. Zo ook in deze situatie waar eigenlijk alleen de Iraanse dissidenten de slachtoffers waren. En dan nog, gezien de hoeveelheid data die men hiervoor moet verwerken denk ik dat er nog veel van hen aan ontsnapt zijn. Om ook even over na te denken… In 2012 zijn er nieuwe verkiezingen in Iran. Deze aanval is voor de huidige regering dan ook ideaal om nog wat extra dissidenten op te pakken en te berechten. Dit is dan ook deels een prestige-hack geweest, naar mijn mening. Gewoon even laten zien aan de bevolking hoe goed Iran is op het gebied van Internet-spionage.

    Maar even een vraagje… Zijn er al gegevens bekend van slachtoffers van deze hack? Zijn er wel slachtoffers of is het meer de chaos en verwarring die slachtoffers maakt?

  9. De overheid heeft zijn certificaten uitbesteed aan Diginotar. De vraag is welke maatregelen heeft de overheid genomen om de veiligheid te waarborgen. Wordt er regelmatig een security audit uitgevoerd op Diginotar. Zoja waarom is dit probleem dan niet eerder ontdekt. Zo nee, hoe weet de overheid dat dit bedrijf zijn zaken op orde heeft? In dat geval is ook de overheid aansprakelijk en nalatig geweest

  10. Wim, ik denk dat de overheid zelf, net als DigiNotar, ook gewoon te gemakzuchtig bezig is geweest. Sowieso is de overheid van nature al erg traag en loopt men altijd achter op ICT-gebied omdat de mensen met ervaring meestal elders een beter betaalde baan kunnen vinden. Ondertussen heeft de overheid DigiNotar gewoon overgenomen en worden er de nodige experts ingehuurd om te onderzoeken wat er precies is gebeurt, wie er achter zat, wat de totale schade is en eventueel wie er strafrechtelijk vervolgd dient te worden. Als het gaat om ICT-projecten is de overheid bijna altijd afhankelijk van externe partijen en heeft de overheid nog wel eens de neiging om op bepaalde controles dusdanig te bezuinigen dat er van deugdelijke controles geen sprake meer is. En denk maar niet dat verkiezingen de volgende regering slimmer zal maken want die personen die we kiezen zijn uiteindelijk niet diegenen die het werk moeten uitvoeren. De regering die we kiezen bepalen alleen het beleid. De ambtenaren die gewoon betaald krijgen ongeacht wie er regeert bepalen uiteindelijk wat er wel en niet gebeurt, ook al moeten ze daarbij tegen de wensen van de regering in gaan…

  11. @Wim(#57):

    Dat klopt niet helemaal want zonder private key kan een CA geeneens een certificaat genereren.
    Dat klopt gewoon niet. Lees de reactie van George nou eens goed, hij legt toch duidelijk uit hoe het in elkaar zit. De CA heeft de private key van de website niet nodig, en die private key zit ook niet in het certificaat. En nogmaals, die certificaten staan ook gewoon op jouw computer nadat je de website hebt bezocht.

    Zelfs al zou Diginotar voor hun klanten het keypaar hebben gegenereerd (wat mij zeer onwaarschijnlijk lijkt), dan zit die private key nog steeds niet in het certificaat, dus is er nog steeds niets aan de hand als Diginotar al die certificaten onveilig heeft opgeslagen. Daar volgt niet uit dat ook de private key’s worden bewaard, dat lees alleen jij erin.

    Maar iedereen kan nu al eenvoudig het certificaat controleren van beveiligde websites!

    Tuurlijk, maar ik heb geen optie om mijn browser mij te laten vertellen dat ik een bepaald certificaat VOOR HET EERST gebruik. Ik hoef een certificaat maar 1x op echtheid te controleren, maar dan moet ik wel weten dat ik een nieuw certificaat heb ontvangen.

    Die Iraanse internetters kregen een nieuw certificaat voor de kiezen zonder het te merken. Je kunt niet verwachten dat je IEDERE sessie gaat controleren of het wel klopt. Per kritieke site (als gmail) één check per 2 of 3 jaar is niet echt een probleem lijkt me zo. (Nee, certificaten worden niet elke week “een klein beetje” gewijzigd.)

    Nou ja, als je het simpele nut van zo’n optie niet wilt zien, dan hoeft dat natuurlijk niet. Maar laat je lange zijspoor-ik-moet-per-se-mijn-kennis-spuien-verhalen liever zitten, neem mij niet kwalijk maar dank je feestelijk.

  12. @Piet, even het gehele proces voor het maken van een certificaat doornemen… Het begint met een key-paar die de gebruiker op zijn eigen systeem heeft. De private key hiervoor behou je zelf, de public key wordt met extra data verstuurd naar de CA. De CA gebruikt vervolgens hun eigen private key om van deze data een certificaat te maken. Dat certificaat gaat weer terug naar de gebruiker en wordt door de webserver weer doorgestuurd naar de browsers die deze vervolgens kunnen valideren. Tot zover heeft George gewoon gelijk. Maar de CA kan naast het tekenen van public keys ook private keys genereren voor hun klanten. StartSSL doet dit, bijvoorbeeld. Je meldt je aan en ze versturen je een certificaat met daarin een public en private key. De CA hoeft daarna alleen de Public key hiervan te bewaren en de gebruiker logt op de site in via hun private key. De CA moet in dit geval niet de private key van de klant bewaren. DigiNotar schijnt dit juist wel gedaan te hebben! Het voordeel van wat StartSSL doet is dat je dus een certificaat plus private key hebt, waarbij je die private key op meerdere servers tegelijkertijd kunt gebruiken. De standaard private key onder IIS is namelijk machine-afhankelijk. Je moet er natuurlijk wel voorzichtig mee zijn want als die private key in verkeerde handen valt… Vergeet niet dat DigiNotar meer deed dan alleen SSL certificaten genereren. Indien DigiNotar inderdaad die private keys bewaarde die in opdracht van klanten zijn aangemaakt dan is dat een enorm risico indien deze private keys in verkeerde handen vallen. Immers, die private key is al voldoende om de communicatie mee te decrypten! Zelfs indien een bedrijf elders een nieuw certificaat genereert maar dezelfde private key gebruikt!!

  13. Die Iraanse internetters kregen een nieuw certificaat voor de kiezen zonder het te merken.
    Eigenlijk schijnt het een Iranier geweest te zijn die de hack als eerste opmerkte toen hij met Chrome naar de website van Google ging. Chrome controleert kennelijk net iets verder dan normaal en kon ontdekken dat die Iranier een certificaat gebruikte dat normaal niet bij Google hoort. Dus een popup met waarschuwing, ook al leek het certificaat verder in orde. Een systeem waarbij de gebruiker zelf moet controleren of een certificaat klopt gaat ten onder aan het gebrek aan gebruikers-gemak. Beter is het indien browsers dergelijke controles automatisch kunnen uitvoeren en dat kan vrij ver geautomatiseerd worden. Voorbeeld: Iranier X gaat bladeren naar https://iusmentis.nl en krijgt een certificaat van DigiNotar. De browser kan op dat moment dit certificaat ook doorsturen naar een centrale server die vervolgens registreert dat bij deze site dit certificaat behoort. Indien het certificaat al eerder bekend was is er niets aan de hand. Is het certificaat nog onbekend dan gaat de browser eerst goedgelovig verder, maar het centrale registratie-systeem gaat vervolgens de betreffende site vanuit meerdere plaatsen op de wereld opnieuw vragen om even het certificaat aan te leveren. Indien al die locaties hetzelfde certificaat opleveren is er niets aan de hand. Als er afwijkingen zijn dan worden die onthouden en die moeten dan verder uitgezocht worden. Dat uitzoekwerk zal de nodige tijd kosten dus die centrale organisatie is daar wel enkele uren mee bezig. De gebruiker zelf zal ondertussen wel klaar zijn met browsen en die wil je niet uren laten wachten. Mocht uiteindelijk geconcludeerd worden dat het een vervalst certificaat betreft (omdat geen enkel checkpoint het betreffende certificaat aanlevert of omdat het onderzoek uitwijst dat het is vervalst) dan kan het betreffende certificaat direct geblokkeerd worden door de browser. Als Iranier X dan weer opnieuw naar de site gaat (of tijdens het browsen) dan krijgt hij daarover meteen een waarschuwing.

  14. Tot zover heeft George gewoon gelijk. Maar de CA kan naast het tekenen van public keys ook private keys genereren voor hun klanten.

    Hey Wim, bel/tweet me even de volgende keer dat je een wachtwoord nodig hebt of je PIN wilt wijzigen. Ik weet nog wel een paar goede codes.

    Het is “niet handig” om je private key door anderen te laten genereren. Als iemand dat aanbiedt “omdat het makkelijk is” dan is dat voor rekening van de sufferd die daarvoor gaat.

    Het hele idee is dat je private key nooit over een onveilig medium (als Internet) wordt verstuurd. Je PIN/wachtwoord geef je ook niet over de telefoon aan iemand door.

    Private Keys kunnen “exporteerbaar” zijn, zodat je ze op meerdere systemen kan gebruiken. Zo worden ze standaard aangemaakt door IIS; voor exporteren gebruik je de Certificates Management Console.

    Je kan een Private Key ook niet exporteerbaar aanmaken; dat is veiliger, “duh”.

    Keys op (USB) access-tokens of voor het identificeren van systemen/computers worden vaak niet-exporteerbaar aangemaakt, om voor de hand liggende redenen.

    George.

  15. @George, natuurlijk is dat niet handig maar het gebeurt wel! Mede ook omdat gebruikers vaak onwetend zijn over hoe je met dit soort beveiliging om moet gaan. Maar goed, zelf heb ik bij StartSSL gewoon eerst zelf via IIS een CSR aangemaakt en die opgestuurd zodat ik zeker weet dat de private key van mijn eigen systeem is gebruikt. Probleem is dan wel dat ik mijn eigen private key dus ook veilig moet stellen indien mijn server ooit vervangen moet worden of als ik een andere server wil gaan gebruiken. Die private key moet dan naar die andere computer. En daar zit het “gemak” hem dus, want StartSSL geeft je eigenlijk alleen die sleutels zodat je daarmee op hun site kunt inloggen. (Client authentication noemen ze dat.) Dat ze daarnaast de mogelijkheid bieden om de publieke key ervan te gebruiken voor het genereren van SSL certificaten is leuk en aardig, maar is eigenlijk niet de bedoeling. En ja, met IIS kun je inderdaad je certificaten exporteren, indien ze exporteerbaar zijn. Handig, maar ook weer riskant want als die keys door malware worden ge-exporteerd… Of als het export-bestand in verkeerde handen valt…

    Domheid en gemakzucht gaan vaak hand-in-hand met elkaar. Mensen kiezen sneller voor de eenvoudige methode dan de veilige methode.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.