Een Nederlandse starter beweert een einde te maken aan de certificatenhel. Trustalert levert automatisch tijdelijke certificaten, zodat beheer onnodig is. Apcare gaat het meteen gebruiken om pki als online dienst aan te bieden.
Public Key Infrastructure (pki) belooft al jaren sessies en transacties over het openbare internet intrinsiek veilig te maken. Toch komt het maar niet goed uit de startblokken. Sten Kalenda, mede-oprichter van Trustalert, heeft daar wel een verklaring voor. "De persoonlijke certificaten worden gewoonlijk voor twee jaar verstrekt. Bedrijven zijn er niet op ingericht om dat allemaal te beheren; vaak is iemand van personeelszaken ermee belast. Die database met certificaathouders functioneert naast een netwerkrechtendatabase als Active Directory die door de it-afdeling wordt beheerd. Na een week lopen die twee al niet meer synchroon."
Gedachtensprong
Kalenda, ooit begonnen als Cobol-programmeur bij het Rijks Rekencentrum, heeft in het verleden veel ervaring opgedaan met pki-projecten en de certificatenhel van nabij meegemaakt. Een creatieve gedachtensprong, zoals hij het zelf omschrijft, bracht hem tot een radicaal andere aanpak van het proces.
Pki kent een certificatie-autoriteit en een registratie-autoriteit. De eerste is al heel lang geautomatiseerd, de tweede wordt met de hand gedaan (vaak personeelszaken). "We hebben de menselijke factor eruit gehaald en de registratie-autoriteit geautomatiseerd. Bovendien bieden we kortlevende certificaten die alleen geldig zijn voor een sessie, een transactie, een halve dag of twee uur; naar believen in te stellen. Ze hoeven dus niet meer beheerd te worden, ze zijn namelijk gewoon na een tijdje niet meer geldig."
ASP
De aanpak van Trustalert (Resept, Remote Security & Escalation Platform genaamd) leidt tevens tot tweeweg SSL (secure socket layer). Gewoonlijk is SSL alleen met tokens of smartcards te bewerkstelligen. Die dingen kunnen evenwel kwijt raken of worden gestolen. En ze kosten ook nog eens geld.
Michiel de van der Schueren, directeur van Apcare, is blij met Resept. Apcare is een managed hosting provider, gespecialiseerd in het hosten van asp-diensten en outsourcing services. Het bedrijf wil online verkeer zo veilig mogelijk maken. Als voorzitter van het ASP-Forum in Nederland is De van der Schueren ervan overtuigd dat op den duur applicaties vrijwel alleen maar als dienst worden afgenomen. "Maar dan moet het wel veilig zijn. Met Trustalert hebben we een oplossing die twee keer zo veilig is dan de huidige praktijk, tegen nog eens de helft van de kosten."
Self service
Hij ziet nieuwe toepassingen ontstaan. "Vrijwel alle salarisstrookjes worden buiten de deur afgehandeld en zijn dan via internet te controleren door personeelszaken, voordat ze worden uitgedraaid en rondgestuurd. Ik zie gebeuren dat mensen een mailtje krijgen dat voortaan hun salarisstrook ergens op internet klaar staat om te worden opgehaald. Zij krijgen dan een certificaat om alleen die handeling te verrichten. Dit is een enorme stimulans voor self service."
Het nut van een certificaat is de identificatie van de gebruiker. Bij uitgifte wordt vastgesteld wie de gebruiker is, door middel van een eenvoudige email challenge of door controle van het paspoort door een notaris, afhankelijk van het gewenste niveau van authenticatie. Daarna weet je dat een bepaald certificaat zeker bij een bepaalde gebruiker hoort.
Als een certificaat maar twee uur geldig is, zou je dus om de twee uur de identiteit van de gebruiker opnieuw moeten verifieren. Dat doet TrustAlert vast niet, ik neem aan dat de link naar de gebruiker wordt gelegd via een cookie, via een user-id en wachtwoord, of zoiets. Het veiligheids niveau van het certificaat wordt dus aanzienlijk omlaag gehaald, tot dat van een user-id en wachtwoord of zelfs van een cookie.
TrustAlert heeft ‘de menselijke factor er uit gehaald’ door het uitgifteproces van certificaten te automatiseren. Izecom doet dat al vier jaar, en sinds kort ook voor Comodo certificaten waarvan de CA in windows is opgenomen.
volgens mij gaat de gedachtengang mis op het feit dat het bij een Registration Authority gaat om het koppelen van fysieke entiteiten aan digitale identiteiten. De RA heef deze verantwoordelijkheid, is persoon A daadwerkelijk is wie hij zegt te zijn; het gaat dus om de vertrouwensrelatie tussen entiteit en (digitale) identiteit.
Een vertrouwen in een certificaat is waardeloos als er geen valide authenticatieproces is vanuit de RA, iedereen kan dan ‘even’ een certificaat aanvragen, hierdoor ontstaat er een vals vertrouwen in certificaten.
Daarbij zal een geautomatiseerd RA proces meestal gaan van username & password naar de aanvraag van een certificaat, dus van weak authentication naar strong authentication… dit kan m.i. nooit de bedoeling zijn, een hogere security graad behalen via een lagere graad.
Microsoft heeft recentelijk een product voor het beheer van certificaten gelanceerd: CLM ofwel Certificate LifeCycle Manager.
En hoe ontvangen de mensen het tijdelijke certificaat? Is dit te onderscheppen? Zo ja, weg is het beoogde resultaat.
Aram zegt:
Een vertrouwen in een certificaat is waardeloos als er geen valide authenticatieproces is vanuit de RA, iedereen kan dan ‘even’ een certificaat
aanvragen, hierdoor ontstaat er een vals vertrouwen in certificaten.
Dat is waar. Je kunt het aanvragen van certificaten automatiseren als de geautomatiseerde aanvrager zich goed kan identificeren met een eigen certificaat, en als uitgifte van certificaten beperkt is tot het domein van de aanvrager. In feite delegeert de RA dan de uitgifte naar een organisatie zelf, die dan uiteraard wel zelf de verantwoordelijkheid draagt. Vergelijkbaar met dat je bij een CA een eigen portal kan huren voor het uitgeven van certificaten binnen je eigen domein.
Mensen zeggen altijd maar dat PKI zo vreselijk ingewikkeld is en dat het zoveel beheer met zich meebrengt. Dat hoeft helemaal niet, als je het goed doet. Kortlevende certificaten zijn in ieder geval niet de oplossing.
Buiten dat er een onjuistheid in het artikel staat: “Gewoonlijk is SSL alleen met tokens of smartcards te bewerkstelligen.”, klopt het voor deel wel dat er procedurele en technische issues zijn met het aanvragen en verlengen van certificaten.
De procedurele issues zijn redelijk goed te automatiseren is onze ervaring (moet je het alleen *wel* doen ;-)) en ik sluit me bij de voorgaande posts aan dat de genoemde dienst hier mogelijk de beveiliging omlaag haalt.
De technische issues zijn minder makkelijk op te lossen. Bij Microsoft gerelateerde producten is het namelijk noodzakelijk om ActiveX ™ controls te runnen en soms zelfs te downloaden. BAH, we hebben tegenwoordig (~30.000 certificaten) veeeeeeel minder (tot geen) problemen met klanten die FF gebruiken (nee geen FF plug, gewoon een constatering).
Ik moet zeggen dat ik niet direct ben overtuigd van de waarde van deze oplossing. Wat Aram Smith terecht opmerkt is het feit dat je nog steeds een fysieke identiteit moet koppelen aan een digitale identiteit. En daar wordt bij deze oplossing toch echt aan voorbijgegaan.
Het distribueren van sleutels en certificaten is the centrale problem wanneer het gaat om veilige infrastructuren voor informatie communicatie netwerken. Public Key technologie is hiervoor in principe niet geschikt, bijvoorbeeld om het inefficiente gebruik van processor resources en het onvoldoende ondersteunen van gedistribueerde scenario?s Conventionele gedistribueerde symmetrische sleutel overeenkomst modellen proberen gemeenschappelijke sleutel overeenkomsten te bereiken tussen elke mogelijke verbinding in het Netwerk. Deze manier in ook ongeschikt omdat het geheugen gebruik N-1 is in een Netwerk met N knooppunten en dus alleen bruikbaar is in kleine netwerken waarbij N klein is. Er is een nieuwe manier van symmetrische sleutel overeenkomst in het Netwerk, welke schaalbaar is voor grote netwerken met een heel klein geheugen gebruik per netwerk node. Het geheugen gebruik per Netwerk Node is daarbij van de orde k.Wortel(N), waarbij k>=1 en afhankelijk is van het vrij instelbare veiligheids niveau tot en met bewijsbaar perfect veilig. De op dit moment gebuikte gedistribueerde sleutel distributie modellen zijn alle een speciaal geval van dit schema.
Wat is hier het nut van? Je kan net zo goed een salarisstrookje met username en password ophalen, via een SSL-beveilige verbinding. Daar heb je echt zelf geen certificaat voor nodig.
Beveiliging is net zo sterk als de zwakste schakel. Dit is in dit geval duidelijk het certificaat dat wordt opgehaald uit je mailbox.. met username/pass. Een persoonlijk certificaat heb je echt niet nodig om de gegevensoverdracht via een veilige SSL-verbinding te laten verlopen. Een server met SSL-certificaat is in dit geval al voldoende.
De kracht van PKI is echter een sterke authenticatie. Het fundamentale probleem ligt hem erin dat PKI een gefragmenteerde structuur is geworden. Het zou mooi zijn als iedere burger een digitaal paspoort krijgt met zijn eigen privesleutel (certificaat) op basis vanwaar authenticiatie en autorisatie kan plaatsvinden.
Complete onzin dit dus.