Mobile PKI. Een technologieverkenning naar veiligheid en gebruik van mobiele authenticatietechnologie. November 2009

   

     

Mobile PKI    Een technologieverkenning naar veiligheid en gebruik van mobiele authenticatietechnologie                              November 2009   Auteurs: Martijn Oostdijk, Maarten Wegdam (Novay, i.o.v. SURFnet) 

Mobile PKI voor SURFnet Een technologieverkenning naar veiligheid en gebruik van mobiele authenticatietechnologie voor SURFnet.

Colofon Datum : Versie : Verandering : Project referentie: Novay referentie : Bedrijfsreferentie : URL : Toegangsrechten : Status : Redacteur : Bedrijf : Auteur(s) :

V O O R

D E Z E

5 november 2009 2.0 TS Mobile PKI Final SURFnet Martijn Oostdijk, Maarten Wegdam

P U B L I C A T I E

G E L D T

D E

C R E A T I V E

“ A T T R I B U T I O N - N O N C O M M E R C I A L - S H A R E M E E R

I N F O R M A T I E

O V E R

D E Z E

L I C E N T I E

A L I K E I S

T E

C O M M O N S 3 . 0

L I C E N T I E

N E T H E R L A N D S ” .

V I N D E N

O P

H T T P : / / C R E A T I V E C O M M O N S . O R G / L I C E N S E S / B Y - N C - S A / 3 . 0 / N L /

Management Samenvatting Een GSM/UMTS telefoon heeft een SIM kaart. Dit is een gestandaardiseerde smartcard, die de mobiele operator aan de gebruiker geeft en primair gebruikt wordt om de gebruiker te authenticeren op het mobiele netwerk. Deze SIM kaart biedt echter meer mogelijkheden, zo kunnen er op een veilige manier sleutels op gezet worden die vervolgens gebruikt kunnen worden voor online authenticatie en digitale handtekeningen. Gebruikte termen hiervoor zijn Wireless PKI en Mobile PKI. Dit rapport is een assessment van Mobile PKI technologie, en de mogelijkheden hiervan voor authenticatie in het onderwijs. De nadruk ligt hierbij op de veiligheid en de toepassingen binnen het onderwijs, en in het bijzonder toepassingen bij de SURFfederatie. Mobile PKI werkt op basis van versleutelde SMSjes, waarbij de gebruiker toestemming geeft tot authenticatie of digitale handtekening via de mobiele telefoon, beveiligd door een PIN-code die, typisch, per transactie opnieuw moet worden ingetoetst. De gebruikte standaarden op de mobiele telefoon bestaan al heel lang, en werken op alle telefoons. Voordelen ten opzichte van sommige andere veilige authenticatiemiddelen zijn dat er geen apart authenticatiedevice nodig is, en dat er geen installatie van software nodig is, noch op de telefoon noch op andere client devices zoals een PC. Ook hoeven er geen codes overgetikt te worden, zoals bv SMS one-time-passwords, wat de gebruikersvriendelijkheid ten goede komt. Eventueel op de PC geïnstalleerde malware zoals virussen of keyloggers hebben geen invloed op Mobile PKI. In dit rapport wordt ingegaan op de vraag of Mobile PKI een veilig authenticatiemiddel is. De belangrijkste threat die uit de analyse kwam is een “Man-in-the-Middle” 1 attack op het Internet kanaal, maar in vergelijking met andere authenticatiemiddelen en gegeven het soort toepassingen in het (hoger) onderwijs zien de auteurs van dit rapport Mobile PKI als meer dan veilig genoeg. De belangrijkste kanttekeningen die we plaatsen bij de Mobile PKI technologie zijn niet van technologische of veiligheidsaard, maar gaan meer over de kosten en het business model. Mobile PKI technologie wordt op dit moment alleen nog voor beperkte pilots ingezet in Nederland, dus de kosten zijn nog moeilijk in te schatten. Maar deze zouden, zolang er geen andere grootschalige toepassing voor Mobile PKI is, voor veel toepassingen in het onderwijsveld wel eens te hoog kunnen liggen. Gerelateerd hieraan is het business model. Aangezien de SIM kaart eigendom is van de mobiele operator, kan deze technologie alleen gebruikt worden met medewerking van de operator. Bij grootschalig gebruik betekent dit ook dat alle operators moeten meewerken. De eindconclusie van dit rapport is dat Mobile PKI een veilig authenticatiemiddel is dat op den duur breed gebruikt kan worden in het onderwijs in Nederland. Voor de kortere termijn is vanwege a) verwachte kosten, b) onvoldoende zicht op het business model en c) beperkte ondersteuning door mobiele operators Mobile PKI alleen in te zetten voor diensten die door beperkte groepen werknemers worden gebruikt en bovendien hoge veiligheidseisen hebben. Voor uitrol naar studenten en algemene authenticatie voor de SURFfederatie of andere grootschalige SURFnet, Kennisnet of andere diensten lijkt de tijd nog wat vroeg. In de tussentijd kan wel overwogen worden SMS one-time-password meer te gaan gebruiken voor step-up authenticatie of password reset omdat dit goedkoper is en gebruikers klaar stoomt voor MobilePKI. 1

Een Man-in-the-Middle attack is een aanval waarbij een kwaadwillende het internetverkeer tussen twee partijen kan onderscheppen en/of kan wijzigen; dit stelt de kwaadwillende in staat om communicatie af te luisteren en om de inhoud van berichten voor zijn eigen doeleinden te veranderen.

T S

M O B I L E

P K I

V

Inhoudsopgave M an age m en t S a men va t t in g 1 Inleid ing 1.1 Achtergrond 1.2 Mobile PKI in de praktijk 1.3 Doel, focus en terminologie 1.4 Leeswijzer 2 State- of-the-art 2.1 Waar reeds gebruikt 2.2 Standaarden 2.2.1 Smartcard standaarden 2.2.2 SIM kaart standaarden 2.2.3 PKI standaarden 2.2.4 Elektronische handtekening standaarden 2.2.5 Mobile Signature Service (MSS) 2.3 Conclusie 3 A rch itect uu r 3.1 Processen 3.2 Rollen 3.3 Registratieproces 3.4 Authenticatieproces 3.5 Technische analyse van een aantal koppelvlakken 3.5.1 Koppelvlak tussen AP en MSSP via Internet 3.5.2 Koppelvlak tussen Mobiel en SIM 3.6 Conclusie 4 V e i l i g h e i d s a n a l ys e 4.1 Een ad-hoc bedreigingsanalyse 4.2 Beveiligingseisen vanuit de ETSI standaard 4.3 Beveiligingseisen vanuit het Common Criteria protectieprofiel 4.4 Conclusie 5 T oe pas s ing vo o r hog er on de rw ijs 5.1 Huidige situatie: gebruikersnaam/wachtwoord 5.2 Criteria voor het gebruik Mobile PKI 5.3 Potentiële diensten voor gebruik Mobile PKI 6 C o nc l us ies en a an be ve l i n ge n Re fer ent ies

T S

M O B I L E

P K I

v 1 1 1 3 4 5 5 6 6 7 8 9 10 11 12 12 13 13 14 16 16 17 17 19 19 22 24 25 26 26 26 26 28 32

VII

1 Inleiding

1.1

A c hte rg ron d

Het gebruik van elektronische diensten vereist vertrouwen bij aanbieders en afnemers. Dit vertrouwen wordt in de praktijk gefaciliteerd door beveiligings-, toegangs- en identiteitsmanagement technieken zoals het authenticeren van partijen en het ondertekenen van documenten en transacties door partijen met behulp van een elektronische handtekening. Voor authenticatie en ondertekening zijn verschillende middelen beschikbaar. Bijvoorbeeld gebruikersnaam / wachtwoord combinatie of een smartcard of smart USB token. De kwaliteit van zo’n middel wordt met name bepaald door de mate van veiligheid (fraudebestendigheid) en de gebruiksvriendelijkheid van het middel. SURFnet biedt verscheidene diensten aan waarvoor authenticatie en soms ook een handtekening nodig is. Met name geldt dit voor de SURFfederatie, die het mogelijk maakt voor studenten en medewerkers in het hoger onderwijs om toegang te krijgen tot een breed scala aan online diensten gebruikmakend van hun instellingsaccount. Dit gaat in verreweg de meeste gevallen met behulp van een gebruikersnaam/wachtwoord. Vanwege phishinggevoeligheid en andere redenen is dit een niet erg veilige manier van authenticeren. Mobile PKI 2 is een technologie die de belofte in zich heeft om mensen op een veilige en relatief gebruikersvriendelijke manier te authenticeren. Mobile PKI maakt hiervoor gebruik van de SIM/USIM kaart (hierna genoemd SIM kaart) die in GSM/UMTS telefoons aanwezig is. Deze SIM kaart is eigendom van de mobiele operator en wordt primair gebruikt voor het authenticeren van een mobieltje op het mobiele netwerk. De mobiele operator kan echter ook extra applicaties op deze SIM kaart installeren, al dan niet van third parties. Mobile PKI maakt hiervan gebruikt door een applicatie te installeren die het mogelijk maakt om gebruikers te authenticeren voor internet diensten, en voor het zetten van elektronische handtekeningen. Een groot voordeel van Mobile PKI is dat de overgrote meerderheid van de doelgroep van SURFnet al beschikt over een mobiele telefoon, en dat die telefoons vrijwel allemaal geschikt zijn voor Mobile PKI. Een tweede voordeel is dat Mobile PKI een gestandaardiseerde technologie is, wat zowel goed is voor de veiligheid (want open) als de interoperabiliteit. 1.2

Mobile PK I in de praktijk

Mobile PKI wordt in het kader van een pilot getest door opdrachtgever SURFnet. Gebaseerd op deze pilot beschrijven we hier hoe Mobile PKI in de praktijk werkt. Mobile PKI vereist een geschikte SIM kaart. Dit betekent met name dat er voldoende cryptografische rekenkracht in zit, voldoende geheugen in zit, en dat er de juiste software op de SIM geïnstalleerd is. Deze software is een zogenaamde SIM toolkit applicatie, waarvoor in de pilot de VMAC applicatie van Valimo 3 wordt gebruikt. Zie Figuur 1 voor een foto van de gebruikte SIM, waarop te zien is hoe klein deze SIM kaart is, en ook het zogenaamde IMSI nummer te zien is die een SIM kaart uniek identificeert.

2 3

Ook wel Wireless PKI of SIM-based authentication genoemd. Op het Web is Valimo Wireless Ltd. te vinden op http://www.valimo.com/.

T S

M O B I L E

P K I

1

Figuur 1: Foto van SIM kaart.

Het typische gebruiksscenario houdt in dat iemand op zijn PC een online dienst gebruikt waarvoor hij zich moet authenticeren danwel een elektronische handtekening moet zetten. Vanuit het gezichtspunt van een gebruiker verloopt dit als volgt: 

De authenticatie dienst verstuurt ‘data to display’ en ‘data to sign’ 4 . Deze worden aan de gebruiker getoond die ze met “ok” moet bevestigen. Deze data wordt als SMSjes naar de telefoon gestuurd, maar dit is onzichtbaar voor de gebruiker. De schermen verschijnen vanuit het gebruikersperspectief ‘vanzelf’, en de gebruiker hoeft alleen maar op “ok” te drukken (hij hoeft geen menu’s te doorlopen etc).



Hierna moet de gebruiker zijn authenticatie PIN invoeren, waarna de SIM toolkit applicatie een aantal SMS berichten verstuurt (afhankelijk van de instellingen van de telefoon kan de gebruiker gevraagd worden hier toestemming voor te verlenen, maar standaard merkt de gebruiker hier niets van).



Nadat de gebruiker zich succesvol geauthenticeerd heeft (danwel een handtekening heeft gezet), ontvangt de gebruiker ter informatie nog een bevestigingsbericht per SMS.

De screenshots in Figuur 2 geven een beeld van het authenticatieproces.

4

In de voorbeelden in dit rapport worden steeds letterlijk die ASCII strings ‘data to display’ en ‘data to sign’ gebruikt. Voor authenticatie zal het tweede bericht vervangen worden door een niet te voorspellen rij tekens. Voor ondertekening zal het tweede bericht vervangen worden door een kenmerk of een fragment van het te ondertekenen document of door bijvoorbeeld een transactienummer als het gaat om goedkeuring van een transactie.

2

N O V A Y

Figuur 2: Screenshots van stappen tijdens transactie.

In vergelijking met andere veilige authenticatiemiddelen is Mobile PKI relatief gebruikersvriendelijk. Er hoeft bijvoorbeeld geen code te worden overgetikt, zoals bijvoorbeeld het geval is bij de op smartcard gebaseerde bankcalculators die door Nederlandse banken worden gebruikt (de ”Random Reader” van de Rabobank of de “E.dentifier” van de ABN-AMRO) of bij SMS one-time-password (SMS-OTP) oplossingen die ook met een mobiele telefoon werken. Ook hoeft er geen client software geïnstalleerd te worden. 1.3

D o e l , f o cus en t er m in o lo g ie

Doel van dit rapport is een analyse te maken van de bruikbaarheid van Mobile PKI technologie voor, met name, de SURFfederatie. Hierbij ligt de focus op de veiligheidsen architecturele aspecten van deze technologie. Daarnaast maken we ook een inschatting van welke soort applicaties op de kortere termijn baat kunnen hebben bij deze technologie. Gegeven de hoeveelheid beschikbare resources voor dit rapport, maken we met name gebruik van bestaand materiaal, en de quickscan methodiek. Over de gebruikte terminologie moet nog wel vermeld worden: veel van de geraadpleegde bronnen zijn zeer technisch van aard. Dit geldt met name voor de verschillende standaardisatiedocumenten. Het is gebruikelijk om in zulke standaardisatiedocumenten een lange lijst afkortingen te introduceren en deze te gebruiken in de rest van het document zodat een zekere abstractie ontstaat en de standaard op meerdere implementaties toegepast kan worden. In dit document gebruiken we echter de concrete namen zoals die in dagelijkse communicatie gebruikelijk zijn. We gebruiken in dit document gewone terminologie zoals SIM, mobiel, etc. in plaats van

T S

M O B I L E

P K I

3

MSCA en MSCD. Desondanks zullen delen van dit rapport niet goed leesbaar zijn zonder de juiste technische achtergrond. Hoewel dit rapport in het Nederlands is opgesteld, is er bewust voor gekozen Engelse vaktermen, zoals bijvoorbeeld Identity Provider, assertions en Service Provider niet te vertalen. 1.4

L ee sw ijze r

Hoofdstuk 2 beschrijft de state-of-the-art op het gebied van Mobile PKI, inclusief een overzicht van de relevante standaarden en voorbeelden uit andere landen waar deze techniek al gebruikt wordt. Hoofdstuk 3 beschrijft de architectuur, en analyseert de meest relevante koppelvlakken. Hoofdstuk 4 doet een veiligheidsanalyse. Hoofdstuk 5 analyseert, gebaseerd op de uitkomsten van de eerdere hoofdstukken, wat de mogelijke toepassingen zijn voor het onderwijs. Hoofdstuk 6 bevat na een korte vergelijking van Mobile PKI met wat andere veelgebruikte authenticatiemiddelen, de conclusies en aanbevelingen. De auteurs van dit rapport danken Roland van Rijswijk (SURFnet), Joost van Dijk (SURFnet), Kick Willemse (Evidos / Diginotar) en Bram Sniekers (Diginotar) voor hun input en feedback.

4

N O V A Y

2 State-of-the-art Mobile PKI, met een centrale rol voor de SIM kaart, bestaat als concept al minstens sinds 2001. Het op grote schaal toepassen van Mobile PKI is echter iets wat pas recentelijk (vooral 2008, 2009) lijkt te gebeuren. De in de SURFnet pilot te gebruiken Mobile PKI oplossing van Valimo duikt daarbij de laatste paar jaren frequenter op. Een snelle scan levert een overzicht op waar Mobile PKI al ingezet wordt. De resultaten van deze scan staan beschreven in het eerste deel van dit hoofdstuk. Veel van de technologieën en protocollen die gebruikt worden door Mobile PKI zijn in publiek beschikbare open standaarden beschreven. Het tweede deel van dit hoofdstuk beoogt een beeld te geven van deze standaarden en hoe deze worden toegepast om tot een Mobile PKI oplossing te komen. Een precieze beschrijving van de architectuur, en hoe de beschreven standaarden daar in passen, is gegeven in hoofdstuk 3. 2.1

W a ar ree ds ge br u ikt

Tabel 1 geeft een chronologisch overzicht van een quick scan naar persberichten en andere (commerciële) aankondigingen rond Mobile PKI producten.

2001

Vodafone doet een eerste trial in Engeland met mobile signatures. [Link]

2001

Common Criteria protectieprofiel [3] gepubliceerd.

2002

Schlumberger (tegenwoordig onderdeel van Gemalto) publiceert een Common Criteria security target voor een Secure Signature Creation Device in de vorm van een Java Card applet. [Link]

2003

ETSI standaarden voor Mobile PKI [8][9][10][11] gepubliceerd.

2006

Giesecke & Devrient voert samen met Vodafone een Mobile PKI pilot uit met G+D’s StarSIM product. [Link]

2006

TeliaSonera en Valimo kondigen Tunnistuspalvelu Pro/Plus product aan. [Link]

2006

Elisa biedt gebruikers de mogelijkheid om hun Finse eID te koppelen aan een SIM kaart 5 . Technologie komt van SmartTrust en Valimo. [Link]

2007

Turkcell gebruikt Valimo oplossing voor telebankieren (minstens 9 banken initieel, maar in oktober 2008 zijn dit al 19 banken). [Link]

2007

Telefonica sluit contract met Ericsson voor Mobile Signatures. Technologie komt van Valimo. [Link]

2007

Valimo partnerschap met Gemalto rond VMAC product [Link]

2007

Technologie provider EMT uit Estland introduceert Mobiil-ID [Link]

2008

Experian en Keynetics voeren in Frankrijk een pilot uit met Valimo technologie. [Link]

2008

Pilot Vodafone en Banco Sabadell. [Link]

5

De SmartTrust oplossing wordt ook genoemd in [15], waarin een alternatieve manier om nationale identiteitskaarten te gebruiken wordt voorgesteld.

T S

M O B I L E

P K I

5

2009

Oberthur neemt de VMAC applet op in Oberthur’s SIM portfolio. [Link]

2009

Samenwerking Telenor en Valimo. [Link]

2009

Samenwerking LatTelecom en Valimo. [Link]

2009

Overheidsinitiatief Oostenrijk mobiele handtekeningen in Q4. [Link]

Tabel 1: Aankondigingen van Mobile PKI pilots en dergelijke.

Een gedegen marktanalyse 6 valt buiten de scope van dit rapport, maar een aantal zaken valt op bij bestudering van de tabel. De eerste pilots vinden plaats in 2001, nog voor de ETSI standaarden gedraft zijn. Wel zijn er rond die tijd al Common Criteria protectieprofielen voor verschillende vormen van signature technologie. Daarna zijn er een aantal pilots met SIM kaart leveranciers en mobiele operators (samen met andere technische partijen zoals CA’s, integrators). In een aantal landen hebben kleinschalige pilots intussen plaats gemaakt voor grote pilots die zich op de consumentenmarkt richten. De laatste paar jaar wordt Mobile PKI ook echt uitgerold, vooral in Scandinavië 7 , de Baltische staten 8 en Turkije. Mobiele operators spelen steeds een belangrijke rol. Soms speelt ook de overheid een rol, waar het gaat om zogenaamde citizen-to-government (C2G) transacties die via Mobile PKI gefaciliteerd worden. De grote SIM kaart leveranciers (Gemalto, Oberthur, Giesecke & Devrient) werken allemaal samen met Valimo voor het aanbieden van Mobile PKI. 2.2

S t a nd aa rde n

2 . 2 .1 S m a rt ca rd st an daa rde n

Een sleutelpositie in Mobile PKI wordt ingenomen door een smartcard: de SIM. Alle SIM kaarten voldoen aan de ISO 7816-4 standaard [13]. Sommige SIM kaarten zijn Java Card [14] kaarten wat vooral personalisatie voor de mobiele operator makkelijker maakt. Het managen van applicaties op zulke Java Card kaarten is beschreven in Global Platform [12]. 

ISO 7816-1, 2, 3, 4, …: Deze ISO standaarden (zie [13]) beschrijven smartcards. Beginnend op zeer laag niveau (de dimensies van een smartcard, de plaats van de contact chip, de betekenis van contactjes, hoe vaak mag de plastic kaart mag buigen voordat hij breekt), via het transport protocol (zogenaamde Transport Protocol Data Units: TPDU’s), naar deel 4 waarin Application Protocol Data Units beschreven worden. Een smartcard die aan ISO 7816-4 voldoet kan overweg met gestandaardiseerde commando’s (bijvoorbeeld navigatie door een bestandssysteem zoals dat ook op een SIM kaart zit). Lagen hoger in de ISO 7816 stack van standaarden betreffen inter-industrie applicatie functionaliteit. Bijvoorbeeld, ISO 7816-8 en 15 beschrijven samen hoe een PKI token geïmplementeerd zou kunnen worden met hulp van de lagere ISO 7816 lagen (standaard commando’s voor authenticatie, signatures, resp. bestandssysteem voor uitlezen certificaten, en overlappen met de PKCS standaarden, hieronder beschreven). De ETSI standaarden voor Mobile PKI (ook hieronder beschreven) maken hier echter niet noodzakelijk gebruik van.

6

De presentatie van Bill Nagel van Forrester Research op RSAcon’08 geeft aan dat het om een niet-triviale analyse gaat. Zie https://365.rsaconference.com/docs/DOC-1172. 7 Valimo Wireless Ltd is een Fins bedrijf. 8 Zie de website van het Baltische WPKI forum http://wpki.eu.

6

N O V A Y



Java Card: Java Card (zie [14]) is een Java variant (dus een defacto Sun “standaard”) voor programmeerbare smartcards. De taal is veel beperkter dan standaard Java, zowel in syntax features als in API. Java Card biedt een multiapplication platform (meerdere zogenaamde applets op een kaart, waarvan er overigens altijd maar een actief is). Een aantal features van Java Card vindt men juist niet in standaard Java, vooral op het gebied van beveiliging en het geheugenmodel. Java Card biedt een appletprogrammeur de mogelijkheid om de cryptografische API te gebruiken, maar of dit ook hardwarematig wordt ondersteund hangt van de specifieke smartcard af.



Global Platform: De Java Card standaard zegt niets over applicatiebeheer (bijvoorbeeld het laden van nieuwe applicaties). Global Platform (GP, voorheen Visa Open Platform, zie [12]) repareert dit. GP is in principe onafhankelijk van Javacard (de standaard praat over applicaties, niet over Java Card applets), maar in de praktijk kan GP gezien worden als Java Card applicatiemanagement. Daarnaast biedt GP ook functionaliteit aan applets waardoor deze bepaalde (security gerelateerde) taken over kunnen laten aan het platform. Denk hierbij aan het opzetten van een end-to-end beveiligde verbinding met de terminal (of achterliggende systemen). Een Java Card SIM zal doorgaans voldoen aan GP.

2 . 2 .2 SIM kaa rt s tan da ar de n

De SIM kaart is eigendom van de mobiele operator maar bevindt zich in het toestel van de client. De SIM is veilig in de zin dat gegevens door de mobiele operator op de SIM opgeslagen kunnen worden waarbij de mobiele operator de toegang tot deze gegevens kan beperken (zowel de gebruiker als potentieel kwaadaardige software geïnstalleerd op de mobiele telefoon van de gebruiker kunnen niet bij deze gegevens komen). GSM SIM kaarten houden zich noodzakelijkerwijs aan standaarden. Immers, een SIM kaart moet in elk GSM toestel kunnen werken. De specifieke functionaliteit van GSM SIM kaarten is beschreven in ETSI standaarden. De originele ETSI standaard, GSM 11.11, maakt het mogelijk voor de operator om bestanden op de SIM te plaatsen die door het toestel bewerkt kunnen worden en biedt de mogelijkheid voor het toestel om zich op het netwerk richting operator te authenticeren. Nieuwere (Java Card) SIM kaarten kunnen ook zogenaamde SIM Toolkit applicaties bevatten.

T S



ETSI: SIM (GSM 11.11): Deze standaard (zie [5]) beschrijft het authenticatiemechanisme dat door de SIM gebruikt wordt om de mobiele telefoon toegang te verlenen tot het netwerk. De SIM gebruikt hiervoor een symmetrische sleutel die niet uitgelezen kan worden. Daarnaast beschrijft GSM 11.11 een eenvoudig, statisch ISO 7816 bestandssysteem (de standaard schrijft voor welke bestanden aanwezig zijn). Toegang tot bestanden kan op verschillende manieren beperkt worden (bijvoorbeeld alleen leesbaar nadat gebruiker PIN heeft ingegeven, of alleen leesbaar door de Mobiele Operator (MO) na authenticatie). In dit bestandssysteem kan de operator eigenschappen van de SIM vastleggen die door het GSM toestel gelezen en verwerkt kunnen worden. Bepaalde bestanden zijn specifiek voor de gebruiker bedoeld (denk aan een telefoonboek).



ETSI: SIM Application Toolkit (GSM 11.14): Deze standaard (zie [6]) definieert een raamwerk bovenop Java Card voor zogenaamde SIM Toolkit applets. Deze Java Card applets bestaan onafhankelijk van het GSM 11.11 bestandssysteem (waardoor oudere mobiele telefoons de applets op een GSM 11.14 SIM zullen negeren). Op nieuwere handsets zullen applets regelmatig gepolld worden door de handset waardoor een SIM Toolkit applet (1) GUI menu’s kan toevoegen en

M O B I L E

P K I

7

(2) kan reageren op events, zoals het binnenkomen van bepaalde SMS berichten of selectie van menu items door de gebruiker. De SIM toolkit applets worden beheerd via Global Platform waarbij ook expliciet management over-the-air (OTA) door de mobiele operator is toegestaan. De meeste mobiele toestellen plaatsen de door SIM Toolkit applets gegenereerde menu’s in een “Extra’s” menu. Voor het gebruiksgemak zijn er drie grote voordelen: Ten eerste, de MO kan op afstand applicatiebeheer doen (nieuwe versies installeren, etc.), ten tweede kunnen SIM applicaties reageren op berichten uit het netwerk zonder dat de gebruiker hiermee lastig gevallen wordt. Ten derde, kan een SIM applicatie de GUI van het toestel gebruiken en heeft zo’n applicatie voorrang op applicaties die op niet op de SIM staan (bijvoorbeeld MIDlets 9 ). 

Na het GSM tijdperk (de zogenaamde 2e generatie mobiele telefoons) leven we ten tijde van het schrijven van dit rapport in het UMTS tijdperk (de zogenaamde 3e generatie mobiele telefoons). Voor zowel GSM 11.11 als voor GSM 11.14 bestaan UMTS equivalenten gepubliceerd door 3GPP die respectievelijk de USIM en de USAT beschrijven.

Onduidelijk is welk percentage van SIM kaarten dat in gebruik is gebruik kan maken van SIM toolkit applicaties ten behoeve van Mobile PKI. Hoewel het overgrote deel van uitgegeven SIM kaarten SIM application toolkit ondersteunen, zullen niet alle SIM kaarten over hardwareondersteuning voor cryptografie beschikken. 2 . 2 .3 PK I st an da ar de n

Los van de smartcard en mobiele telefonie standaarden is veel van de technologie rond authenticatie en het zetten van elektronische handtekeningen gestandaardiseerd. Zowel (sterke) authenticatie als (geavanceerde) elektronische handtekeningen vereisen cryptografische bewerkingen en dus sleutelbeheer. Om sleutelbeheer beheersbaar te maken is het gebruik van Public Key cryptografie onvermijdelijk. Dit maakt het inrichten van een hiërarchische infrastructuur voor sleutelbeheer (een zogenaamde PKI) mogelijk. Het beschrijven van public key cryptografie valt buiten de scope van dit rapport. Defacto wordt bij het gebruik van public key cryptografie eigenlijk altijd gebruik gemaakt van X.509 certificaten, zoals gestandaardiseerd door de ITU-T en de Public Key Cryptography Standardaarden (PKCS) van RSA Security. Omdat de omgeving aan de client-kant niet altijd vertrouwd kan worden - zowel de gebruiker als software op het platform van de gebruiker kunnen kwaadwillend zijn worden soms zogenaamde PKI tokens gebruikt. Dit zijn apparaten waarmee cryptografische bewerkingen kunnen worden uitgevoerd ten behoeve van authenticatie en digitale ondertekening. Een PKI token zal beschikken over een privé sleutel in beschermd geheugen (niet uitleesbaar, maar wel te gebruiken in transacties) en over certificaten waarin de identiteit van de gebruiker gekoppeld wordt aan een publieke sleutel. De certificaten zijn weer getekend door een Certificate Authority (CA) en de handtekening kan door een ieder gecontroleerd worden die de beschikking heeft over het root certificaat van de betreffende CA. Om te voorkomen dat een gestolen PKI token door onbevoegden gebruikt wordt, is meestal een PIN code vereist voordat cryptografische bewerkingen kunnen worden uitgevoerd met het token.

9

MIDlets zijn op de telefoon (dus niet op de SIM) geïnstalleerde Java applicaties die voldoen aan de Java ME specificatie (zie http://java.sun.com/javame/index.jsp).

8

N O V A Y

Een op PKI gebaseerde oplossing voor ondertekenen kan ook gebruikt worden voor authenticatie. Door aan de server kant een bericht te genereren (dat niet herhaald zal worden), dit te laten ondertekenen aan de client kant en de resulterende handtekening samen met het publieke sleutelcertificaat op te laten sturen naar de server kant, kan een server controleren dat een client beschikt over de bij het certificaat horende privé sleutel (en dus over een PKI token dat aan die client is uitgedeeld). Een overzicht van de PKCS standaarden van RSA Security: 

PKCS #1 Public Key cryptography (RSA).



PKCS #6 Certificaten (is vervallen en vervangen door X.509 versie 3).



PKCS #7 Cryptographic message syntax. Beschrijft hoe het resultaat van een handtekening (zogenaamde ‘signed data’) eruit ziet.



PKCS #9 Selected attributes. Beschrijft aspecten van inhoud van ‘signed data’ structuur.



PKCS #11 Crypto tokens. Werking van PKI tokens ten behoeve van koppelvlak met client software op PC.



PKCS #15 Crypto token information format. De inhoud van het token. Met name certificaten, selectie van sleutels indien een token meerdere privé sleutels heeft, enz.

Opgemerkt dient te worden dat Mobile PKI oplossingen in eerste instantie geen gebruik maken van PKCS #11 en hoger. Het door Mobile PKI geimplementeerde token heeft namelijk geen directe interactie met de client kant (de PC van de gebruiker). 2 . 2 .4 E l e kt r on isc he han dt e ke n ing sta nd aa rde n

Verschillende landen, waaronder ook Nederland 10 , hebben wetgeving ingevoerd gebaseerd op een Europese richtlijn uit 1999 [2]. Deze richtlijn definieert in artikel 2 een aantal eisen waaraan een zogenaamde geavanceerde elektronische handtekening moet voldoen. Van een geavanceerde elektronische handtekening wordt geëist dat deze: 

aan de ondertekenaar gebonden is,



gebruikt kan worden om de ondertekenaar te identificeren,



alleen door de ondertekenaar geplaatst kan worden (met middelen waartoe de ondertekenaar exclusieve toegang heeft),



gebonden is aan de data die ondertekend is (zodat deze data niet veranderd kan worden zonder detectie)

Daarnaast definieert de richtlijn de eisen waaraan een zogenaamd gekwalificeerd certificaat moet voldoen. Dit zijn niet zozeer eisen aan de gebruikte technologie (X.509 is de de-facto standaard) maar vooral eisen aan de CA. De eisen gaan over attributen die ingebed zijn in het certificaat, zoals naam en locatie van de CA, het doel van het certificaat (ondertekenen, authenticatie, versleuteling, …), geldigheidsdata, etc. Elektronische handtekeningen worden, volgens de Mobile PKI standaarden van ETSI, daarnaast ook geclassificeerd binnen het European Electronic Signature Standardization Initiative (EESSI) van de International Communications and Technology Standards Board (ICTSB). Deze maakt onderscheid tussen een algemene elektronische 10

Zie http://www.e-overheid.nl/e-overheid-2.0/live/binaries/e-overheid/juridisch/wetelektronische-handtekening.pdf. T S

M O B I L E

P K I

9

handtekening (die niet automatische verwerkt kan worden maar wel een juridische status heeft), een gekwalificeerde elektronische handtekening (die als gevolg van zijn technische implementatie minstens dezelfde juridische status zou moeten hebben als een handgeschreven handtekening) en een uitgebreide (“enhanced”) elektronische handtekening met dezelfde kenmerken als de geavanceerde elektronische handtekening uit de Europese richtlijn. Het lijkt erop dat EESSI overgegaan is in ETSI-ESI 11 en dat de terminologie uit de Europese richtlijn leidend is. In het Common Criteria protectieprofiel voor Secure Signature Creation Devices (beschreven in [3]) wordt overigens ook gesproken over zowel “qualified” certificaten als over “qualified electronic signatures”. Mobile PKI oplossingen hebben de ambitie om geavanceerde handtekening devices te implementeren waarmee het mogelijk is om handtekeningen te produceren met gekwalificeerde certificaten. 2 . 2 .5 Mobile Signature Se rvice (MSS)

Omdat Mobile PKI uitgebreid beschreven wordt in Hoofdstuk 3 beperkt deze paragraaf zich tot een opsomming van relevante standaarden met een korte beschrijving. 

ETSI 102 203 – “Business functional requirements”. Bevat een niet-technische introductie tot Mobile PKI waarin de concepten uit de andere ETSI documenten alvast uitgelegd worden. Beschrijft een groot aantal applicatie scenario’s. Daarnaast ook verantwoording over ontwerpcriteria en mogelijke invulling van verschillende rollen.



ETSI 102 204 – “Web service interface”. Beschrijft de syntax van het berichtenverkeer tussen MSSP (de server) en Application Providers (AP’s). Dit is de meest concrete van de ETSI documenten die Mobile PKI beschrijven.



ETSI 102 206 – “Security framework”. Bevat een raamwerk van beveiligingseisen waaraan een Mobile PKI oplossing moet voldoen. Helaas “technology agnostic”, dus abstract. De eisen vormen de basis van Hoofdstuk 4.



ETSI 102 207 – “Roaming”. De ETSI standaarden voor Mobile PKI voorzien in roaming op transactieniveau waarbij transacties via een pad van aaneengeschakelde MSSP’s doorgegeven worden. Dit is niet van toepassing op de onderhavige pilot en dit document is daarom genegeerd.



WPKI document [16]. Dit document is recenter dan de ETSI standaarden. Het document claimt dat de afhankelijkheden met de ETSI standaarden minimaal zijn. Concreter dan ETSI standaarden. Status onduidelijk (geen standaard).

11

10

Zie http://portal.etsi.org/esi/el-sign.asp.

N O V A Y



Common Criteria protection profiles voor SSCD’s Software die gebruikt wordt voor beveiligingsdoeleinden kan op een onafhankelijke manier gecertificeerd worden zodat leveranciers van dit soort producten op kwaliteit vergeleken kunnen worden. Een standaard voor de certificering is de zogenaamde Common Criteria (CC). Onderdeel van een CC certificering is de keuze voor een zogenaamd protection profile (PP). Voor apparaten die gebruikt worden voor het zetten van digitale handtekeningen (zogenaamde Secure Signature Creation Devices, SSCD’s) bestaat zo’n PP (zie [3]). De PP voor SSCD beschrijft op systematische wijze de eisen waaraan een SSCD moet voldoen. Bovendien wordt ook de omgeving waarin een SSCD gebruikt gaat worden beschreven.

De ETSI standaarden die Mobile PKI beschrijven zijn “technology agnostic”, en bevatten dus weinig details (met uitzondering van de SOAP specificatie voor het verkeer tussen AP en MSSP). Wel bevatten ze veel eisen, waaronder veel security eisen. Opvallend is dat begrippen als “SIM kaart” en “mobiele telefoon” nauwelijks als zodanig genoemd worden: er wordt een onderscheid gemaakt tussen het kale Signature Creation Device (in de praktijk de SIM Toolkit applicatie op de SIM kaart) en de Signature Creation Application (in de praktijk de mobiele telefoon). 2.3

Conclusie

Mobile PKI technologie is gebaseerd op basis-ingredienten die al sinds 2001 bestaan, technisch volwassen zijn en gestandaardiseerd zijn. Wel vereist Mobile PKI redelijk geavanceerde (en mogelijk dus duurdere) SIM’s. Wellicht was er tot nu toe gebrek aan business opportunity bij mobiele operators om zulke SIM’s in te voeren. De vraag onder welke voorwaarden Mobile PKI grootschalig ingevoerd kan worden in Nederland valt echter buiten de scope van dit rapport. Gebruik van open standaarden zorgt ervoor dat een identity provider of application provider zoals SURFnet relatief eenvoudig in kan stappen en de oplossing kan integreren met de eigen systemen. De laatste jaren (2007 – 2009) lijkt er wat meer adoptie van Mobile PKI, vooral rond de oplossing van Valimo. Een groot aantal pilots is intussen uitgevoerd, maar Mobile PKI wordt intussen ook al echt gebruikt bij het aanbieden van echte diensten door banken (bijvoorbeeld in Turkije, Scandinavië en de Baltische staten). De grote partijen die een rol spelen bij Mobile PKI, SIM kaart leveranciers en mobiele operators lijken partnerschappen aan te gaan om Mobile PKI aan de man te brengen.

T S

M O B I L E

P K I

11

3 Architectuur Dit hoofdstuk beschrijft de architectuur van Mobile PKI oplossingen in het algemeen en de Valimo oplossing in het bijzonder. Voor Mobile PKI beschrijven we op hoog abstractieniveau de registratie en authenticatie (en signing) processen. Voor de Valimo oplossing beschrijven we het authenticatieproces in meer detail op basis van ervaringen in een kleinschalige pilot (voor zover te achterhalen). 3.1

Pr oc ess en

Ieder identiteitsmanagementproces kent een aantal fases: creatie, registratie (provisioning van identiteiten, enrolment van gebruikers, uitgifte van certificaten), gebruik van identiteiten, intrekken (terugroepen, revocatie) van identiteiten.

A.

B.

C.

D.

E.

Creatie

Registratie

Uitgifte

Gebruik

Intrekken

Figuur 3: Fases authenticatiemiddelen.

In concrete situaties zijn allerlei varianten denkbaar, maar deze fases kunnen doorgaans wel herkend worden. Los van de identiteit van de gebruiker kennen authenticatiemiddelen (zoals de smartcard) een eigen zogenaamde lifecycle. Deze bestaat uit fases zoals: creatie, personalisatie, uitgifte, gebruik, terminatie. Soms wordt in de creatie-deelfase ook het ontwikkelen van hardware en software meegenomen. Dit gebeurt bijvoorbeeld bij beveiligingsevaluatie in het kader van Common Criteria: protectieprofiel [3] noemt in Figuur 3 op badzijde 8 de stadia van de lifecycle: Design, Fabrication, Initialization, Personalization, Usage, Destruction). In dit rapport beperken we ons echter tot het registreren en het gebruik van authenticatiemiddelen, de andere fases zullen van geval tot geval anders zijn. Bij registratie wordt een identifier (meestal een naam of een nummer) gekoppeld aan een eindgebruiker en krijgt de eindgebruiker de beschikking over credentials (in dit een geval een applicatie op een SIM kaart met daarin een privésleutel). De identifiers worden opgenomen in het publieke sleutel certificaat van de gebruiker. Tijdens de gebruiksfase worden sessies opgezet tussen gebruikers, AP’s en de Identity Provider (IdP). Ook iedere sessie kan weer ingedeeld worden in fases: sign on, authenticatie, autorisatie, gebruik, en sign off.

1.

2.

3.

4.

5.

Sign on

Authenticatie

Autorisatie

Gebruik

Sign off

Figuur 4: Fases sessie met authenticatie.

De twee faseringen hebben een totaal andere tijdschaal. We kijken naar beide en deze komen terug in de architectuur/implementatie en vormen ook de basis voor de veiligheidsanalyse in Hoofdstuk 4.

12

N O V A Y

3.2

Rollen

Bij elk van de processtappen zijn verschillende partijen/rollen betrokken:  De eindgebruiker  De mobiele operator (de MO)  De producent van het authenticatiemiddel (de SIM) en bijbehorende back-end systemen (de MSSP) (bijvoorbeeld Valimo)  De IdP (bijvoorbeeld SURFnet)  De certificate authority (CA) (bijvoorbeeld Diginotar)  De applicatieprovider (AP) (bijvoorbeeld een bij SURFnet aangesloten onderwijsinstelling, in sommige scenario’s ook SURFnet zelf) Merk op dat de diverse verantwoordelijkheden, gedetailleerder besproken in de twee processen hieronder, bij verschillende belanghebbenden kunnen worden belegd. Bijvoorbeeld het beheren van attributen die horen bij identiteiten kan exclusief bij IdP gelegd worden, of verdeeld worden over AP, IdP, CA, MO en eindgebruiker. Ook kan het controleren van authenticiteit van identiteiten (danwel integriteit van transacties) mogelijk gemaakt worden of juist beperkt worden tot een subset van deze partijen. 3.3

R e g ist rat ie pr oc es

Registratie (ook wel provisioning of enrolment genoemd) is het proces waarin de identiteit van een eindgebruiker initieel in het systeem wordt vastgelegd. We gaan ervan uit dat een eindgebruiker al een relatie heeft met een MO en mogelijk ook al met andere partijen zoals de IdP. Deze partijen hebben al attributen opgeslagen over de eindgebruiker, geïndexeerd op een bepaalde identifier. Deze identiteiten moeten gekoppeld worden in de databases van de verschillende partijen en de CA moet credentials aanmaken (een sleutelpaar genereren waarvan het privé gedeelte in de SIM terecht komt, en het publieke gedeelte in de MSSP). Er dienen koppelingen gemaakt te worden tussen de identifiers waaronder een gebruiker bekend is bij de verschillende partijen. Het diagram in Figuur 5, gebaseerd op de beschrijvingen in [8], [10], [16], geeft een voorbeeld van de infrastructuur zoals deze kan zijn toegepast tijdens de pilot. CA

IdP

MSSP Operator

Personalisator

SIM Figuur 5: Partijen en berichten tijdens (een mogelijk) registratieproces.

Varianten op de geschetste infrastructuur zijn mogelijk. Aanname is dat zowel de IdP als de MO de gebruiker al kennen. Op basis van de gebruikersadministratie van de MO worden certificaten aangemaakt bij de CA. In deze certificaten wordt het International Mobile Subscriber Identity nummer (IMSI) van de SIM als attribuut opgenomen. De publieke sleutel die in de certificaten komt te staan, moet overeenkomen met de privésleutel zoals die in de SIM applicatie toolkit applet voorkomt. Er zijn een aantal T S

M O B I L E

P K I

13

verschillende manieren om dit voor elkaar te krijgen (waarvan de eerste het meest waarschijnlijke is): 

Generatie van het sleutelpaar in de SIM. De kaart, inclusief de applicatie gaat naar de gebruiker, de applicatie genereert het sleutelpaar, stuurt (via de mobiele operator) een Certificate Signing Request (CSR) naar de CA, deze tekent het certificaat, het publieke deel wordt opgeslagen in de MSSP.



Generatie sleutelpaar bij CA: CA genereert sleutelpaar, privésleutel gaat (op beveiligd) transport naar personalisator, SIM met applicatie en sleutels gaan naar gebruiker, CA tekent certificaat, wordt opgeslagen in MSSP.



Generatie sleutelpaar door MSSP: MSSP genereert sleutelpaar, stuurt CSR naar CA, deze tekent certificaat, wordt opgeslagen in MSSP, operator stuurt de privésleutel naar de personalisator.

De applicatie op de SIM bevat in alle gevallen de privésleutel, die tijdens het proces als het goed is nergens anders blijft opgeslagen. Het publieke sleutelcertificaat blijft altijd in de MSSP (hoewel deze in principe ook in de applicatie in de SIM zou kunnen worden opgeslagen). De IdP hoeft alleen een identifier op te slaan die naar het certificaat refereert en heeft een online verbinding met de MSSP. De rol van de personalisator (vaak is dit de leverancier van de SIM kaart), die namens de MO de applicaties op de SIM laadt, kan overgenomen worden door de MO zelf aangezien de SIM toolkit API applicatiebeheer over-the-air toestaat. Dit betekent dat de Mobile PKI applicatie post-issuance, dus terwijl de SIM kaart al bij de gebruiker in de mobiele telefoon zit, geïnstalleerd en gepersonaliseerd kan worden. 3.4

Au the nt ica tiep ro ces

Authenticatie is het proces waarin de eindgebruiker aan de IdP bewijst te beschikken over de aan hem uitgereikte credentials. In dit geval gebeurt dat door een door de IdP gegenereerd bericht te ondertekenen met de privésleutel die zich in de SIM bevindt. Authenticatie gebeurt op verzoek van de eindgebruiker in een poging om een dienst bij een AP af te nemen waarbij de AP enige zekerheid wil hebben omtrent de identiteit van de eindgebruiker. Vaak wordt het verstrekken van opgeslagen attributen door de IdP aan de AP (zogenaamde attribute release) ook meegenomen als onderdeel van authenticatie. Figuur 6 (wederom gebaseerd op de beschrijvingen in [8], [10], [16] en een Valimo marketing presentatie 12 ) geeft het Mobile PKI authenticatieproces weer. Het protocol maakt een hele rondtrip langs alle partijen. In dit geval wordt het geïnitieerd doordat de eindgebruiker zich (via de PC) aanmeldt bij AP. De AP verbindt de gebruiker door naar de IdP omdat de AP een authenticatie vereist. De IdP maakt verbinding met de MSSP, deze zoekt credentials van de gebruiker, met name het IMSI nummer, en checkt bij de CA of het corresponderende eindgebruiker-certificaat nog geldig is. Zo ja, dan genereert de IdP een bericht met daarin een onvoorspelbare challenge en stuurt dit naar de MSSP. De MSSP stuurt nu via de MO, die bij het IMSI nummer een MSISDN (telefoonnummer) kan opzoeken, een SMS bericht naar het telefoonnummer van de eindgebruiker met daarin een verzoek om het bericht van de IdP te ondertekenen. De SMS is niet bedoeld voor consumptie door de eindgebruiker, maar voor consumptie door de SIM (een service SMS). De mobiele Valimo VMAC applet op de SIM ondertekent de challenge nadat de gebruiker via de GUI van de telefoon gevraagd is naar zijn PIN code. De AP krijgt de

12

Powerpoint presentatie door Erkki Saharanta, Valimo Wireless Ltd, beschikbaar via http://www.oasis-open.org/events/forum/2006/slides/saharanta.ppt.

14

N O V A Y

signature weer via MO en MSSP en kan actie ondernemen (additionele attributen op gaan zoeken bijvoorbeeld). IdP (via AP)

1

PC

CA 2

Mobiel

3 SIM 5

4

MSSP Operator

Figuur 6: Partijen en berichten tijdens authenticatieproces (of ondertekenproces).

Als de SIM (via de MSSP) antwoord heeft gegeven op het challenge bericht dat oorspronkelijk door de IdP opgestuurd is, dan gaat de IdP als volgt te werk om deze response te controleren: 1. In het bericht bevindt zich het publieke eindgebruikerscertificaat dat hoort bij de privésleutel in de SIM. De IdP beschikt over het root certificaat van de CA en controleert of het eindgebruikerscertificaat ondertekend is met een privésleutel die hoort bij het root certificaat van CA. 2. In het bericht bevindt zich ook een PKCS #7 structuur waarvan, als het goed is, de oorspronkelijke challenge deel uitmaakt. De IdP controleert of dit inderdaad het geval is. Bovendien controleert de IdP of deze structuur ondertekend is met de privésleutel die hoort bij het eindgebruikerscertificaat. 3. Van tijd tot tijd communiceert de IdP met de CA om bij certificaten te kunnen beslissen of deze verlopen zijn of niet. 13 Bovenstaand bewijsmateriaal (challenge en response) kan in principe ook gedeeld worden met AP’s. In de figuur geven gestippelde vlakken aan wat ten behoeve van de pilot onder controle van de auteurs van dit rapport was. Paragraaf 3.5 geeft een korte technische analyse van hetgeen zich aan koppelvlak 2 (het verkeer tussen MSSP en AP) en koppelvlak 5 (het verkeer tussen MO en SIM) afspeelt. In de figuur is de MSSP bij de MO getekend. Alternatieven zouden zijn om deze bij de IdP, of bij de CA, of bij authenticatiemiddelenproducent Valimo te hosten. Het meest voor de handliggend is om de MSSP bij de MO te hosten. Voor ons deel van de pilot van SURFnet werd een MSSP bij Valimo gebruikt.

13

Ofwel door het ophalen van een Certificate Revocation List (CRL) of via het Online Certificate Status Protocol (OCSP). T S

M O B I L E

P K I

15

3.5

T ec hn is che an al ys e va n e en aan t a l k op pelvla k k en

Hoewel de ETSI standaarden technology agnostic zijn (pagina 14 van [10]), kunnen we, door de Valimo oplossing in het authenticatie scenario aan een aantal tests te onderwerpen, een redelijke inschatting maken hoe Valimo het programma van eisen implementeert. We analyseren het verkeer tussen IdP en MSSP (koppelvlak 2 in Figuur 6) en het verkeer tussen mobiele telefoon en SIM kaart (koppelvlak 5 in Figuur 6). Deze twee koppelvlakken staan tenslotte tot onze beschikking tijdens de pilot. Deze analyses geven tevens een wat gedetailleerder beeld van welke veiligheidscontroles uitgevoerd (moeten) worden tijdens een transactie. 3 . 5 .1 K o pp e l vlak t us sen A P e n M S S P via I n t er ne t

De IdP stuurt een XML geformatteerd bericht (een SOAP aanroep volgens [9]) naar de MSSP via interface 2 met daarin een verzoek tot ondertekening van ‘data to sign’ en ‘data to display’. Een voorbeeld van zo’n verzoek staat in Appendix A. De MSSP stuurt, nadat de IdP geauthenticeerd is (in de pilot op basis van een wachtwoord), een SMS naar de SIM van de eindgebruiker, deze ondertekent ‘data to sign’. De MSSP antwoordt via interface 2 met een XML geformatteerd bericht (een SOAP reactie volgens [9]). Een voorbeeld van zo’n reactie staat in Appendix B. Dit antwoord bevat een PKCS#7 signed data structuur in base64 codering. Deze structuur bevat drie componenten. Ten eerste bevat de PKCS#7 structuur een verzameling zogenaamde signed attributes. Er zijn drie zulke attributen: 

1.2.840.113549.1.9.3 (ContentType)  1.2.840.113549.1.7.1 (data)



1.2.840.113549.1.9.25.3 (randomNonce)  30B18CD97E66EB29



1.2.840.113549.1.9.4 (messageDigest)  D32C2CE05DD77BEF3687B40D361532FD4030716D

Het eerste attribuut geeft het type van de ondertekende inhoud aan. Het tweede attribuut zorgt ervoor dat oude transacties niet opnieuw gebruikt kunnen worden. Het laatste attribuut blijkt inderdaad een SHA1 hash te zijn van de ‘signed data’ (letterlijk) die opgestuurd was. Ten tweede maakt ook het publieke sleutelcertificaat van de eindgebruiker onderdeel uit van de PKCS#7 signed data structuur: Certificate: Data: Version: 3 (0x2) Serial Number: 90:28:79:d8:34:75:9e:83:24:df:02:8c:41:d5:e2:1a Signature Algorithm: sha1WithRSAEncryption Issuer: C=fi, O=valimo, OU=RSADevpCA Validity Not Before: Jun 16 15:23:41 2009 GMT Not After : Jun 16 15:23:41 2010 GMT Subject: C=fi, O=Valimo, OU=nonrep, CN=8935801080084400490F Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:92:b8:58:e4:50:af:27:c7:bd:40:55:59:df:c8:9e:14:7f:b9:f0:6e:05:68:ed:b4:a4:33:49:3d:23:

16

N O V A Y

57:91:af:e6:4e:b2:bc:aa:ff:55:c4:91:2b:19:24:9f:52:66:c4:32:5f:60:c1:38:04:6b:57:9d:7c:81: 07:8d:c1:ce:24:cb:81:c0:1a:4f:4d:a1:65:e4:a5:34:00:ec:3f:6d:d2:1f:94:2a:9c:c1:18:6e:4b:01: ee:ef:0e:d2:0c:e0:96:ce:14:31:13:a3:d3:78:91:5a:8c:f3:d0:71:cb:6d:5a:75:0d:e0:39:fe:30:6f: 2b:cd:8e:96:9e:e9:72:05:29 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 CRL Distribution Points: DirName:/C=fi/O=valimo/OU=RSADevpCA Signature Algorithm: sha1WithRSAEncryption 55:29:2f:5a:c1:60:02:dc:a9:3b:61:e4:55:aa:e5:d7:0e:3a:07:b0:41:0b:fc:62:a3:19:32:3e:7f:be:a0:77:2a:5f:ce:b4: ee:5f:36:ba:29:a9:0e:da:7b:e4:1f:8d:79:de:0b:9e:c8:ab:d3:25:a0:2b:08:07:83:34:c1:a4:7b:b0:ee:be:bd:1b:74:b 4:4e:2a:5c:09:84:2e:a3:e9:90:16:c2:1c:43:b9:9d:80:4d:6d:9a:47:50:56:35:1d:ba:0d:d9:4f:b7:db:62:69:65:40:89 :85:9c:20:62:87:d4:15:26:5b:7a:83:e0:83:48:81:b9:68:61:77:09:72

Merk op dat de naam in het subject van het certificaat het IMSI nummer van de SIM bevat: /C=fi/O=Valimo/OU=nonrep/CN=8935801080084400490F. Met behulp van het Valimo test root certificaat is gecontroleerd dat dit meegestuurde certificaat inderdaad ondertekend is door Valimo. Ten derde bevat de PKCS#7 structuur ook de uiteindelijke handtekening over de attributen (een RSA versleuteling van een SHA1 hash van de signed attributes): 5FC6951CA01DBE0C1B4C6457B04855B58931214034540016C496260452EE8EE5894B51F11FE195DED55 330729101F2638C0BE8E28B145B8ED02FF85BD1753BB238D058510357B6A4CAE5AD2FAFF9268365EFB B8C5ADA37467820262B52767C1EAFABA75F051B5171743BC1CD0C759AB2CBC1B574153C5ED819832C7 653D38B82

De handtekening over de signed attributes bleek in de pilot niet te kloppen, hetgeen waarschijnlijk veroorzaakt wordt door een verkeerd geconfigureerde MSSP. 3 . 5 .2 K o pp e l vlak t us sen M ob i e l e n S I M

Het verkeer tussen mobiele telefoon en SIM kaart kan geanalyseerd worden door tussen de contactjes van de SIM en de kaartlezer in de mobiele telefoon een zogenaamde “Season interface” 14 te plaatsen. De grote vraag hierbij is of en hoe er een end-to-end verbindingsbeveiliging (secure messaging) tussen de VMAC applet en de MSSP wordt opgezet. In principe is het hoog niveau communicatieprotocol voor dit koppelvlak proprietary, zij het dat het natuurlijk op GSM 11.14 (zie [6]) gebaseerd is en er eisen aan worden gesteld in de Mobile PKI standaarden van ETSI (zie [10]). Binnen de scope van dit project was het helaas niet mogelijk om dit experiment succesvol af te ronden. 3.6

Conclusie

Mobile PKI (in het scenario zoals gebruikt in de pilot; en zoals het typisch gebruikt zou worden voor de SURFfederatie) maakt gebruik van twee kanalen naar de gebruiker: een kanaal via de PC van de gebruiker en een kanaal via de mobiele telefoon van de gebruiker. Authenticatie van de gebruiker wordt geïnitieerd via het PC kanaal en bevestigd door via het GSM kanaal te controleren of de gebruiker de corresponderende sleutels in een SIM toolkit applicatie op de SIM kaart heeft. Een aantal partijen (MO, IdP/AP, CA) speelt bij het tot stand komen van authenticatie een rol. Elk van deze partijen beheert een deel van de identiteit van de gebruiker (een identifier met een aantal attributen). De architectuur is flexibel, waardoor veel 14

Zie http://en.wikipedia.org/wiki/Pirate_decryption#Terminology_and_Definitions.

T S

M O B I L E

P K I

17

configuratievarianten mogelijk zijn. Een andere configuratie betekent dat de verantwoordelijkheden anders belegd worden bij de verschillende stakeholders. Maar de MO heeft een speciale rol omdat deze eigenaar is van de SIM en geïnstalleerde SIM toolkit applicaties. Hierdoor kan Mobile PKI alleen gebruikt worden als de MO meewerkt. Dit in tegenstelling tot bijvoorbeeld SMS-OTP, waarbij de MO alleen data door hoeft te geven.

18

N O V A Y

4 Veiligheidsanalyse Om de veiligheid van Mobile PKI oplossingen te kunnen beoordelen zijn een tweetal standaardbenaderingen mogelijk. Ten eerste, onder de ETSI standaarden die Mobile PKI beschrijven, bevindt zich ook een raamwerk met security eisen (namelijk [10]). Dit document is als uitgangspunt genomen voor dit hoofdstuk en een aantal eisen wordt in detail besproken in 4.2. Ten tweede, bestaat er een Common Criteria protectieprofiel (namelijk [3]) voor mobile signature devices, waarin ook eisen gesteld worden aan Mobile PKI oplossingen die op EAL4+ niveau gecertificeerd worden. Paragraaf 4.3 schetst in hoofdlijnen waar en hoe deze eisen afwijken van de eisen in de ETSI standaard. Dit hoofdstuk begint echter met een ad-hoc beveiligingsanalyse waarbij de auteurs getracht hebben om vanuit het standpunt van een aanvaller naar de concrete Valimo oplossing te kijken tijdens de pilot. 4.1

Ee n ad -h oc be dre ig in gs ana l ys e

Zoals aangegeven in hoofdstuk 3 bestaat een Mobile PKI oplossing uit een aantal componenten. De belangrijkste componenten zijn: een server die bij de MO staat (de MSSP), de mobiele telefoon van de gebruiker (de SCA), en de SIM toolkit applicatie op de SIM in die mobiele telefoon (de SCD). De identiteit van de gebruiker wordt gekenmerkt door de SIM kaart van de gebruiker. In elk van deze componenten bevinden zich zaken die de moeite van het beschermen waard zijn: zogenaamde assets. Op basis van hoofdstuk 2 (hoe werkt PKI, hoe werkt Mobile PKI) en hoofdstuk 3 (hoe zit de Mobile PKI architectuur in elkaar) identificeren we de volgende assets. 

Privésleutels die zich in de SIM kaart bevinden. Deze privésleutels bevinden zich in het geheugen van de SIM, en worden tijdens transacties gebruikt om de MSSP te overtuigen van de authenticiteit van de SIM kaart. Bij goede beveiliging zijn deze sleutels niet uitleesbaar, zelfs niet door de eindgebruiker.



De SIM zelf. Een gestolen SIM kaart kan gebruikt worden door anderen om namens de gebruiker transacties te plegen. Zonder PIN code kan de aanvaller er niet zo veel mee, maar deze zou later ontfutseld kunnen worden, of is wellicht raadbaar.



PIN code. Een ontfutselde PIN code is alleen waardevol in combinatie met een gestolen SIM kaart. Bij een goed beveiligde SIM kan de aanvaller typisch hoogstens drie keer raden voordat de PIN controle de SIM blokkeert.



Integriteit van de server en achterliggende systemen. AP’s maken een connectie met de MSSP, dit vereist in principe dat de MSSP online is en dus benaderbaar door aanvallers. Typisch zal deze asset beveiligd worden door wederzijdse authenticatie tussen MSSP en AP’s te eisen. Hieronder vallen ook bijvoorbeeld privacy gerelateerde aanvallen die het online

T S

M O B I L E

P K I

19

gedrag van gebruikers onthullen (tegen de wens van gebruikers in) en aanvallen op de aanvraagprocedures (het laten blokkeren van SIM kaarten van nietsvermoedende gebruikers, niet bestaande gebruikers aanmelden). De assets worden in een Mobile PKI oplossing door een aantal beveiligingsmechanismes beschermd: de SIM kaart is een smartcard die bestand is tegen allerlei aanvallen, deze blokkeert als te vaak een verkeerd PIN code wordt geprobeerd, etc. Door vanuit de aanvaller te denken, wordt geprobeerd om een zo volledig mogelijk beeld te verkrijgen van mogelijke aanvallen en hun impact. We gaan uit van het standaard authenticatiescenario (zie Figuur 6) waarin een gebruiker via zijn PC probeert aan te loggen bij een AP. Impact van de aanval wordt kwalitatief weer gegeven met [OK] of [LET OP]. 

Online passieve aanvaller o

Het gebruik van twee kanalen (PC via Internet, mobiele telefoon via MO netwerk) maakt het voor een online aanvaller al aanzienlijk moeilijker. [OK]

o

Het verkeer tussen PC en IdP/AP is normaal gesproken via SSL beveiligd, dus een passieve aanvaller kan hier niet zoveel mee. Het verkeer tussen IdP/AP en MSSP wordt (in ieder geval in de pilot) vooraf gegaan door een authenticatie van de IdP/AP op basis van gebruikersnaam/wachtwoord. Dit is qua veiligheid niet voldoende. Mutual authentication op basis van certificaten over een SSL link zou beter zijn. [OK]

o

Het verkeer tussen mobiele telefoon en MSSP (via MO) is in de GSM standaard beveiligd (via algoritme A5), maar bij de sterkte van deze beveiliging worden recentelijk vraagtekens geplaatst 15 . [LET OP] Het is zeer waarschijnlijk dat de SIM toolkit applicatie eerst een secure channel opzet, alvorens de applicatie over het potentieel onveilige GSM kanaal communiceert. (De Global Platform standaard biedt hier in ieder geval mogelijkheden voor.) [OK]



Online actieve aanvaller o

Ook voor een actieve online aanvaller is het gebruik van twee kanalen een obstakel. [OK]

o

Via een phishing aanval op het PC kanaal kan een actieve aanvaller een gebruiker proberen te verleiden om een nep-AP te bezoeker. Echter, omdat een AP slechts met de MSSP kan communiceren na authenticatie zal deze nep-AP geen transactie kunnen starten die gebruik maakt van de mobiele telefoon van de gebruiker. [OK] Wel zou een naïeve gebruiker verleid kunnen worden om zijn PIN code in te voeren via het PC kanaal. [LET OP]

o

15

20

De MSSP en AP servers moeten natuurlijk afdoende beveiligd zijn tegen aanvallen die via het netwerk komen. Dit is een standaard beveiligingsvraagstuk. [OK]

Zie, bijvoorbeeld, http://reflextor.com/trac/a51.

N O V A Y





Aanvaller met toegang tot PC o

Een aanvaller die fysiek bij de PC kan heeft nog geen toegang tot de mobiel van de gebruiker en kan dus geen transacties verrichten namens de gebruiker. [OK]

o

Geïnstalleerde malware op de PC van de gebruiker vormt in die zin dus ook geen reële bedreiging. [OK]

o

Wel kan door geïnstalleerde malware een zogenaamde “Man-in-theBrowser” 16 aanval gelanceerd worden die een nietsvermoedende gebruiker doet geloven dat hij deel neemt aan een (low-value) transactie bij een door hem uitgekozen AP, terwijl een trojan in de browser namens de gebruiker deelneemt aan een (high-value) transactie bij een andere AP. [LET OP]

o

Ook kan geïnstalleerde malware bijhouden welke AP’s bezocht worden (een privacy probleem dus). Maar dit ligt niet aan de authenticatieoplossing.

Aanvaller met toegang tot mobiele telefoon o

Een aanvaller met fysieke toegang tot de SIM kan de privé sleutel(s) en PIN code niet bemachtigen (mits het smartcard platform afdoende beveiligd is). Dit is een standaard beveiligingsprobleem. [OK]

o

Een aanvaller die (een mobiele telefoon met) SIM steelt weet de PIN code van de Mobile PKI applicatie niet (en, indien ingeschakeld, de globale PIN code van de SIM kaart niet). [OK] Over het algemeen merken gebruikers snel dat een mobiele telefoon gestolen is. Sneller dan andere PKI tokens. Op de MSSP kan het certificaat van de gebruiker dan ingetrokken worden. [OK]

o

Onduidelijk is of malware geïnstalleerd op de mobiele telefoon (bijvoorbeeld een Java ME, Symbian, Windows Mobile applicatie) het gedrag van een SIM toolkit applicatie kunnen verstoren (zowel gedrag betreffend de user interface als gedrag betreffend het ontvangen/versturen van SMS berichten) en zo de gebruiker de verkeerde indruk kunnen geven dat de Mobile PKI PIN gevraagd word of een transactie (niet) heeft plaatsgevonden. [LET OP]

o

Dreiging van malware op het mobiele platform is nog niet zo reëel als bij PC. [OK] Maar dat kan veranderen naarmate mobiele telefoons voor meerdere diensten gebruikt gaan worden. [LET OP]

 16

Aanvaller met toegang tot server systemen (een insider)

Zie http://en.wikipedia.org/wiki/Man_in_the_Browser.

T S

M O B I L E

P K I

21

o

Een (werknemer bij een) AP zou lokaal transacties kunnen aanpassen of verwisselen en een gebruiker een (high value) transactie kunnen laten tekenen terwijl de gebruiker veronderstelt een andere (low value) transactie te ondertekenen. [LET OP]

o

Een (werknemer bij een) AP zou een “Mafia-in-the-Middle” 17 aanval kunnen implementeren en (bijvoorbeeld via phishing) gebruikers naar zijn AP kunnen lokken. Bij een Mafia-in-the-middle aanval denkt een niets vermoedende gebruiker deel te nemen aan een (low-value) transactie, terwijl de middenpartij namens de gebruiker deelneemt in een andere (high-value) transactie bij een andere AP. [LET OP]

Afgezien van een aantal standaard beveiligingsvraagstukken rond de gebruikte SIM smartcard en aan de server kant, lijkt Mobile PKI een behoorlijk veilige oplossing. Onder bepaalde voorwaarden (malware op de PC van de eindgebruiker, insider attack bij de AP) kan een aanvaller een “Man-in-the-Middle” aanval proberen op te zetten waardoor de gebruiker een andere transactie ondertekent dan hij voornemens was. Een dergelijk aanval is te herkennen door eindgebruikers, maar dan moeten ze wel goed opletten op de Data To Be Signed (DTBS) die op de mobiele telefoon getoond wordt. Deze moet passen bij de transactie die wordt aangegaan. Dit vereist dat AP’s de DTBS op zo’n manier construeren dat gebruikers ook begrijpen wat de transactie inhoudt waarmee ze gaan instemmen. Mobile PKI vereist dat de MSSP en AP’s elkaar wederzijds authenticeren om vast te stellen dat ze met de juiste partij praten. In het geval van de SURFnet pilot praat de MSSP alleen met de SURFnet IdP. Op de SURFnet IdP zijn weer AP’s aangesloten die een vertrouwensrelatie hebben met de IdP. Mobile PKI kan door deze AP’s gebruikt worden als extra authenticatiemechanisme ten behoeve van bijvoorbeeld step-up authenticatie. 4.2

Beve iligingseisen va nuit de ETSI standaard

In ETSI 102 206 [10] wordt een raamwerk van eisen beschreven. Het document stelt eisen aan de volledige Mobile Signature Creation Service en aan de individuele componenten die deel uitmaken van deze dienst: de SIM kaart, de mobiele telefoon, en de MSSP server. (Eisen zijn gemarkeerd met respectievelijk MSCS, MSCD, MSCA en MSSP). De eisen zijn gesteld op relatief hoog niveau waardoor aanbieders van Mobile PKI ruime vrijheid hebben om implementatiekeuzes te maken. Het voert te ver om de hele lijst met eisen in dit hoofdstuk na te gaan. Dit hoofdstuk bespreekt slechts een selectie van eisen waaruit de lezer hopelijk kan opmaken hoe het met de beveiliging is gesteld. Algemene eisen aan de Mobile PKI dienst zijn bijvoorbeeld: 

The DTBS shall contain a Signer's Document. (MSCS1) Deze eis is niet zozeer een eis aan de Valimo oplossing, maar meer een eis aan de IdP/AP. Deze is namelijk verantwoordelijk voor het opstellen van de SOAP request die naar de MSSP gestuurd wordt.

17

22

Zie Hoofdstuk 2 van Ross Anderson’s Security Engineering.

N O V A Y



The DTBS shall contain the Signer's Certificate related to the Signature Creation Data that the MSCD uses to generate the Mobile Signature and intended by the Signer. (MSCS2) Om aan deze eis tegemoet te komen moeten de verschillende systemen goed op elkaar zijn afgestemd: de AP moet aangeven over welke gebruiker het gaat, de CA moet het juiste certificaat leveren, namelijk het certificaat dat hoort bij de privésleutel in de SIM van de gebruiker.



The MSCA, MSSP and MSCD shall maintain the confidentiality of the DTBS components, DTBSF, DTBSR, Mobile Signature, and SDO. (MSCS8) Aan deze eis is voldaan als de SIM toolkit applet een beveiligd kanaal opzet naar de MSSP op basis van een gedeelde sleutel.



The System shall ensure that the DTBS components used to create the DTBSF and DTBSR are the same as those presented to the Signer during the representation process and that they are identical to those signed by him. (MSCS9) Deze eis zegt iets over de consistentie van de door IdP/AP, MSSP en SIM toolkit applicatie geïmplementeerde oplossing.

Eisen die aan de SIM kaart (inclusief Valimo’s applicatie) worden gesteld zijn bijvoorbeeld: 

The MSCD shall provide unambiguous detection of physical tampering that might compromise the security functions. (MSCD8) Deze eis houdt in dat het smartcard platform waarop de SIM gebaseerd is enige weerstand biedt tegen aanvallen waarbij hardwarematig getracht wordt om de privé sleutels aan de SIM te ontfutselen.

Een eis aan de mobiele telefoon is bijvoorbeeld: 

A Trusted Path for the transaction of SAD to the SSCD shall be provided through the MSCA. (MSCA15) Hetgeen zoveel wil zeggen dat een GSM telefoon een beveiligd toetsenbord moet hebben zodat een ingetoetste PIN veilig de SIM kaart kan bereiken. Eventueel geïnstalleerde key-loggers op de mobiele telefoon mogen dus, bijvoorbeeld, geen invloed hebben op SIM application toolkit interacties met de gebruiker. Dit is een behoorlijk zware eis waaraan mogelijk niet alle leveranciers van mobiele telefoons voldoen.

Een eis die aan de MSSP server wordt gesteld is bijvoorbeeld: 

T S

The MSCA and the MSSP shall mutually authenticate each other, to assure the Signer that the MSSP and this particular Mobile Signature request can be trusted. (MSSP10)

M O B I L E

P K I

23

De ETSI eisen dekken een groot deel van de risico’s af. De Valimo oplossing lijkt op de meeste fronten te voldoen aan de ETSI eisen. Op een aantal fronten waar niet duidelijk is of de Valimo oplossing voldoet ontbreekt het de auteurs van dit rapport aan informatie. 4.3

Beve i l i g i n g sei sen va nuit he t C om m on Criteria prote c t ie p r o f ie l

Hoewel niet met zekerheid vast te stellen is of de Valimo SIM aan de Common Criteria standaard testen voor protectieprofiel [3] onderworpen is, helpt de beschrijving van het protectieprofiel om de security analyse vollediger te maken. Een Common Criteria protectieprofiel beschrijft de eisen die gesteld worden aan een product (het zogenaamde Target of Evaluation of TOE) en de omgeving waarin de TOE voorkomt. Het protectieprofiel begint met een lijst van assets. Deze is overgenomen in Tabel 2. Het protectieprofiel beschrijft vervolgens op systematische wijze een aantal aannames over de TOE en zijn omgeving: de dreigingen die relevant zijn voor deze assets, en organisationele security policies. Een voorbeeld van zo’n security policy is dat gekwalificeerde certificaten gebruikt gaan worden, andere voorbeelden zijn dat alleen de ondertekenaar de TOE kan gebruiken, en dat een handtekening praktisch gezien maar eenmaal geplaatst kan worden. Tabel 2: Assets van een Signature Creation Device volgens Common Criteria protectieprofiel.

1. SCD: private key used to perform an electronic signature operation (confidentiality of the SCD must be maintained). 2. SVD: public key linked to the SCD and used to perform an electronic signature verification (integrity of the SVD when it is exported must be maintained). 3. DTBS and DTBS-representation: set of data, or its representation which is intended to be signed (Their integrity must be maintained). 4. VAD: PIN code or biometrics data entered by the End User to perform a signature operation (confidentiality and authenticity of the VAD as needed by the authentication method employed) 5. RAD: Reference PIN code or biometrics authentication reference used to identify and authenticate the End User (integrity and confidentiality of RAD must be maintained) 6. Signature-creation function of the SSCD using the SCD: (The quality of the function must be maintained so that it can participate to the legal validity of electronic signatures) 7. Electronic signature: (Unforgeabilty of electronic signatures must be assured). Op basis van de dreigingsanalyse en deze aannames volgt een systematische opsomming van de beveiligingsdoelstellingen van het TOE en zijn omgeving. Deze wordt vervolgens gebruikt om een lange lijst van eisen te formuleren waaraan TOE en omgeving moeten voldoen. Veel van de eisen uit [3] komen overeen met de ETSI eisen beschreven in paragraaf 4.2. Het is niet denkbeeldig dat de schrijvers van de ETSI standaard zich gedeeltelijk gebaseerd hebben op dit protectieprofiel. Toch zijn er een aantal verschillen met de ETSI standaard: Ten eerste, het protectieprofiel (en Common Criteria in het algemeen) beschrijft een veel groter deel van de lifecycle van de TOE, onder andere of de TOE op een verantwoorde manier geproduceerd en geconfigureerd wordt. Ten tweede, is in het protectieprofiel een wat algemener onderscheid tussen TOE (de SCD i.e. SIM kaart) en omgeving van de TOE (de SCA, de MSSP). Aan de omgeving worden door [3] ook eisen gesteld, maar de nadruk ligt duidelijk op de TOE. Ten derde, zijn een aantal zeer specifieke eisen

24

N O V A Y

opgenomen die te maken hebben met het fysieke karakter van de SIM kaart. Geavanceerde aanvallen zoals ‘differential power attack’ worden specifiek genoemd waar ETSI wat abstracter blijft. 4.4

Conclusie

Mobile PKI is een zeer veilige oplossing, welke voldoet aan een uitgebreid programma van eisen (voor zover we dat zelf kunnen nagaan) zoals opgesteld door ETSI. De oplossing is veel sterker dan gebruikersnaam/wachtwoord want het is een hardware token dat aan strenge eisen voldoet (Common Criteria EAL4+ ge-assured). Maar, een “Man-in-the-middle” aanval door een kwaadwillende AP is altijd mogelijk indien een gebruiker de echte IdP/AP niet kan herkennen aan de DTBS die hij op zijn mobiele telefoon ziet.

T S

M O B I L E

P K I

25

5 Toepassing voor hoger onderwijs In dit hoofdstuk bediscussiëren we wat de impact van MobilePKI technologie is voor SURFnet en het hoger onderwijs in het algemeen, inclusief mogelijke concrete toepassingen voor de kortere termijn. We kijken vooral naar gebruik in de SURFfederatie, maar noemen ook wat andere mogelijkheden. 5.1

Hu id ig e s it uat ie : geb ru ike rsn aa m/w achtw oord

Het de-facto verreweg meest gebruikte authenticatiemiddel in het hoger onderwijs is gebruikersnaam/wachtwoord. Dit is ook het meest gebruikte authenticatiemiddel in de SURFfederatie. Gebruikersnaam/wachtwoord is erg phishing gevoelig, en wordt ook makkelijk gedeeld met collega’s, en is daarom niet geschikt om te gebruiken voor diensten die een hoger veiligheidsniveau vereisen. Hoewel er weinig consensus lijkt te bestaan tussen experts over het tempo waarin dit zal gebeuren, lijkt er wel consensus te zijn dat gebruikersnaam/wachtwoord als single-factor authenticatiemiddel zal verdwijnen op den duur 18 . Voordelen van gebruiksnaam/wachtwoord is natuurlijk dat het goedkoop is (bv geen kosten voor hardware, of communicatiekosten), en met name ook dat mensen dit gewend zijn. Overigens is wel zo dat bij gebruikersnaam/wachtwoord de kosten voor wachtwoord reset (bij vergeten wachtwoorden) duur kunnen zijn, als dit veilig moet gebeuren. 5.2

C r ite r ia vo o r h et g ebr u ik Mo b i le PK I

Bij het introduceren van een veiliger authenticatiemiddel zoals Mobile PKI moet er goed gekeken worden naar de balans met gebruikersvriendelijkheid. Er bestaat immers een trade-off tussen gebruikersvriendelijkheid aan de ene kant en veiligheid aan de andere. Het voordeel van MobilePKI is dat het niet alleen veiliger is dan gebruikersnaam/wachtwoord, maar dat het ook relatief gebruikersvriendelijk is. Criteria voor selectie van diensten waarvoor Mobile PKI op de kortere termijn geïntroduceerd kan worden zijn: 1. Hoge veiligheid – diensten die fraude- of privacygevoelig zijn, of bijvoorbeeld een grote negatieve impact kunnen hebben op integriteit of beschikbaarheid van systemen of netwerken, hebben een veiliger authenticatie middel nodig. 2. Laag aantal gebruikers – als er slechts toegang geboden hoeft te worden aan een beperkt aantal gebruikers zijn de kosten minder een probleem. 3. Voor werknemers – als het gaat om toegang voor werknemers van een organisatie met een ‘corporate’ abonnement bij één mobiele operator, kan Mobile PKI in samenwerking met die mobiele operator aangeboden worden. Dit in tegenstelling tot een dienst voor alle studenten in Nederland, waarbij dus alle mobiele operators zullen moeten meerwerken. 5.3

P ot ent i ë le d i en ste n vo o r g eb ru i k M ob i le P K I

Uit discussies gedurende het project kwamen de onderstaande diensten naar boven als kandidaten om op de kortere termijn Mobile PKI te gaan gebruiken voor authenticatie. 18

Bijvoorbeeld, Dave Kearns, 'Managing' passwords doesn't make them less unsafe, 4 mei 2009, http://www.networkworld.com/newsletters/dir/2009/050409id1.html.

26

N O V A Y

We hebben deze gecategoriseerd in diensten t.b.v onderzoek, onderwijs en voor ICT/netwerk. Onderzoek: Grid en e-science authenticatie: Toegang tot grid en e-science resources is nu typisch PKI gebaseerd, met alle bekende nadelen van het distribueren van de certificaten. Lichtpad opzetten: Vanwege kosten is hier een hoog authenticatieniveau nodig. Onderwijs: Toegang tot cijferlijsten en studentenadministratie algemeen: Vanwege privacy aspecten is hier een hoog authenticatieniveau nodig. Examenbriefjes bij aangesloten onderwijsinstellingen: Dit is typisch een erg fraudegevoelige applicatie, die nu nog vaak, zo niet altijd, per papier gaat. ICT/netwerk: Certificaten aanvragen: Dit gebeurt nu met een USB PKI token maar zou gebruikersvriendelijker worden door gebruik te maken van de mobiele telefoon. In het bijzonder zou er ook geen installatie van software op de PC nodig zijn. DNS registratie: Er is al een traject gestart om dit via SMS One-Time-Password te gaan doen, als step-up authenticatie. Mobile PKI zou zowel veiliger als gebruikersvriendelijker dan SMS OTP zijn. Account management bij instellingen: De Mobile PKI identiteit kan gebruikt worden om provisioning en wachtwoord-reset van accounts bij de aangesloten onderwijsinstellingen te regelen. Dit bespaart helpdesk kosten voor password reset, is gebruikersvriendelijker en veiliger. VPN authenticatie: Vanwege veiligheid (van het netwerk en identiteit van gebruikers) is hier een een hoog authenticatieniveau nodig.

T S

M O B I L E

P K I

27

6 Conclusies en aanbevelingen De vraag dient zich aan hoe Mobile PKI vergeleken kan worden met andere oplossingen. Wat zijn de Unique Selling Points van Mobile PKI? 









Mobile PKI gebruikt een “something you have” token, namelijk de SIM kaart in de mobiele telefoon. Daardoor sluit de oplossing vele problemen uit die bijvoorbeeld eenvoudige gebruikersnaam / wachtwoord authenticatie wel heeft. Bijvoorbeeld phishing aanvallen behoren tot het verleden. Net als bij gebruik van een TAN lijst wordt bij Mobile PKI een extern kanaal gebruikt. Mobile PKI heeft op het vlak van gebruiksgemak voordelen omdat de mobiele telefoon door veel gebruikers vaker meegedragen wordt dan een lijst met TAN codes. Net als bij gebruik van SMS-OTP wordt bij Mobile PKI een extern kanaal gebruikt, namelijk de mobiele telefoon van de gebruiker. Mobile PKI heeft als voordeel dat geen code overgetypt hoeft te worden op de PC. De PIN code is steeds dezelfde. Een ‘OTP token met display’ (of vergelijkbaar een bankcalculator) vereist ook dat een code wordt overgetypt. En de gebruiker kan zo’n token vergeten terwijl hij zijn mobiele telefoon doorgaans wel altijd meeneemt. Dit laatste nadeel geldt niet als de OTP token als een SIM toolit applicatie op de SIM kaart draait, in tegenstelling tot een apart hardware token. Ook een USB PKI token of PKI smartcard zal door de gebruiker vaker vergeten worden dan een mobiele telefoon, bovendien vereist deze soms PIN-code-invoer via een onvertrouwd PC toetsenbord (denk aan keyloggers en andere malware), en vereist deze geïnstalleerde hardware (een kaartlezer) en/of software (drivers, middleware).

Bovenstaande vergelijking kijkt alleen naar andere authenticatieoplossingen. Eigenlijk is alleen de laatste oplossing, de USB PKI token, vergelijkbaar met Mobile PKI aangezien hier ook elektronisch mee ondertekend kan worden. Merk op dat de over-the-air mogelijkheden van de SIM toolkit API aan Mobile PKI een extra voordeel bieden boven traditionele USB PKI tokens en smartcards. Dit maakt namelijk een flexibel migratiepad mogelijk van eenvoudige (niet gekwalificeerde) certificaten naar gekwalificeerde certificaten. De mobiele operator biedt als het ware een veilige verbinding met de SIM kaart zodat updates post-issuance uitgevoerd kunnen worden. De afhankelijkheid van de MO is meteen ook een zwakte van Mobile PKI. Invoeren kan alleen als samengewerkt wordt met een MO. Een heterogene groep gebruikers (met abonnementen bij verschillende MO’s) kan dus alleen gebruik gaan maken van Mobile PKI als alle MO’s meewerken. Op basis van het voorgaande en de conclusies uit de verschillende hoofdstukken (2.3, 3.6, 4.4) concluderen we: 

28

Mobile PKI technologie is gebaseerd op basisingredienten die al sinds 2001 bestaan en technisch volwassen en gestandaardiseerd zijn. Gebruik van open standaarden zorgt er voor dat IdP/AP’s zoals SURFnet relatief eenvoudig in kunnen stappen. Wel vereist de technologie behoorlijk geavanceerde (en dus dure) SIM’s. De mobiele operators, als eigenaar van de SIM, vervullen een sleutelrol bij de uitrol. Het invoeren van Mobile PKI op nationale schaal kan alleen als alle mobiele operators een dergelijk initiatief ondersteunen.

N O V A Y

De vraag waarom Mobile PKI nog niet grootschalig in Nederland is ingevoerd wordt niet in dit rapport beantwoord. De laatste jaren (2007 – 2009) is er wel wat beweging te constateren. Veel pilots zijn uitgevoerd of aangekondigd. Mobile PKI is ook reeds in gebruik genomen voor diensten voor banken, bijvoorbeeld in Turkije, Scandinavië en de Baltische staten. De leverancier van de in de pilot gebruikte technologie, Valimo, komt relatief vaak voor in berichtgeving en heeft partnerships met alle grote SIM kaart fabrikanten en veel Europese mobiele operators.

T S



De Mobile PKI architectuur is door standaardisatie zeer flexibel. Hierdoor zijn veel configuratievarianten mogelijk. De mobiele operator speelt in elke configuratievariant een centrale rol omdat deze de toegang tot de SIM kaart regelt.



Met de veiligheid van Mobile PKI zit het wel goed. Voor Mobile PKI implementaties bestaat een compleet programma van eisen opgesteld door ETSI. De Valimo implementatie voldoet aan deze eisen (voor zover de auteurs van dit rapport dat zelf hebben kunnen nagaan). Mobile PKI is veel sterker dan gebruikersnaam/wachtwoord want maakt op een essentiële manier gebruik van een de SIM kaart (die aan strenge Common Criteria eisen voldoet). Het enige bedreigende scenario, een “Mafia-in-the-Middle” uitgevoerd door een niet vertrouwde applicatieprovider danwel “Man-in-the-Browser”, is alleen mogelijk indien gebruikers niet goed opletten.



Gezien de toepassingen bij SURFnet is de beveiliging voor veel van de huidige toepassingen onnodig sterk. Dit hoeft niet erg te zijn, aangezien de oplossing wel gebruikersvriendelijk is, maar dit is wel afhankelijk van de kosten. Voor bepaalde doelgroepen (hoge veiligheid vereisend, voor laag aantal werknemers) is de oplossing wel interessant. Het lijkt raadzaam om de oplossing eerst uit te proberen met zulke doelgroepen, en verder af te wachten tot er een bredere adoptie is van Mobile PKI technologie in Nederlands, inclusief duidelijkheid over kosten ondersteuning door alle drie de mobiele operators. In de tussentijd kan wel overwogen worden SMS one-time-password meer te gaan gebruiken, voor step-up authenticatie, of password reset.

M O B I L E

P K I

29

Appendix A - Voorbeeld verzoek voor de MSSP Onderstaand XML document is een voorbeeld verzoek zoals die door de IdP (in het algemeen door een AP) aan de MSSP gestuurd kan worden. Wachtwoorden en telefoonnummers zijn weggehaald. <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <MSS_Signature xmlns="http://uri.etsi.org/TS102204/v1.1.2#"> <MSS_SignatureReq MinorVersion="1" MajorVersion="1" MessagingMode="synch" TimeOut="180"> <AP_Info AP_ID="http://mssp.valimo.com/diginotar" AP_TransID="_x0032_20091007T160109" AP_PWD="********" Instant="2009-10-07T16:01:09.+02:00" AP_URL=""/> <MSSP_Info> <MSSP_ID> <MobileUser> <MSISDN>+350000000000 data to sign data to display <SignatureProfile> <mssURI>http://mss.valimo.com/DiginotarDS C=fi, O=Valimo, OU=RSADevpCA

30

N O V A Y

Appendix B - Voorbeeld antwoord van de MSSP Onderstaand XML document is het antwoord dat de MSSP aan de AP gaf op het voorbeeld verzoek in Appendix A. Telefoonnummers zijn weggehaald. <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <MSS_SignatureResponse xmlns="http://uri.etsi.org/TS102204/v1.1.2#"> <MSS_SignatureResp xmlns="" MSSP_TransID="_9780" MajorVersion="1" MinorVersion="1"> <ns1:AP_Info xmlns:ns1="http://uri.etsi.org/TS102204/v1.1.2#" AP_ID="http://mssp.valimo.com/diginotar" AP_PWD="********" AP_TransID="_x0032_20091007T160236" Instant="2009-10-07T14:02:36.000Z"/> <ns2:MSSP_Info xmlns:ns2="http://uri.etsi.org/TS102204/v1.1.2#" Instant="2009-10-08T09:44:43.353Z"> <ns2:MSSP_ID> <ns2:DNSName>vasser.valimo.com <ns3:MobileUser xmlns:ns3="http://uri.etsi.org/TS102204/v1.1.2#"> <ns3:HomeMSSP> <ns3:DNSName>vasser.valimo.com <ns3:MSISDN>+350000000000 <ns4:MSS_Signature xmlns:ns4="http://uri.etsi.org/TS102204/v1.1.2#"> <ns4:Base64Signature>MIID4wYJKoZIhvcNAQcCoIID1DCCA9ACAQExCzAJBgUrDgMCGgUAMBsGCSqGSIb 3DQEHAaAOBAxkYXRhIHRvIHNpZ26gggJTMIICTzCCAbigAwIBAgIRAJAoedg0dZ6DJN8CjEHV4howDQYJKo ZIhvcNAQEFBQAwMjELMAkGA1UEBhMCZmkxDzANBgNVBAoTBnZhbGltbzESMBAGA1UECxMJUlNBRGV2 cENBMB4XDTA5MDYxNjE1MjM0MVoXDTEwMDYxNjE1MjM0MVowTjELMAkGA1UEBhMCZmkxDzANBgNVB AoMBlZhbGltbzEPMA0GA1UECwwGbm9ucmVwMR0wGwYDVQQDDBQ4OTM1ODAxMDgwMDg0NDAwNDk wRjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAkrhY5FCvJ8e9QFVZ38ieFH+58G4FaO20pDNJPSNX ka/mTrK8qv9VxJErGSSfUmbEMl9gwTgEa1edfIEHjcHOJMuBwBpPTaFl5KU0AOw/bdIflCqcwRhuSwHu7w7SD OCWzhQxE6PTeJFajPPQccttWnUN4Dn+MG8rzY6WnulyBSkCAwEAAaNJMEcwRQYDVR0fBD4wPDA6oDigN qQ0MDIxCzAJBgNVBAYTAmZpMQ8wDQYDVQQKEwZ2YWxpbW8xEjAQBgNVBAsTCVJTQURldnBDQTANB gkqhkiG9w0BAQUFAAOBgQBVKS9awWAC3Kk7YeRVquXXDjoHsEEL/GKjGTI+f76gdypfzrTuXza6KakO2nvk H4153gueyKvTJaArCAeDNMGke7Duvr0bdLROKlwJhC6j6ZAWwhxDuZ2ATW2aR1BWNR26DdlPt9tiaWVAiY WcIGKH1BUmW3qD4INIgbloYXcJcjGCAUgwggFEAgEBMEcwMjELMAkGA1UEBhMCZmkxDzANBgNVBAoTB nZhbGltbzESMBAGA1UECxMJUlNBRGV2cENBAhEAkCh52DR1noMk3wKMQdXiGjAJBgUrDgMCGgUAoFkw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAYBgoqhkiG9w0BCRkDMQoECEYZA9Fr9wIFMCMGCSqGSI b3DQEJBDEWBBTTLCzgXdd77zaHtA02FTL9QDBxbTANBgkqhkiG9w0BAQEFAASBgGXCKsUDJGxc5i7P2/sI rKEmw09okAV2xbo0Iciha2Oe/JsrYrNrJQBxmyaFATVI8T4pQCGFPEfRhTSR6DzFXudtaVY5jOTkzmDolRXQj WWEjbgmM/qqUClI+SMHd308wRPfEJ6f49fRUMll6BucK3DQ55JYimYMs4eWN5ovwty+ <ns5:SignatureProfile xmlns:ns5="http://uri.etsi.org/TS102204/v1.1.2#"> <ns5:mssURI>http://mss.valimo.com/DiginotarDS <ns6:Status xmlns:ns6="http://uri.etsi.org/TS102204/v1.1.2#"> <ns6:StatusCode Value="500"/>

T S

M O B I L E

P K I

31

Referenties [1] [2] [3]

[4] [5]

[6]

[7] [8] [9] [10] [11] [12] [13] [14] [15]

[16]

32

3G Americas, Identity Management – Overview of Standards & Technologies for Mobile and Fixed Internet, januari 2009 European Parliament and Council, Directive 1999/93/EC, Official Journal of the European Communities, 13 december 1999 CEN/ISSS, E-SIGN workshop - expert group F, Common Criteria EAL4+ Protection Profile - Secure Signature-Creation Device Type 3, Versie 1.05, 25 juli 2001 ETSI SR 002 176 Algorithms and Parameters for Secure Electronic Signatures ETSI, TS 100 977 v8.10.0 (2003-09), Digital cellular telecommunications system (Phase 2+); Specification of the Subscriber Identity Module – Mobile Equipment (SIM-ME) interface (3GPP TS 11.11 version 8.10.0 Release 1999), 2003 ETSI, TS 101 267 v8.13.0 (2003-03), Digital cellular telecommunications system (Phase 2+); Specification of the SIM Application Toolkit (SAT) for the Subscriber Identity Module – Mobile Equipment (SIM-ME) interface (3GPP TS 11.14 version 8.13.0 Release 1999), 2003 ETSI, TR 101 903 XAdES ETSI, TR 102 203 v1.1.1 – business functional requirements ETSI, TR 102 204 v1.1.4 – web service interface ETSI, TR 102 206 v1.1.3 – security framework ETSI, TR 102 207 v1.1.3 – roaming GlobalPlatform Card Specification Version 2.2, beschikbaar via http://www.globalplatform.org/, maart 2006 ISO/IEC, Identification cards – Integrated circuit cards Part 4: Organization, security and commands for interchange, ISO/IEC 7816-4: 2005 Sun, Java Card Platform Specification 2.2.2, beschikbaar via http://java.sun.com/javacard/specs.html. Elena Trichina, Konstantin Hypponen, Marko Hassinen, SIM-enabled Open Mobile Payment System Base don Nation-wide PKI, In proc. Secure Electronic Business Processes, 355 – 366, ISSE/Vieweg, 2007 WPKI Projectgroup, WPKI Main Specification, Rev. 2.2 (en appendices), beschikbaar via http://www.wpki.net/, 14 mei 2009

N O V A Y

T S

M O B I L E

P K I

33