Mobile PKI Eindrapport proof-of-concept

Vergelijkbare documenten
SURFconext Cookbook. Het koppelen van Alfresco aan SURFconext. Versie: 1.0. Datum: 8 december admin@surfnet.nl

SURFconext Cookbook. Het koppelen van Wordpress aan SURFconext. Versie: 1.0. Datum: 7 november admin@surfnet.nl

Bestanden uploaden op StamrechtBV.com

Help er gaat iets mis

Snelle installatiegids voor Symbian

SURFconext Cookbook. Het koppelen van LimeSurvey aan SURFconext. Versie: 1.0. Datum: 4 december admin@surfnet.nl

Dienstbeschrijving SURFconext

Handleiding Curasoft. Het cliëntenportaal. Versie 2.0

Technische handreiking govroam

Handleiding Simon. 5 juni Schouw Informatisering B.V. Danny Cevaal. Versienummer 1.0

Handleiding voor aansluiten op Digilevering

Clientportaal handleiding Voor portaalgebruikers

Kennisnet Federatie Handleiding Migratie Sharepoint 2007/2010 naar ADFS 2.0

Technologieverkenning

Gebruikershandleiding MobiDM

Procedure activeren van de MFA applicatie op een mobiele telefoon

Financieringsverstrekkersportaal. Aansluitdocument

Autorisatierollen beheren

Gebruikershandleiding Mijn cliëntportaal

Klanthandleiding Digitale Services. Versie 1.0

Handleiding DocProof ELA

Single Sign-On in ZIVVER met Microsoft ADFS

Spam & Antivirus Admin gebruiker

Dienstbeschrijving SURFconext

Reglement Stimuleringsregeling MediaMosa 2011:

Dienst Dienstoverstijgend Federatief Groepsmanagement: SURFteams. indi

GOOGLE APPS-AUTHENTICATIE VIA DE SURFFEDERATIE

SURFconext Cookbook. Het koppelen van BigBlueButton aan SURFconext. Versie: 1.0. Datum: 1 december admin@surfnet.nl

Online invullen en beveiliging

SURFconext dienstbeschrijving

Gebruikershandleiding Cliëntportaal TMZ

Handleiding Nalevingsmodule. Gebruikershandleiding voor de nalevingsmodule van het Zorginkoopportaal

DM WEB PORTAAL Functionele handleiding 2-factor authenticatie Gebruikers. MediSoft. Versie

Handleiding Mooy Logistics Servicedesk

Handleiding (Verzender Ontvanger)

ELEKTRONISCHE HANDTEKENINGEN IN CLIENT ONLINE

Aanvragen en in gebruik nemen KPN BAPI-certificaten d-basics b.v.

Klanthandleiding. Versie 2.0

SURFdomeinen. Handleiding. Versie: 2.1. Datum: november Radboudkwartier CK Utrecht

XIMEx handleiding Gebruiker. Uw XIMEx Portal URL:

Handreiking Digipoort SMTP, POP3 en FTP Overheden

Databroker invoer NHR datasets 2018 Pacemaker- en ICD registratie. Definitief / 21 augustus 2018 / versie

Autorisatierollen beheren

Werkwijze Licenties Use2Day

Gebruikershandleiding Mijn cliëntportaal

Handleiding Installatie en Gebruik Privacy- en Verzend Module Stichting Farmaceutische Kengetallen

HANDLEIDING DOSSIER.NU. Handleiding Dossier.nu. Vertrouwelijk DOCUMENT VERSIE 1.0 DATUM CLASSIFICATIE

Handleiding Contracteermodule. Zorgaanbieders. Gebruikershandleiding voor de contracteermodule van het Zorginkoopportaal

ZorgMail Secure

Handleiding ZKM Online. Versie 2.1

MijnOffice365 Beheerdershandleiding.

Peridos. Registreren voor Zorgportaal. Datum: Landelijk beheer Peridos. Versie: 1.0

Installatiehandleiding Windows XP / Vista / Windows 7

Peridos. Registreren voor Zorgportaal. Datum: Landelijk beheer Peridos. Versie: 1.3

Implementatiekosten en baten van SURFconext. Versie: 0.5 Datum: 06/06/2013 Door: Peter Clijsters

Handleiding mijn.intertraining.nl

Gebruikershandleiding voor toegang tot Gasport

Praktijk en practices

Implementatiehandleiding idin

Handleiding website voor All in House

Handleiding voor beheerders SesamID

Gebruikershandleiding BrabantZorg cliëntportaal

TIP: Op elke pagina in SalarOnline vindt u een tekst ballon met?, zodra u hierop klikt krijgt u de help voor de betreffende pagina.

Cliënten handleiding PwC Client Portal

Handleiding: inloggen op Klantportaal

Cloud services: aantrekkelijk, maar implementeer zorgvuldig

Incura Handleiding 2-factor authenticatie (2FA)

Twee-factor-authenticatie (2FA)

Handleiding Ouderportaal

ZORGMAIL SECURE

Projectvoorstel SAN migratie NSG

Tetra Portaal Handleiding

Single Sign-On in ZIVVER met Microsoft ADFS

Handreiking Digipoort X400, SMTP, POP3 en FTP Bedrijven

STARTGIDS AUTODESK ABONNEMENTEN

Altijd en overal toegang tot en documenten. MijnOffice365 Beheerdershandleiding

HANDLEIDING VEILIG THUIS CLUSTERBEHEER

247 SERVICES APP GEBRUIKERSHANDLEIDING. Versie: 1.4a

Augustus Handleiding Subsidieportaal Uitvoering Van Beleid

Duifmelden. nl Gebruikershandleiding Automatische Aanmeld Module met de kloksystemen - Tauris - Unikon - Mega - Bricon - Benzing M1

Introductie SURFconext

Handleiding Hulp bij verbindingsinstellingen. Versie

1. Inloggen artsenportaal

WORKSPACE. Snelstarthandleiding: Eerste Stappen

FAQ-Document. Noteer voor uzelf even of het certificaat op deze werkplek of op de server geïnstalleerd is.

Gebruikershandleiding wachtwoord instellen en account ontgrendelen

How To Do VPN verbinding maken via SMS

Bestaand domein instellen Uw bestaande domeinnaam gebruiken voor Zakelijk Office 365

HANDLEIDING HUAWEI MIFI ROUTER

e-uur en UBplus Gebruikershandleiding Versie: 1.05

Handleiding. Serviceportal. Versie 1.2 Datum

Koppel je dienst aan de demo-omgeving

SURFsecureID i.c.m. Azure Conditional Access Rules. configuratie en bevindingen. Version 1.0 ( ) Peter Ruiter (2AT)

Gebruikersinstructie Mijn Bol. Voor gebruikers van Mijn Bol. Instructie

Eindrapportage resultaten Stimulering Gebruik Onderzoeker & Docent

Gebruikershandleiding VGN-Portal

MULTIFUNCTIONELE DIGITALE SYSTEMEN. Instellen en gebruiken van LDAP met Active Directory

Handleiding ABK Extra - Zoekprofielen

Deze handleiding is voor alle gebruikers die een token willen registreren voor SURFsecureID.

Transcriptie:

Mobile PKI Eindrapport proof-of-concept Versie 1.1 Datum 15 december 2009 SURFnet/Kennisnet Innovatieprogramma

Het SURFnet/ Kennisnet Innovatieprogramma wordt financieel mogelijk gemaakt door het Ministerie van Onderwijs, Cultuur en Wetenschap. Voor deze publicatie geldt de Creative Commons Licentie Attribution 3.0 Unported. Meer informatie over deze licentie is te vinden op http://creativecommons.org/licenses/by/3.0/

Managementsamenvatting Gedurende het afgelopen jaar (2009) is in het kader van het SURFnet/Kennisnet programma een proof-of-concept geïmplementeerd en uitgevoerd met de Mobile PKI technologie met deelname van een aantal op SURFnet aangesloten instellingen. In dit rapport worden de ervaringen die zijn opgedaan tijdens deze proof-of-concept uiteengezet. Voor deze proof-of-concept is een aparte identity provider (IdP) ingericht die gebruikt werd voor het verlenen van toegang tot bepaalde SURFnet diensten die alleen toegankelijk zijn voor IT beheerders van aangesloten instellingen en die een sterke vorm van authenticatie vereisen. Voor deze opzet is gekozen omdat vanwege de huidige vorm van authenticatie voor deze diensten, namelijk SMS authenticatie het eenvoudig in te passen is in de infrastructuur en aansluit bij eerdere ervaringen van participanten. Vervolgens is een aantal gebruikers van mobiele telefoons voorzien met daarin een voor Mobile PKI geschikte SIM kaart en is hen gevraagd om voor de toegang tot deze diensten gebruik te maken van deze telefoon en SIM kaart. De resultaten van de proof-of-concept zijn positief. Behoudens een aantal verbeterpunten zijn alle deelnemers enthousiast over de technologie. Hierbij valt wel op te merken dat vanwege de beperkte beschikbaarheid van test SIM kaarten de schaal van het onderzoek vrij klein is geweest en er dus voorzichtig met de resultaten omgegaan moet worden waar het de algemene toepasbaarheid van de technologie betreft. Naar aanleiding van de resultaten van de proof-of-concept wordt aan SURFnet aanbevolen om serieus naar deze technologie te kijken als authenticatiemiddel zodra deze in Nederland algemeen beschikbaar is. Daarnaast verdient het aanbeveling om indien daartoe de mogelijkheid bestaat meer ervaring op te doen in een grotere pilot. 2

Inhoudsopgave MANAGEMENTSAMENVATTING...2 INHOUDSOPGAVE...3 1. INLEIDING...4 1.1 Leeswijzer...4 1.2 Dankwoord...4 2 TECHNISCHE OPZET...5 2.1 Inleiding...5 2.2 Uitgangssituatie...5 2.3 Technische integratie...6 2.4 Mobile PKI IdP...7 2.5 Opgedane ervaringen tijdens de technische integratie...7 3. PROOF-OF-CONCEPT OPZET...8 3.1 Inleiding...8 3.2 Workflow...8 3.3 Gebruikerservaring in screenshots...9 3.3.1 Stap 1: gebruiker wil toegang verkrijgen tot een dienst... 9 3.3.2 Stap 2: gebruiker krijgt Where Are You From vraag op ESPEE... 10 3.3.3 Stap 3: E-mail adres invoeren bij Mobile PKI IdP... 11 3.3.4 Stap 4: De gebruiker authenticeert met zijn mobiele telefoon... 12 3.3.5 Stap 5: De gebruiker is ingelogd op de dienst... 13 4. GEBRUIKERSERVARINGEN...14 4.1 Inleiding...14 4.2 Samenvatting van de gesprekken...14 5. CONCLUSIES EN AANBEVELINGEN...15 5.1 Conclusies...15 5.2 Aanbevelingen...15 6. REFERENTIES...16 3

1. Inleiding Dit jaar is in het kader van het SURFnet/Kennisnet programma een technologieverkenning uitgevoerd naar het onderwerp Mobile PKI. Eerder in het jaar is een rapport opgeleverd door Novay waarin een veiligheids- en bruikbaarheidsstudie naar deze technologie is uitgevoerd [1]. Hieruit kwam naar voren dat Mobile PKI een zeer veilig authenticatiemiddel is dat een aantal mogelijke toepassingen heeft in de SURFnet en Kennisnet doelgroep. SURFnet heeft in samenwerking met Diginotar een proof-of-concept georganiseerd waarvan het doel was om praktijkervaring op te doen met deze technologie. In dit rapport worden de ervaringen die tijdens deze proof-of-concept zijn opgedaan uiteengezet. 1.1 Leeswijzer In hoofdstuk 2.3 wordt uitgelegd hoe de Mobile PKI technologie technisch is geïntegreerd met de SURFnet diensten die gebruikt zijn voor de proof-of-concept. Vervolgens beschrijft hoofdstuk 3 hoe de proof-of-concept is uitgevoerd en wat daarin van gebruikers werd verwacht. Daarna staat in hoofdstuk 4 een overzicht van de feedback die de deelnemers aan de proof-of-concept hebben gegeven. Tot slot worden in hoofdstuk 5 een aantal conclusies en aanbevelingen gegeven. 1.2 Dankwoord SURFnet wil graag de volgende personen bedanken voor hun bijdrage aan de proof-of-concept Mobile PKI: Kick Molenveld (Saxion Hogeschool) Martijn Oostdijk (Novay) René Scheffer (Stroomt) Maarten Wegdam (Novay) Bart Willems (Diginotar) Kick Willemse (Evidos) 4

2 Technische opzet 2.1 Inleiding Om de proof-of-concept te kunnen realiseren moest er een toepassing worden geïmplementeerd van de Mobile PKI technologie. Er is voor gekozen om Mobile PKI in te zetten als één van de mogelijke authenticatiemethoden voor toegang tot SURFnet diensten voor ICT beheerders. 2.2 Uitgangssituatie Bepaalde SURFnet diensten zijn alleen toegankelijk voor ICT beheerders van de aangesloten instellingen. Voorbeelden van zulke diensten zijn: SURFdomeinen hierin kunnen domeinregistraties en DNS beheerzaken worden geregeld Dashboard hierin wordt een overzicht van alle diensten die een instelling bij SURFnet afneemt gegeven SURFopzichter deze dienst maakt het mogelijk om monitoring uit te voeren op online services Op dit moment wordt toegang tot deze diensten afgeschermd door middel van een aparte identity-provider voor beheeraccounts, de BAB IdP. Deze IdP maakt geen deel uit van de SURFfederatie en is op niet-standaardwijze geïntegreerd. In de toekomst is het de bedoeling om de BAB IdP te gaan vervangen en het is wenselijk om deze op een dusdanige manier te vervangen dat een betere integratie met de SURFfederatie mogelijk wordt. De reden dat de aparte BAB IdP bestaat is dat voor de diensten die erdoor worden afgeschermd een sterkere vorm van authenticatie dan gebruikersnaam/wachtwoord vereist is. De BAB IdP maakt hiervoor nu gebruik van SMS authenticatie. Zowel omdat de wens bestaat de BAB te vervangen alsmede omdat de BAB nu al gebruik maakt van mobiele telefonie is ervoor gekozen om de proof-of-concept uit te voeren met gebruikers van de BAB en om de BAB te vervangen door een IdP die met Mobile PKI werkt. 5

2.3 Technische integratie Figuur 1 - Technische integratie van Mobile PKI In Figuur 1 staat weergegeven hoe Mobile PKI geïntegreerd is in de SURFnet authenticatie infrastructuur voor beheerdersdiensten. Centraal in de figuur weergegeven (oranje) staat SURFnet ESPEE; dit is een centrale portal waarnaar een gebruiker (geel) die toegang wil verkrijgen tot een dienst wordt doorgestuurd. In ESPEE staat geconfigureerd welke IdPs mogen worden gebruikt om toegang te verkrijgen tot een bepaalde dienst. Voorheen was dit voor beheerdersdiensten alleen de BAB IdP zodat er een automatische redirect plaatsvond rechtstreeks naar de BAB IdP en de gebruiker in feite ESPEE nooit te zien kreeg. Na authenticatie bij de IdP stuurt ESPEE de gebruiker door naar de dienst (groen). Om Mobile PKI te integreren is er een aparte Mobile PKI IdP ontwikkeld (rood omlijnd) die in ESPEE is geconfigureerd. Dit betekent dat in de proof-of-concept de gebruiker zodra hij op de ESPEE portal terecht komt een zogenaamde Where Are You From (WAYF) pagina te zien krijgt waarin de gebruiker kan kiezen welke IdP hij wil gebruiken (dit staat uitgebreider beschreven in hoofdstuk 3). 6

2.4 Mobile PKI IdP De Mobile PKI IdP is apart voor dit project ontwikkeld. Om de gebruikerservaring voor de deelnemers zoveel mogelijk te laten aansluiten bij wat ze al kenden is de workflow voor deze IdP gebaseerd op die van de BAB IdP. Om dit mogelijk te maken maakt de Mobile PKI IdP gebruik van de onderliggende database die gekoppeld is met de BAB IdP. Hierdoor worden dezelfde gebruikerskenmerken vrijgegeven door de Mobile PKI IdP als door de BAB IdP wanneer een gebruiker inlogt. Voor de achterliggende dienst maakt het dus geen verschil via welke IdP een gebruiker inlogt. 2.5 Opgedane ervaringen tijdens de technische integratie Voor de proof-of-concept kon gebruik worden gemaakt van SIM kaarten die door Diginotar ter beschikking zijn gesteld. Deze SIM kaarten zijn aangeleverd door de partij waar Diginotar de Mobile PKI op dit moment betrekt, Valimo, een Fins bedrijf. Omdat het niet mogelijk was om mee te doen met een pilot bij een Nederlandse operator moest gebruik worden gemaakt van een Finse provider (TeliaSonera). Tijdens het integreren van de Mobile PKI technologie zijn een aantal problemen geconstateerd: Het bleek soms moeilijk te zijn om de Finse SIMs betrouwbaar te registreren op een Nederlands mobiel netwerk; uiteindelijk zijn de telefoons vast ingesteld op het netwerk van KPN omdat dit de betrouwbaarste resultaten opleverde; De demo-omgeving van Valimo waarvan gebruik werd gemaakt was met name in de eerste paar maanden van het project nogal onbetrouwbaar en regelmatig niet beschikbaar; De initiële configuratie van de Valimo omgeving met name de configuratie van timeout waarden leidde ertoe dat authenticatieverzoeken soms mislukten; De PKI certificaten die gekoppeld waren aan de RSA sleutels op de SIMs en die waren uitgegeven door een Valimo demo-ca bevatten codes die niet werden herkend door de standaardtooling waardoor het onmogelijk werd om betrouwbaar de met de RSA sleutels gezette digitale handtekeningen te controleren. Gelukkig is het mogelijk gebleken om deze problemen op te lossen of om een geschikte workaround te implementeren. Het heeft echter wel tot de nodige vertraging geleid bij de uitvoering van de proof-of-concept. 7

3. Proof-of-concept opzet 3.1 Inleiding Doel van de proof-of-concept was om gebruikers ervaring te laten opdoen met de Mobile PKI technologie en om hen hierover feedback te laten leveren (waarover meer in hoofdstuk 4). In dit hoofdstuk wordt beschreven hoe de proof-of-concept er voor gebruikers uit heeft gezien. 3.2 Workflow Onderstaand diagram laat de workflow zien zoals deze voor de gebruiker is ingericht: Figuur 2 Gebruikersworkflow voor de proof-of-concept 8

In dit diagram is globaal te zien hoe de communicatie verloopt tussen de verschillende componenten. Om het diagram compact te houden is de technische uitwisseling tussen de Mobile PKI IdP en de Mobile Signature Service (MSSP) uit het diagram weggelaten. 3.3 Gebruikerservaring in screenshots Hieronder is de gebruikerservaring in screenshots weergegeven: 3.3.1 Stap 1: gebruiker wil toegang verkrijgen tot een dienst Onderstaand screenshot laat als voorbeeld de inlogpagina van SURFdomeinen zien: Figuur 3 - Inlogpagina SURFdomeinen Een gebruiker klikt op deze pagina op Inloggen Federatie. Hierna wordt de gebruiker door middel van een HTTP-redirect doorgestuurd naar ESPEE. 9

3.3.2 Stap 2: gebruiker krijgt Where Are You From vraag op ESPEE In het volgende screenshot is de WAYF pagina van ESPEE te zien: Figuur 4 - Where Are You From pagina van ESPEE Hier kiest de gebruiker uit de lijst de IdP; in dit geval zal dat de Mobile PKI IdP zijn zoals in onderstaande figuur te zien is: Figuur 5 - Lijst met IdPs Vervolgens drukt de gebruiker op Bevestig en wordt hij doorgestuurd naar de geselecteerde IdP. 10

3.3.3 Stap 3: E-mail adres invoeren bij Mobile PKI IdP Om de gebruiker te kunnen identificeren en het bijbehorende mobiele nummer op te zoeken zal de Mobile PKI IdP nu vragen om het e-mail adres van de gebruiker: Figuur 6 - Gebruiker voert e-mail adres in Nadat de gebruiker zijn e-mail adres heeft ingevoerd drukt hij op Verstuur Authenticatie Request om de authenticatie te starten. Hierop zal de Mobile PKI IdP een transactiecode laten zien en de gebruiker vragen om op Proceed te drukken zodra deze zijn mobiele telefoon bij de hand heeft: Figuur 7 - De Mobile PKI IdP laat de transactiecode zien 11

3.3.4 Stap 4: De gebruiker authenticeert met zijn mobiele telefoon Er wordt nu een verzoek tot authenticatie naar de mobiele telefoon van de gebruiker gestuurd. Dit ziet er als volgt uit: Figuur 8 - Interactie met de gebruiker op de mobiele telefoon 12

Achtereenvolgens gebeurt er het volgende: 1. De gebruiker krijgt een melding dat er data ondertekend moet worden (in Mobile PKI termen heet dit bericht: data-to-display) (eerste plaatje) 2. De gebruiker krijgt de data te zien die ondertekend gaat worden (in Mobile PKI termen: data-to-sign) (tweede plaatje) 3. De gebruiker wordt gevraagd om zijn authenticatie PIN-code (derde plaatje) 4. De gebruiker toetst zijn authenticatie PIN-code in en drukt op Send om de authenticatie af te ronden (vierde plaatje) De authenticatiehandtekening wordt nu verstuurd naar de Mobile PKI IdP die vervolgens bij een succesvolle authenticatie de attributen van de gebruiker zal vrijgeven aan ESPEE die deze gegevens weer doorstuurt naar de dienst waarna de gebruiker toegang krijgt tot de dienst. Het transport van de attributen verloopt in alle gevallen via redirects en dus via de browser van de gebruiker. 3.3.5 Stap 5: De gebruiker is ingelogd op de dienst Onderstaand screenshot laat zien dat de gebruiker succesvol is ingelogd op de dienst: Figuur 9 - De gebruiker is succesvol ingelogd op SURFdomeinen 13

4. Gebruikerservaringen 4.1 Inleiding In dit hoofdstuk wordt ingegaan op de gebruikerservaringen die zijn opgedaan tijdens de proofof-concept. Op verschillende tijden hebben de volgende personen gebruik gemaakt van de Mobile PKI technologie: Kick Molenveld (Saxion Hogeschool) Martijn Oostdijk (Novay) René Scheffer (Stroomt) Na afloop van de proof-of-concept is met deze personen in een 1-op-1 gesprek besproken hoe hun ervaringen waren. Hieronder is een samenvatting van hun opmerkingen weergegeven. 4.2 Samenvatting van de gesprekken Allereerst is de gebruikers gevraagd wat ze vonden van het gebruiksgemak van deze technologie. Zonder uitzondering gaven alle gebruikers aan dat ze de technologie zeer gebruiksvriendelijk vonden. In vergelijking met SMS authenticatie waarbij ook gebruik wordt gemaakt van mobiele telefoons vinden ze Mobile PKI duidelijk prettiger in gebruik omdat er geen codes hoeven worden overgetikt van de telefoon op de computer. Er was wel wat kritiek op de workflow die tijdens de proof-of-concept werd gebruikt: Het feit dat op de telefoon apart de data-to-display en de data-to-sign werden getoond ervoeren gebruikers als verwarrend Dat er nog een keer apart op proceed moest worden gedrukt (zie Figuur 7 in 0) vonden gebruikers storend, het zou volgens hen beter zijn om dit te combineren met het invoeren van het e-mail adres (zie Figuur 6 in 3.3.3) Het was onduidelijk dat nadat op proceed was gedrukt de server stond te wachten tot er een antwoord van de mobiele telefoon terug was gestuurd; ze gaven aan dat een apart wachtscherm hier wenselijk zou zijn Gebruikers gaven ook aan dat ze soms problemen hadden om de mobiele telefoon te registreren op het mobiele netwerk (zie ook 2.5). Daarnaast werd er door één gebruiker opgemerkt dat het niet duidelijk was hoe hij een authenticatie zou moeten annuleren. Hij vond het niet voor de hand liggen dat hij hiervoor op de ophang knop van de telefoon moest drukken. Tot slot ervoeren gebruikers het als storend dat er na een succesvolle authenticatie nog een SMS naar de telefoon werd verstuurd om aan te geven dat de authenticatie gelukt was. 14

5. Conclusies en aanbevelingen 5.1 Conclusies De proof-of-concept is met aanzienlijke vertraging succesvol afgerond. Verder bleek dat gebruikers erg enthousiast zijn over deze technologie en dat de uiteindelijke technische integratie vrij eenvoudig te realiseren was. Er bestaan echter nog wel een aantal wensen ten aanzien van extra mogelijkheden op het technische koppelvlak met de MSSP server; vanwege een aantal tekortkomingen in de implementatie van de omgeving waarmee getest is was het niet mogelijk om alle mogelijkheden van de technologie ten volle uit te testen. Tot slot was de schaal van de proof-of-concept qua aantal gebruikers dat ervaring heeft opgedaan met de technologie (afgezien van de SURFnet medewerkers die aan het project hebben gewerkt) vrij klein, waardoor het moeilijk in te schatten is of de uitkomsten algemeen van toepassing zijn. 5.2 Aanbevelingen De Mobile PKI technologie is erg geschikt als sterk authenticatiemiddel en gebruikers ervaren de technologie als prettig in het gebruik. Het valt dan ook aan te bevelen om zodra de technologie in Nederland algemeen beschikbaar is deze in te zetten voor (SURFnet) diensten waarvoor sterke(re) authenticatie een vereiste is. Om de gebruikerservaring te verbeteren verdient het aanbeveling om de door gebruikers genoemde minpunten (zie 0) aan te pakken; een eerste inventarisatie van deze punten geeft aan dat het redelijk eenvoudig zou moeten zijn om hierin verbetering aan te brengen. Gezien de kleine schaal waarop nu de proof-of-concept is uitgevoerd verdient het tot slot nog aanbeveling om op een grotere schaal een pilot uit te voeren. Een van de deelnemende instellingen aan de proof-of-concept heeft in ieder geval aangegeven hiervoor open te staan. 15

6. Referenties [1] Mobile PKI Een technologieverkenning naar veiligheid en gebruik van mobiele authenticatietechnologie, Martijn Oostdijk en Maarten Wegdam, SURFnet/Kennisnet project, oktober 2009 http://www.surfnetkennisnetproject.nl/attachments/session=cloud_mmbase+2074112/r apport_ts_mobile_pki_v2.0.pdf 16