Iedereen heeft wel eens van pki (public key infrastructure) gehoord, maar slechts weinigen weten hoe je het moet implementeren en gebruiken. Daarom blijven we werken met ontoereikende technieken als authenticatie per site op basis van een gedeeld ‘geheim’: de combinatie gebruikersnaam en wachtwoord. Toch hoeft pki niet complexer te zijn, terwijl het wel veiliger is.
Als je besloten webfora leest of zaken doet via internet, moet je regelmatig eerst een ‘account aanmaken’ en vervolgens ‘inloggen’. Zo’n gemeenschappelijk geheimpje schept de illusie van vertrouwelijkheid tussen gebruiker en webdienstleverancier. Het feit dat het verkeer tegenwoordig routineus over versleutelde verbindingen wordt geleid versterkt die illusie vaak. Gebruiker en leverancier wanen zich veilig, maar hun vertrouwen kan eenvoudig worden beschaamd, met alle gevolgen van dien.
Leveranciers kunnen je op je internetidentiteit aanspreken en zaken leveren die je niet hebt besteld. Dat is op zijn minst lastig, ook voor de leverancier; hij maakt kosten en moet maar hopen dat daar baten tegenover staan. Iemand kan zich als jou voordoen op internet en je bijvoorbeeld uitspraken in de mond leggen die je zeker niet zou doen. Al is het juridisch niet aantoonbaar dat jij het was, het is ook niet makkelijk te bewijzen dat je het niet was. Veel mensen denken dan ‘waar rook is zal wel vuur zijn’.
Slechte sleutels
Veel van deze problemen zijn te voorkomen door te garanderen dat je bent wie je zegt te zijn. Bij het aanvragen van een wachtwoord/gebruikersnaam-combinatie via een website gebeurt dit niet of nauwelijks. Daardoor houdt weinig een kwaadwillende tegen om op internet te doen of hij jou is. Veelal volstaat de webdienstleverancier met een mail naar een adres wat je zelf mag opgeven en naderhand kunt wijzigen. Daarvan is evenmin gegarandeerd bij wie het hoort.
Nog beroerder dan iemand die zich voordoet als jou is het als iemand je digitale identiteit echt kan stelen door zich het ‘bewijs’ dat hij jou is (je gebruikersnaam en wachtwoord) toe te eigenen. Al denk je dat dit een geheim is tussen jou en je leverancier, je hebt daar geen zekerheid over. Een malafide beheerder of een hacker kan zich er meester van maken en heeft dan toegang tot je persoonlijke, vertrouwelijke gegevens.
Voor elke dienst en voor elk forum moet je je opnieuw aanmelden en je (deels vertrouwelijke) gegevens invoeren, en je wachtwoorden zien te onthouden. Hoe meer servers je gebruikt, hoe moeilijker dat wordt. Veel mensen gebruiken daarom op verschillende sites dezelfde naam/wachtwoord-combinatie. Die stelen geeft dus toegang tot meerdere systemen.
Wachtwoorden zijn bovendien slechte sleutels. Ze zijn makkelijk te kopiëren en te raden. Ze blijven vaak te lang hetzelfde. Veel mensen moeten hun wachtwoorden opschrijven om ze te onthouden. Heeft niemand ze overgeschreven? Zo’n handige browser die je wachtwoorden onthoudt, is die te vertrouwen? En je gezinsleden? Zelfs als je zuinig bent op je wachtwoorden blijft het mogelijk dat de beheerder van de server waar je je dienst afneemt onbetrouwbaar is.
Alternatief
Gezien de plausibiliteit dat je gebruikersnaam/wachtwoord-combinatie bekend raakt bij anderen en de doorgaans ontbrekende binding tussen digitale- en werkelijke identiteit bestaat er aarzeling om vertrouwelijke elektronische dossiers via internet beschikbaar te stellen. We kiezen dan voor ’tokens’ als badges en chipkaarten, tan-lijsten en dergelijke. Er is terecht geen vertrouwen in wachtwoorden als het er echt op aan komt. Neem een medisch dossier. Zo’n dossier zou je alleen mogen openen met een veilige sleutel. Wachtwoorden zijn dat niet, ook niet als je ze over een versleutelde verbinding invoert.
Er bestaat al jaren een alternatief waarmee deze problemen zijn op te lossen: ‘public key infrastructure’. Het blijft oppassen, je bent altijd minder veilig dan je denkt, maar de meeste van de geschetste problemen zijn op te lossen door inzet van een pki. De software om dit alternatief te gebruiken is op vrijwel alle gangbare pc’s al aanwezig of eenvoudig te installeren.
Een bepaalde pki-toepassing is het ‘client-side certificate’. Het gebruik van deze techniek is voor de eindgebruiker niet moeilijk. De manier waarop het Dosis/GP-project (Dutch Open Source Information Systems for General Practitioners) deze techniek inzet illustreert het generieke gebruik van clientcertificaten. Het Dosis/GP project betreft het opzetten van standaarden en voorbeeldimplementaties voor het bieden van huisartsendiensten via internet middels open broncode-software.
Zekerheid
De infrastructuur berust op het opzetten van een onderling verbonden netwerk van kleine computers; minimaal één zo’n server per arts. Patiëntendata wordt superredundant sterk versleuteld opgeslagen over meerdere servers op meerdere plekken in het netwerk, zodat uitval van een knooppunt niet tot dataverlies leidt. Op die – extra beveiligde – servers bestaat onder meer een koppeling met het reguliere his (huisartsen informatie systeem). Patiënten kunnen daardoor met hun browser toegang krijgen tot allerhande webdiensten die artsen willen leveren, bijvoorbeeld publicatie van de openingsuren, online afspraken boeken, een online consult en zelfstandige volledige toegang tot het eigen dossier.
Cruciaal is dat er zekerheid bestaat dat dokter en patiënt zijn wie ze zeggen te zijn. Dosis vertrouwt niet op gemeenschappelijke geheimen. De arts fungeert vooralsnog als ca (certificate authority). Hij is degene die de binding tussen werkelijke en virtuele identiteit borgt door de fysieke presentie van zijn patiënt te vereisen. Dit leidt tot een certificaat bij de patiënt, wat bij voorkeur in een token wordt opgeslagen, of ten minste in een versleuteld bestand. Daarnaast heeft de patiënt een pincode om zich te wapenen tegen misbruik van zijn concrete identiteit.
Een praktijkvoorbeeld: meneer Datema wil de webdiensten van dokter Jansen gebruiken. Hij start zijn browser en tikt Jansens url in. Als hij het root-certificaat van de Dosis/GP-servers nog niet in zijn browser heeft geïnstalleerd, krijgt hij een waarschuwing dat er geen garanties zijn dat het hier inderdaad om de server van Jansen gaat. Hij kan er echter voor kiezen de site te vertrouwen omdat verificatie achteraf plaatsheeft. Nu klikt hij op het veld ‘Internetdiensten aanvragen’. Op die pagina vindt hij een aanvraagcode, die hij opschrijft. Hij moet tevens (twee keer blind) een pincode/wachtwoord invullen, die hij goed onthoudt.
Certificaat
Datema moet zich binnen twee werkdagen fysiek vervoegen bij Jansen met een wettig legitimatiebewijs. Daar wordt een kopie van gemaakt die hij tekent. Dit bewijsstuk van zijn actuele identiteit wordt gearchiveerd en het nummer van het legitimatiebewijs wordt op de server bij de aanvraagcode en pincode opgeslagen. Tevens wordt geverifieerd dat Datema patiënt is bij deze arts en dat zijn gegevens correct in het his staan. Datema bevestigt de koppeling tussen zijn virtuele identiteit (de aanvraagcode) en zijn actuele identiteit door de pincode opnieuw in te tikken. Als dit lukt, is daarmee ook aangetoond dat hij met de webserver van de arts heeft gecommuniceerd en dat het gepresenteerde certificaat dat van die server was.
Als alles klopt, geeft de dokter binnen het systeem fiat, waarna de procedure start die de persoonlijke pagina’s inclusief koppelingen met het his aanmaakt voor deze patiënt. Deze procedure genereert ook een bevestigingsbrief voor Datema. Hij heeft daarna enige werkdagen om de procedure af te ronden. De brief bevat een activeringscode en de url van de bevestigingspagina. Datema bezoekt deze pagina, voert het nummer van zijn identiteitsbewijs in, en vervolgens de activeringscode en zijn pincode. Doet hij dat meer dan twee keer fout, dan moet hij de aanvraagprocedure opnieuw starten. Als alles in orde is, volgt een welkomstpagina waarop onder meer de identificerende gegevens van alle personen te zien zijn die via Datema’s sleutel toegang hebben tot het systeem (normaliter zijn minderjarige kinderen en hijzelf). Als alles klopt, klikt Datema een ‘ok-knop’ aan.
Nu wordt binnen zijn browser een digitaal sleutelpaar gegenereerd. Zo’n sleutelpaar heeft als voornaamste kenmerk dat je met één helft een boodschap versleutelt en je de andere helft moet hebben om de boodschap te ontsleutelen. Na generatie van het sleutelpaar wordt één helft op harde schijf opgeslagen en het andere deel naar de server gezonden. Op de server wordt de sleutelhelft voorzien van een uniek kenmerk en in een bepaald formaat gegoten (een ‘signing request’). Dan wordt het certificaat – want dat is het nu – getekend door de serversoftware.
Het getekende certificaat wordt teruggezonden naar de browser. Nu kan Datema besluiten hoe en waar hij het opslaat (en of hij dat versleuteld wil doen). Aanvullend worden de publieke gegevens van het certificaat op de website van de arts gepubliceerd. Daarmee krijgen ook derden de gelegenheid om hun diensten beschikbaar te stellen aan Datema.
Veiliger
Als Datema de volgende keer de website van de dokter bezoekt en op ‘Internetdiensten’ klikt wordt – voor Datema meestal ongemerkt – het certificaat uitgewisseld met de server. Dit certificaat is door deze dokter zelf getekend en vormt daarmee het bewijs dat de patiënt die bepaalde client is – hij hoeft dus niet in te loggen, maar krijgt onmiddellijk de juiste pagina te zien. Dankzij de doorlopen procedure weet hij zeker dat het de website van de dokter is.
Deze aanpak lost een aantal problemen van gedeelde geheimen op. Het is volgens een openbaar bekende procedure geborgd dat de virtuele Datema overeenkomt met de werkelijke Datema. Het bewijs ligt bij de oorspronkelijk uitgevende huisarts of zijn opvolger in het archief. De patiënt kan met hetzelfde certificaat op alle servers van alle doktoren terecht. Die hebben dan allen de zekerheid dat Datema is wie hij zegt te zijn en kunnen de kosten voor hun diensten met zekerheid op hem verhalen.
Uitwisseling van data gaat over een sterk beveiligde verbinding, wat het vrijwel onmogelijk maakt de datastroom illegaal te bekijken. Er is geen gedeeld geheim wat kan uitlekken. De arts kent het geheime deel van Datema’s sleutel niet, maar omdat hij zijn berichten wel kan ontcijferen met de publieke helft van het sleutelpaar die hij eerder heeft opgeslagen weet hij zeker dat het bericht van Datema afkomstig is.
Dat is in ieder geval veiliger. Het nadeel van deze aanpak is dat iemand de identiteit van Datema kan stelen door het certificaat te stelen. Hij moet dan wel toegang hebben tot Datema’s computer. Er zijn verschillende maatregelen om dit te voorkomen. Je kan het certificaat opslaan in een al dan niet virtueel ‘security device’ wat je met een wachtwoord beveiligt. Je moet dan ook dat wachtwoord weer kennen. Dit wachtwoord is niet elders bekend; het is geen gedeeld geheim. Daarnaast zijn er ‘security devices’ als usb-sticks en smartcards. Deze kan de patiënt bij zich dragen of in een kluis bewaren, en ze zijn bij voorkeur beveiligd met een (eenzijdig bekend) wachtwoord.
Borglijntje
Pas als iemand zo dom is om zijn certificaat onversleuteld op te slaan en het wordt gekopieerd bestaat er kans op misbruik. Om dat te voorkomen wordt, als laatste borging tegen misbruik, binnen Dosis aanvullend ook gebruik gemaakt van een gedeeld geheim tussen arts en patiënt. Datema moet binnen Dosis/GP steeds ter bevestiging van zijn transacties de pincode die hij oorspronkelijk verzon invoeren. Dit is de allerlaatste borging voor mensen die slordig omgaan met hun certificaat en het onversleuteld op hun publiek toegankelijke harde schijf hebben opgeslagen. Wat anderen als hun levenslijn gebruiken is hier dus slechts het borglijntje.
De procedure is niet veel complexer dan degene die gebruikt wordt bij gedeelde wachtwoorden: in beide gevallen vult de gebruiker een webpagina in, volgt bevestiging en kan je vervolgens gebruik maken van de diensten. Het verschil is dat, als eenmaal de identiteit van Datema is ‘ge-echt’ door de dokter, hij niet meer hoeft in te loggen; hij krijgt simpelweg de juiste pagina te zien.
De Dosis/GP servers zijn voorzien van open brondcode-software, waaronder een voor beveiliging geoptimaliseerde Linux-variant, de Apache webserver, open ssl-software (secure sockets layer) en (delen van) open ca-software. Aan de clientkant volstaat een courante browser, die bij voorkeur hardwaretokens moet ondersteunen, al is dat geen randvoorwaarde. Op een gegeven moment worden alle gegevens over de gebruikte configuratie en implementatie via internet vrij beschikbaar gesteld.< BR>
Henk Kloepping, European Fortean Foundation en senior Unix-consultant bij Snow
