NemID på Mobile Enheder

Til

Digitaliseringsstyrelsen

Dokumenttype

Teknisk arbejdspapir

Dato

Marts 2012

DIGITALISERINGS-STYRELSEN NEMID PÅ MOBILE ENHEDER - TEKNISK OG SIKKERHEDSMÆSSIG AFKLARING

DIGITALISERINGS-STYRELSEN NEMID PÅ MOBILE ENHEDER - TEKNISK OG SIKKERHEDSMÆSSIG AFKLARING

NemID på mobile enheder - Teknisk og sikkerhedsmæssig afklaring

Revision 1.2 Dato 29-03-2012 Ref. 70112791

3

INDHOLD

1. Executive summary 1

1.1 Brugernes muligheder 1

1.2 De undersøgte løsningsmuligheder 1

1.3 Samlet vurdering 3

2. Baggrund og formål 5

3. Kontekst og afgrænsning 5

3.1 Hvilke mobile enheder er omfattet af analysen 5

3.2 Målgrupper for analyserapporten 6

4. Ord og begreber 6

5. Tekniske forudsætninger 7

5.1 Smartphonens arkitektur 7

5.2 To veje til tjenester på mobile enheder 8

6. Opstilling af løsningsmodeller 9

6.1 Log-in og signering 9

6.2 Alternative løsninger 9

7. Overordnet om evalueringstilgangen og -metoden 10

7.1 Metodisk tilgang 10

7.2 Præmisser for udvælgelse 11

8. Teknisk og sikkerhedsmæssig analyse 12

8.1 Om opbygningen af dette afsnit 12

8.2 Om den tekniske analyse 12

8.3 Om den sikkerhedsmæssige analyse: sårbarheder og risikoanalyse 12

8.3.1 Om sikkerhedsbrud og -tiltag 13

8.3.2 Teknisk oversigt over sårbarheder 14

8.3.3 Sikkerhedskriterier 14

8.3.4 Mitigeringsstrategier 15

8.4 Native app 16

8.4.1 Statisk indlejret NemID-bibliotek 16

8.4.2 NemID app lokal 18

8.4.3 Interapp ekstern 20

8.5 Browserbaserede løsninger (web app) 20

8.5.1 Oracle Java Applet 20

8.5.2 Adobe Flash 20

8.5.3 JavaScript 21

8.5.4 Web proxy 23

8.6 Hybrid app 26

8.6.1 Hybrid - Indlejret statisk bibliotek intern browser 27

8.6.2 Hybrid – NemID app lokal intern browser 27

8.6.3 Hybrid - Dynamisk bibliotek intern browser 28

8.6.4 Hybrid – Dynamisk bibliotek intern browser (webservice) 30

8.6.5 Hybrid – Dynamisk bibliotek ekstern browser 31

8.6.6 Hybrid - Dynamisk bibliotek ekstern browser (webservice) 33

8.7 Opsamling på teknisk og sikkerhedsmæssig vurdering 34

8.8 Mitigeringsløsninger 35

8.8.1 Statisk indlejret NemID-bibliotek (N1) og Hybrid - Indlejret statisk bibliotek intern browser (H1) 35

8.8.2 NemID app lokal (N2) og Hybrid – NemID app lokal intern browser (H2) 35

8.8.3 Web proxy (W4) 35

8.9 Hvad skal en hybrid app give adgang til 35

4

8.10 Distribution og sikkerhedsniveau på app markets 35

8.11 Konklusion på den teknisk-sikkerhedsmæssige vurdering 36

9. Omkostninger til drift og udvikling 38

9.1 Overblik over tekniske komponenter i løsningerne 38

9.1.1 Statisk indlejret NemID bibliotek (N1) og Hybrid – Indlejret statisk bibliotek intern browser (H1) 38

9.1.2 NemID app lokal (N2) og Hybrid – NemID app lokal intern browser (H2) 39

9.1.3 Web proxy (W4) 39

9.2 Omkostningskomponenter 40

9.2.1 Digitaliseringsstyrelsens omkostninger til Statisk indlejret NemID bibliotek og NemID app lokal 40

9.2.2 Digitaliseringsstyrelsens omkostninger til de hybride løsninger 41

9.2.3 Digitaliseringsstyrelsens omkostninger til DanIDs snitflade og back-end 41

9.2.4 Digitaliseringsstyrelsens omkostninger til web proxy 41

9.2.5 Digitaliseringsstyrelsen omkostninger til DanIDs snitflade og backend til web proxy 42

9.2.6 Tjenesteudbydernes omkostninger til native app 42

9.2.7 Tjenesteudbydernes omkostninger til hybride app 42

9.2.8 Tjenesteudbydernes omkostninger til browserbaserede løsninger (web app) 42

9.2.9 Tjenesteudbydernes samlede omkostninger 42

9.3 Oversigt over omkostninger i løsningerne 43

10. Brugervenlighed 44

10.1 Er løsningen let at lære og let at huske 45

10.2 Er løsningen effektiv at bruge 45

10.3 Er løsningen rar at bruge 46

10.4 Tilgængelighed 46

10.5 Samlet vurdering 46

11. Dækning af private tjenesteudbydere 47

12. Konsekvenser for regler og standarder og for styring af området 48

13. Konsekvenser i forhold til kontrakt 49

13.1 Udbudsretlig vurdering af DanIDs kontrakter 49

13.1.1 Tilretninger af infrastruktur 49

13.1.2 Udvikling af applikationer til brug for infrastrukturen 49

13.2 Udbudsretlig vurdering af NNITs kontrakt 50

14. Projektrisici 51

14.1 Løsningernes tekniske robusthed, performance og modenhed 51

14.2 Projekt- og tidsplan 51

14.3 Risikoanalyse 53

14.4 Vurdering i forhold til tidsplan og projektrisici 54

15. Samlet vurdering 55

5

OVERSIGT OVER TABELLER OG FIGURER

Tabel 1: Oversigt over omkostninger ....................................................... 3

Tabel 2: Samlet vurdering ..................................................................... 4

Tabel 3: Oversigt over tjenesteudbydernes omkostninger .......................... 43

Tabel 4: Oversigt over omkostninger ..................................................... 43

Tabel 5: Brugervenlighed ..................................................................... 46

Tabel 6: Dækning af private tjenesteudbydere ........................................ 47

Tabel 7: Udviklingsopgaveplacering ....................................................... 50

Tabel 8: Tidsplan for EU-udbud ............................................................. 52

Tabel 9: Risici .................................................................................... 54

Tabel 10: Tidsplan og projektrisici ......................................................... 54

Tabel 11 Samlet vurdering ................................................................... 56

Figur 1: Metodisk tilgang ....................................................................... 2

Figur 2: Mobiltelefonarkitektur ................................................................ 7

Figur 3: Overordnet samspil mellem mobil enhed og tjenester ..................... 7

Figur 4: Metodisk tilgang ..................................................................... 10

Figur 5: Statisk indlejret NemID bibliotek ............................................... 16

Figur 6: NemID app lokal ..................................................................... 18

Figur 7: JavaScript ............................................................................. 22

Figur 8: Web proxy ............................................................................. 24

Figur 9: Krypteret tunnel – ubrudt og i proxy-løsningen ............................ 24

Figur 10: Hybrid med indlejret statisk bibliotek ........................................ 27

Figur 11: Hybrid – NemID app lokal intern browser .................................. 28

Figur 12: Hybrid - Dynamisk bibliotek intern browser ............................... 29

Figur 13: Hybrid - Dynamisk bibliotek intern browser (webservice) ............. 31

Figur 14: Hybrid - Dynamisk bibliotek ekstern browser ............................. 32

Figur 15: Hybrid - Dynamisk bibliotek ekstern browser (webservice) ........... 34

Figur 16: Komponenter i Statisk indlejret NemID bibliotek og hybrid ........... 38

Figur 17: NemID app lokal og hybrid ..................................................... 39

Figur 18: Web proxy ........................................................................... 40

Figur 19: App use case ........................................................................ 44

Figur 20: Web use case ....................................................................... 45

Figur 21: Projektplan .......................................................................... 53

1


1. EXECUTIVE SUMMARY

Formålet med analysen er at afdække de tekniske muligheder for at tilbyde en sikker login-løsning med NemID og NemLog-in på mobile enheder, herunder at afdække begrænsninger, risi-ci, sikkerhed, økonomi og brugervenlighed ved forskellige løsninger. Analysen skal danne grundlag for, at der kan træffes en kvalificeret beslutning om valg af løsning med henblik på efterfølgende specifikation, udvikling, implementering og drift. Baggrunden er, dels at det offentlige har valgt NemID og NemLog-in som grundlag for offentlige selvbetjeningsløsninger, dels at udbredelsen af mobile enheder som smartphones og tablets sti-ger. I juni 2011 havde således 1,5 mio. danskere en smartphone ifølge Gallup. Rapporten er en del af arbejdet med at udmønte Digitaliseringsstrategiens initiativ 1.6: Borgerne kan betjene sig selv på mobilen. Selve analysen er et resultat af Digitaliseringsstrategiens initia-tiv 9.1: Sikker digital selvbetjening på mobilen.

1.1 Brugernes muligheder Brugerne har to grundlæggende muligheder for at bruge tjenester på en mobil enhed – ved at afvikle programmer (native app) eller ved at browse hjemmesider (web app) via mobiltelefonens browser. Anvendelse af apps er meget udbredt og understøttes af leverandørerne med markedspladser (App Store, Android Market, Windows Marketplace) for apps, som brugerne kan downloade gratis eller mod betaling. Apps er operativsystemspecifikke, hvilket betyder, at tjenesteudbyderen skal udvikle og vedligeholde en app-version for hvert operativsystem. Apps bygger på teknologier, der gør det vanskeligt at bygge på NemLog-in-infrastrukturen (med SSO, brugeradministration og fuldmagter). Anvendelse af en browser (web app) til at tilgå en tjeneste vil blive mere mobil-egnet med intro-duktionen af HTML5-standarden, der giver mulighed for en forbedret navigation og brugerople-velse. Her bruges browseren til at tilgå en hjemmeside på samme måde som med en PC. Hjem-mesiden bør være tilpasset den mobile enhed. Browserbaserede løsninger kan umiddelbart gen-bruge den fællesoffentlige infrastruktur via NemLog-in. Det er Rambølls vurdering, at både native apps og web apps vil have stor udbredelse i de kom-mende 2-4 år. Analysen vurderer derfor muligheden for at understøtte NemID med både native og web apps.

1.2 De undersøgte løsningsmuligheder Der er undersøgt løsninger til tre operativsystemer til mobile enheder (iOS, Android og Windows Phone 7) og tre grundlæggende løsningsdesigns. Det ene løsningsdesign baserer sig på native app, det andet på web apps, mens det tredje kombinerer de to veje i hybride løsninger. Inden for hvert løsningsdesign er der yderligere løsningsvarianter, der er behandlet i analysen og gennem-gået herunder. Der er undersøgt i alt 13 løsningsvarianter i en proces, hvor der først er gennemført en teknisk og sikkerhedsmæssig vurdering af løsningerne.

2


Figur 1: Metodisk tilgang

Af de 13 løsningsvarianter er de 8 sorteret fra, fordi de ikke er teknisk mulige, eller fordi de har store sikkerhedsmæssige svagheder. Tilbage er fem løsningsvarianter, der er teknisk mulige, og som på forskellig måde kan opnå en høj - men ikke tilstrækkelig høj - sikkerhed gennem mitigeringstiltag, dvs. tiltag for at øge sik-kerheden. De fire løsningsvarianter danner to par baseret på native apps, hvor native app-løsningen i hvert par er suppleret med en hybrid løsning, der kan genbruge NemLog-in-infrastrukturen. Hertil kommer web proxy-løsningen, som er en web app. Sikkerheden i de fem løsninger er præget af, at operativsystemerne til mobile enheder på nogle områder er mere sikre end PC-operativsystemer. De tre mobile operativsystemer understøtter dog ikke samme sikkerhedstiltag, og det er derfor vanskeligt at finde fælles løsninger, der under-støtter de høje krav til sikkerhed, som kræves i forbindelse med anvendelse af NemID. Det vurderes, at de væsentligste sårbarheder for angreb for NemID-løsningen på mobile enheder vil være hos brugeren og i selve den mobile enhed. Sårbarheder hos brugeren (valg af sikre ko-der, sikker brugeradfærd) adskiller sig ikke væsentligt fra PC’en. I vinteren 2011-2012 har phishing mod NemID-bankløsninger været det mest omtalte i medierne, og phishing kan også forventes i forbindelse med mobile enheder. For at modvirke phishing skal brugeren kunne se på skærmen, hvad han gør, og om han tilgår en legitim tjeneste, ved f.eks. at URL vises. Sårbarheden i den mobile enhed er bestemt af, at det ikke er muligt at anvende Java applet-teknologien på mobile enheder. På PC’er giver applet-teknologien en meget høj sikkerhed (den downloades hver gang og er signeret af DanID), mens der ikke er tilsvarende sikre løsninger for den kode, der skal afvikles på den mobile enhed. Da gevinsterne for hackere ved at bryde sikkerheden er store, kombineret med at risikoen for pågribelse og straf er lille, er erfaringerne, at hackere i stigende grad forsøger at udnytte eksiste-rende såvel som ny-introducerede sårbarheder. Erfaringerne viser ydermere, at kendte og identi-ficerede sikkerhedsbrud er blevet gennemført ved at kombinere flere sårbarheder. Efter den tekniske og sikkerhedsmæssige vurdering er de fem løsninger vurderet i forhold til:

• Omkostninger til drift og udvikling • Brugervenlighed • Dækning af private tjenesteudbydere • Konsekvenser for regler og standarder • Konsekvenser i forhold til Digitaliseringsstyrelsens kontrakter • Projektrisici, herunder tidsplaner

Omkostningsvurderingen omfatter både de centrale, fælles omkostninger og tjenesteudbyder-nes omkostninger til at implementere log-in. Derimod indgår omkostninger til at tilpasse tjene-sternes design til de mobile enheders skærmformater ikke.

3


For de fælles komponenter er omkostningsniveauet for alle løsninger over budgettet til initiativ 9.1 på 8 mio. kr. (angivet med en rød smiley).

Tabel 1: Oversigt over omkostninger

Fælles om-kostninger

Omkostninger tjenesteudbydere

Samlede omkostninger for det offentlige

Native App - Indlejret statisk bibliotek (N1)

Over budget 15-30 mio. kr. Ikke tilfredsstillende

Hybrid - Indlejret statisk bibliotek intern browser (H1)


Native App - NemID app lokal (N2)


Hybrid – NemID app lo-kal intern browser (H2)


Web Proxy (W4) Over budget 0 kr. Ikke tilfredsstillende

Oversigten over omkostninger viser, at de to løsninger med native apps vil blive dyre for tjene-steudbyderne, og at de hybride løsninger kun vil have lidt mindre omkostninger for tjenesteud-byderne. Et samarbejde mellem tjenesteudbydere om at samle flere tjenester i en app kan være med til at begrænse omkostningerne yderligere. Omvendt kan omkostningerne betyde, at nogle tjenesteudbydere vil fravælge den mobile løsning. Brugervenligheden er vurderet ud fra forskellige dimensioner (er løsningen let at lære og let at huske, effektiv og rar at bruge samt tilgængelig). For brugerne vil log-in være en del af den samlede brugeroplevelse, som vil være bestemt af tje-nestens design og tilpasning til brugerens brugssituation og den mobile enheds skærm. For bru-geren vil det være den samlede brugeroplevelse, der har betydning for brugervenligheden, mens denne analyse alene har fokus på log-in funktionen. De hybride løsninger har lavere brugervenlighed, da de kræver download og vedligehold af en ekstra app. Native apps og proxy har samme niveau af brugervenlighed. Tilgængeligheden er den samme for løsningerne, men der er forskelle på operativsystemerne. Det er muligt at udvikle løsninger til blinde og svagtseende til iOS og Android, men ikke til den nuværende version af Windows Phone 7. Projektrisici og tidsplan er præget af, at der ved alle fem løsninger er behov for større udvik-lingsarbejde. Det betyder, dels at der skal afsættes tid til udvikling og test af løsningerne, dels at der i alle løsninger indgår komponenter, der skal anskaffes gennem EU-udbud. Ingen af de fem løsninger vil derfor kunne blive etableret inden udgangen af 2012.

1.3 Samlet vurdering Den samlede vurdering af de fem løsningsvarianter i analyserapporten er, at ingen af dem lever op til kravene om høj sikkerhed. De fælles omkostninger vil for alle løsningerne overstige budget-tet til Digitaliseringsstrategiens initiativ 9.1: Sikker digital selvbetjening på mobilen. Hertil kom-mer, at fire løsninger (app og hybride) vil medføre omkostninger for tjenesteudbyderne. To af løsningerne lever ikke op til krav om brugervenlighed.

4


Tabel 2: Samlet vurdering

Sikkerhed Samlet øko-nomi

Brugervenlighed


Betinget sikker Ikke tilfredsstillende

God

Hybrid - Indlejret statisk bib-liotek intern browser (H1)


Mindre god



God

Hybrid – NemID app lokal in-tern browser (H2)


Mindre god

Web Proxy (W4) Ikke sikker Ikke tilfredsstillende

God

Også i forhold til de øvrige kriterier som tid og risiko er løsningsvarianterne mangelfulde.

5


2. BAGGRUND OG FORMÅL

Formålet med analysen er at afdække, hvilke tekniske muligheder der er for at tilbyde en sikker log-in-løsning med NemID og NemLog-in på mobile enheder, herunder at afdække begrænsnin-ger, risici, sikkerhed, økonomi og brugervenlighed ved forskellige løsninger. Analysen skal danne grundlag for, at der kan træffes en kvalificeret beslutning om valg af løsning med henblik på efterfølgende specifikation, udvikling, implementering og drift. Baggrunden er, dels at det offentlige har valgt NemID og NemLog-in som grundlag for offentlige selvbetjeningsløsninger, dels at udbredelsen af mobile enheder som smartphones og tablets sti-ger. I juni 2011 havde således 1,5 mio. danskere en smartphone ifølge Gallup.1 Digitaliseringsstrategien har derfor et initiativ 1.6: Borgerne kan betjene sig selv på mobilen. Selve analysen er et resultat af Digitaliseringsstrategiens initiativ 9.1: Sikker digital selvbetjening på mobilen.

Den hurtige udbredelse af smartphones o.l. giver borgerne endnu bedre muligheder for at kommunikere digitalt med det offentlige. I første omgang gøres digital post og Min Side på borger.dk mobile, så borgerne kan have overblikket over deres kommunikation med det offentlige med ”i lommen”. Digitaliseringsstrategien

Brugen af mobile klienter som for eksempel smartphones breder sig eks-plosivt i disse år. I besøgsstatistikker for de fleste netsteder kan man se, at andelen af visninger på mobile enheder er stigende måned for måned. De eksplosive vækstrater betyder, at antallet af mobile brugere på internettet inden for ganske få år vil overhale antallet af traditionelle ”desktop”-brugere. Samtidig forventer nye generationer, at tjenester leveres på alle platforme, herunder mobile. For offentlige myndigheder er mobile tjenester særligt interessante i er-kendelsen af, at de traditionelle digitale selvbetjeningsløsninger ikke har realiseret potentialet. Det er således langt fra alle borgere og virksomhe-der, der udnytter de digitale tjenester, som stilles til rådighed, og dermed realiseres gevinsterne ved digitaliseringen ikke. I den henseende udgør den mobile teknologi en mulighed for at øge brugen af de digitale løsninger via nye kanaler. Fra udbudsmaterialet

Rapporten beskriver, hvilke forhold der gælder for etablering af NemID på mobile enheder, hvilke løsningsmuligheder der er, og hvilken løsning der anbefales.

3. KONTEKST OG AFGRÆNSNING

3.1 Hvilke mobile enheder er omfattet af analysen Mobile enheder er først og fremmest smartphones, der er kendetegnet ved at være computere i ”mobiltelefonstørrelse”. Mobile enheder omfatter også tablets, dvs. håndholdte enheder i størrelse mellem mobiltelefonen og den bærbare PC. Tablets er netopkoblet trådløst (WIFI) eller med mobil dataadgang. Medio 2011 havde 175.000 danskere adgang til en tablet, og i 2012 forventer yderligere 300.000 at få adgang til en tablet.2 Sammen med smartphones vil tablets være udbredt hos mange borgere, og det kan forventes, at mere og mere internetbrug vil ske fra smartphones og tablets. Analysen dækker efter opdrag fra Digitaliseringsstyrelsen mobiltelefoner med de tre operativsy-stemer: iOS (Apple), Android (Google) og Windows Phone 7 (Microsoft). Android og iOS er de

1 http://www.specialmedierne.dk/sites/default/files/Gallup-mobile%20devices%202011.pdf 2 http://www.specialmedierne.dk/sites/default/files/Gallup-mobile%20devices%202011.pdf

6


mest udbredte i 2011 og forventes sammen med Windows Phone 7 (og 8) at blive de mest ud-bredte i de kommende år3. Tablets fra Apple og tablets med Android som operativsystem fungerer stort set som mobiltelefo-nen. Den væsentligste forskel er, at tablet’en har større skærm, hvilket betyder, at nogle pro-grammer er målrettet den ene platform. Det betyder, at løsninger for smartphones også vil kun-ne anvendes på tablets med iOS og Android. Microsoft har derimod meddelt, at de vil bruge PC-versionen af Windows 8 til tablets. Konsekven-serne heraf indgår ikke i denne rapport.

3.2 Målgrupper for analyserapporten Målgrupperne for analysen er flere. Executive summary er målrettet beslutningstagere. Rapporten er rettet til eksperter i forhold til mobile løsninger og sikkerhed. Der er lagt vægt på faglig dybde, og der vil blive brugt tekniske fagudtryk for at give baggrunden for de anbefalede løsninger. Dele af rapporten kan dog læses af en bredere målgruppe, der skal have alment kend-skab til mobile teknologier og sikkerhedsmæssige problemstillinger.

4. ORD OG BEGREBER

Her præsenteres og defineres de mest centrale begreber, der bruges på tværs i rapporten. De tekniske begreber forklares og defineres i det tekniske afsnit. Mobil enhed En mobiltelefon (smartphone) eller en tablet

Operativsystem iOS, Android, Windows Phone 7 App Bruges om en native app Applikation De programmer, der viser en brugergrænse-

flade og kommunikerer med en tjeneste Browser Der er browsere til mobile enheder, der svarer

til browsere til PC’er. Browseren kommunikerer med tjenesteudbyderens webserver (http og html)

Native app En applikation til en mobil enhed, der kommu-nikerer med tjenestens server med servicekald (SOAP, REST)

Web app En løsning, der bruger browseren til kommuni-kation med tjenestens webserver

3 I fjerde kvartal 2011 var Android på 50,9 procent af de solgte smartphones. På anden- og tredjepladsen er henholdsvis Apples iOS med 23,8 procent og

Symbian (Nokia) med 11,7 procent. KGartner report "Market Share: Mobile Devices by Region and Country, 4Q11 and 2011."

7


5. TEKNISKE FORUDSÆTNINGER

5.1 Smartphonens arkitektur

De smartphones, der er i fokus i denne analyse, har en arkitektur, der forenklet kan beskrives som følger:

• Applikationslaget, hvor analysen har fokus på to typer, browsere (web apps) og native apps.

• Operativsystemet. Her har analysen fokus på tre operativsystemer: iOS, Android og Windows Phone 7. Der er en række andre operativsystemer så-som Symbian, Blackberry.

• SIM-kortet, som er kernen i mobiltele-foni og datakommunikation. Det leve-res af teleselskabet og produceres af en mindre gruppe af internationale le-verandører af SIM-kort (f.eks. Gemal-to, Oberthur).

• Mobiltelefonens hardware – skærm, mikrofon, højttaler mm. Hardware le-veres af leverandører såsom Nokia, HTC mv.

Figur 2: Mobiltelefonarkitektur

Tegningen herunder viser helt overordnet de vigtigste infrastrukturelle elementer, der er involve-ret i at tilvejebringe NemID funktionalitet på selvbetjeningsløsninger, der skal gøres tilgængelige på mobile enheder.

Figur 3: Overordnet samspil mellem mobil enhed og tjenester

Understøttelse af NemID på mobile enheder skal ske på basis af operativsystemet, og analysen koncentrerer sig om tre operativsystemer, iOS, Android og Windows Phone 7. Alle tre operativsystemer er unge i forhold til operativsystemerne for PC’er, og det betyder, at der sker løbende forbedringer i nye versioner. En løsning til NemID skal tage højde for disse æn-dringer, ved at der indtænkes løbende udvikling og tilpasning til nye versioner. De mobile operativsystemer er alle designet med et stort fokus på sikkerhed og sikkerhedsrelate-rede aspekter som et centralt omdrejningspunkt i relation til deres kernefunktionalitet. Selvom de mobile operativsystemer alle varierer på tværs af den faktiske implementering af deres sik-kerhedsmodel, så har de det til fælles, at de alle skiller de sig ud fra deres "søskende" på desktop platformen på en række centrale områder.

8


Eksempler på områder, hvor de skiller sig ud fra desktop verdenen, er f. eks. med hensyn til ejerskabsbegrebet af applikationer, dvs. brugen af digitale signatur i relation til udgivet applikati-oner. Dette giver brugeren mulighed for at tjekke identiteten af firmaet, organisationen eller fol-kene bag en given app og på baggrund af dette vurdere, hvorvidt de stoler på og vil bruge app'en. Derudover er der et større fokus på isolationsteknikker, herunder brugen af sandkasse-begrebet. Disse isolationsteknikker er et forsøg på at sikre data applikationer imellem samt mel-lem operativsystem-kritiske områder og de enkelte apps. Et yderligere eksempel er brugen af til-ladelsesbaseret adgangskontrol, som styrer hvilke funktioner, operationer og data de enkelte apps kan tilgå. Et andet centralt aspekt de mobile operativsystemer anvender, er brugen af en systembred kryptering af data (dog i varierende grad), som ligger på enheden, som sikkerhed imod datatyveri ved tab af selve enheden. De tre mobile operativsystemer understøtter dog ikke samme sikkerhedstiltag, og det er derfor vanskeligt at finde fælles løsninger, der understøtter de høje krav til sikkerhed, som kræves i forbindelse med anvendelse af NemID.

5.2 To veje til tjenester på mobile enheder Brugerne har to grundlæggende muligheder for at bruge tjenester på en mobil enhed – ved at afvikle programmer (native app) eller ved at browse hjemmesider (web app). Anvendelse af apps er meget udbredt og understøttes af leverandørerne med markedspladser (App Store, Android Market, Windows Marketplace) for apps, som brugerne kan downloade gratis eller mod betaling. Her kan tjenesteudbyderne placere deres apps, som kan målrettes brugernes anvendelse af tjenesten. eBoks er et eksempel på en tjenesteudbyder, som har valgt at udvikle en app, så brugerne får en smartphone-tilpasset adgang til eBoks. Apps er programmer, som installeres på mobiltelefonen og afvikles under dens operativsystem. De findes i forskellige varianter. Nogle er store programmer, som alene afvikles på mobilenhe-den. En anden type kombinerer afvikling på mobilenheden med kommunikation til en server, hvor der hentes oplysninger, som præsenteres i app’en. Den simpleste form for app wrapper (kalder) er blot en browser med en URL og fungerer derfor blot som en genvej. Apps kommuni-kerer med servere med forskellige teknologier som REST eller SOAP. Apps er operativsystemspecifikke, hvilket betyder, at tjenesteudbyderen skal udvikle og vedlige-holde en app-version for hvert operativsystem. Apps skal downloades og installeres på mobilenheden af brugeren. Det sker fra operativsyste-mernes webshops, der har forskellige spilleregler for de apps, der kan hentes. Apps bygger på teknologier, der gør det vanskeligt at bygge på NemLog-in-infrastrukturen (med SSO, brugeradministration og fuldmagter), der er baseret på OIOSAML-standarden og dermed på http-protokollen. NemLog-in vil fra 2012 understøtte SOAP med identitetsbaserede webservices (OIOIDWS), men standarden kræver en tilføjelse og implementering af en ny profil for at kunne understøtte log-in fra mobile enheder. REST understøttes ikke i NemLog-in-infrastrukturen. Anvendelse af en browser (web app) til at tilgå en tjeneste vil blive mere mobil-egnet med intro-duktionen af HTML5-standarden, der giver mulighed for en forbedret navigation og brugerople-velse. Her bruges browseren til at tilgå en hjemmeside på samme måde som med en PC. Hjem-mesiden kan være tilpasset den mobile enhed:

• Skærmstørrelsen betyder behov for at tilpasse layout og indhold til en mindre skærmstør-relse

• Browsere i mobile løsninger har andre (og i et vist omfang færre) funktioner end en brow-ser til en PC.

Browserbaserede løsninger (web apps) kan umiddelbart genbruge den fællesoffentlige infrastruk-tur via NemLog-in. Begge veje har stor udbredelse, og det er Rambølls vurdering, at det også vil være tilfældet i de kommende 2-4 år. Analysen vurderer derfor muligheden for at understøtte NemID begge veje.

9


6. OPSTILLING AF LØSNINGSMODELLER

Formålet med den tekniske gennemgang er at give et 360◦ overblik over de muligheder, der er for at understøtte NemID på mobile enheder. Digitaliseringsstyrelsen har i udbudsmaterialet opstillet 3 løsningsdesigns til behandling. Det ene løsningsdesign baserer sig på native apps, det andet på web apps, mens det tredje kom-binerer de to veje i hybride løsninger. Inden for hvert løsningsdesign er der yderligere løsningsvarianter, der er behandlet i analysen og gennemgået herunder. Der er undersøgt tre løsningsvarianter med native apps. Fælles for dette løsningsdesign er, at koden til at understøtte NemID’s funktionalitet er indbygget i app’en:

• Statisk indlejret NemID-bibliotek, som bygger på et kodebibliotek, som app-udviklere skal indlejre i app-koden (N1)

• NemID app lokal, som bygger på en NemID-app, som skal kaldes af tjenesteudbyderens app. Kommunikationen mellem de to apps sker lokalt på den mobile enhed (N2)

• NemID app ekstern, som bygger på en NemID-app, som skal kaldes af tjenesteudbyde-rens app. Kommunikationen mellem de to apps sker via en ekstern server (N3).

Der er undersøgt fire browserbaserede løsningsvarianter (web apps). Fælles for dette løsningsde-sign er, at koden til at håndtere log-in med NemID overføres dynamisk ved hvert log-in fra en server til den mobile enheds browser:

• Oracle Java Applet, svarende til PC-løsningen (W1) • Adobe Flash, som bygger på Flash-teknologien (W2) • JavaScript (W3) • Web proxy, hvor der etableres en proxy mellem den mobile enhed og NemID-serverne

(W4). Der er undersøgt seks løsningsvarianter med kombinationer af native apps og browsere (web apps). Fælles for dette løsningsdesign er, at en native app styrer log-in og adgang til indhold med brug af en browserkomponent. Hybridmodellerne kombinerer derfor flere mulige løsningsde-signs, herunder at kommunikation med NemID-serveren sker udelukkende via den native app, udelukkende via en browser, eller via en lokal, men selvstændig NemID app. Der er undersøgt følgende løsningsvarianter:

• Hybrid - Indlejret statisk bibliotek intern browser (H1) • Hybrid – NemID app lokal intern browser (H2) • Hybrid - Dynamisk bibliotek intern browser (H3a) • Hybrid - Dynamisk bibliotek intern browser (webservice) (H3b) • Hybrid - Dynamisk bibliotek ekstern browser (H4a) • Hybrid - Dynamisk bibliotek ekstern browser (webservice) (H4b).

6.1 Log-in og signering NemID understøtter både log-in (autentifikation af en bruger) og digital signering. Analysen be-handler understøttelse af begge funktioner på mobile enheder, og de tekniske og sikkerheds-mæssige analyser i denne rapport (afsnit 8) er gældende både for login- og signeringsfunktionali-tet. Selvom der ikke er noget teknisk til hinder for, at man kan signere vilkårlige dokumenter på en mobil enhed, ligger der alligevel nogle store begrænsninger i, at brugeren skal kunne læse det, der skrives under på. I analysen behandles denne type begrænsninger ikke.

6.2 Alternative løsninger Rambøll har desuden afdækket markedet for at afklare, om andre løsningsdesigns kunne være relevante.

10


I bl.a. Finland har man således lavet en løsning, der baserer sig på opbevaringen af digitale certi-fikater på mobiltelefonens SIM-kort. En sådan løsning kræver specielle SIM-kort med tilstrække-lig kapacitet samt passende software på kortet. Eksisterende SIM-kort skal således skiftes ud med disse ekstra sikrede udgaver. En lignende løsning eksisterer i Norge, hvor der ligeledes kræves et specielt SIM-kort. Sverige havde tidligere en lignende løsning, men tilbyder nu en løsning meget lig den, DanID til-byder til de danske banker, dvs. at der ikke længere kræves et specielt SIM-kort. Den svenske løsning understøtter officielt kun mobiltelefoner med iOS og Android operativsystemer, men man er ved at evaluere andre operativsystemer som del af en større test. Den norske løsning rammer lidt bredere, da det meste af funktionaliteten ligger i SIM-kortet. En løsning baseret på SIM-kort kræver aftaler med alle leverandører af mobiltelefoni om udrul-ning af certifikater. Løsningen skal desuden fungere, så brugernes certifikat kan overføres mel-lem teleselskaber. Dette vanskeliggøres af det liberaliserede telemarked med mange teleoperatø-rer. Endelig skal en SIM-kort-baseret infrastruktur kunne spille sammen med NemID-infrastrukturen, så brugerne kan anvende samme NemID på PC og mobilenhed. Dette vil kræve en større teknisk indsats. På den baggrund er løsningen ikke analyseret yderligere.

7. OVERORDNET OM EVALUERINGSTILGANGEN OG -METODEN

7.1 Metodisk tilgang

De tre løsningsdesigns med løsningsvarianter er vurderet i en proces, hvor der først er gennem-ført en teknisk og sikkerhedsmæssig vurdering af løsningerne.

Figur 4: Metodisk tilgang

De opstillede løsningsmodeller og -varianter for understøttelse af NemID på mobile enheder er vurderet ud fra, om de er teknisk gennemførbare (dvs. om de kan implementeres på de respekti-ve operativsystemer), om de er sikkerhedsmæssigt tilfredsstillende, og om de kan indgå i Nem-Log-in-infrastrukturen (OIOSAML og single sign-on). Den tekniske analyse omfatter krav om brugerrettet funktionalitet, dvs. krav om autentifikation og signering og krav om applikationsrettet funktionalitet, herunder krav om sikker kommunikati-on til DanID, verifikation af digital signatur, beregning af digest (kode til signering), kryptering og dekryptering. Desuden indeholder den tekniske analyse en vurdering af løsninger ift. en række tekniske krav og kriterier, som f.eks. hastighed, understøttelse af sandkasse, overholdelse af kryptografiske standarder og fremtidssikre teknologier og udbredelse.

11


Den sikkerhedsmæssige analyse består af en række delanalyser ift. forskellige sikkerhedsrisici og angrebstyper, herunder jailbreaking, phishing, ”Man-in-the-browser”, ”Man-in-the-data” og ko-demanipulation samt en vurdering af relevante mitigeringstiltag for at forhindre de identificerede angrebsformer. Resultatet af dette trin har været at opstille kandidater til nærmere vurdering. Denne første filtrering har identificeret fem løsninger, som derefter er vurderet i forhold til:

• Omkostninger til drift og udvikling • Brugervenlighed • Dækker løsningen også private tjenesteudbydere • Konsekvenser for regler og standarder • Konsekvenser i forhold til Digitaliseringsstyrelsens kontrakter • Projektrisici, herunder tidsplaner.

Ud fra det er der udarbejdet en samlet vurdering og anbefalinger.

7.2 Præmisser for udvælgelse Understøttelse af NemID på mobile platforme har som grundlæggende forudsætning, at sikker-heden lever op til OCES-standarden4, og at sikkerhedsniveauet er på niveau med den nuværen-de NemID. Baggrunden for det er, at OCES-standarden er anerkendt af Datatilsynet som tilstrækkelig til an-vendelse i forhold til kommunikation med offentlige myndigheder om persondata, og den mulig-gør således digital forvaltning. Det er derfor vedtaget fællesoffentligt, at OCES/NemID skal an-vendes bredt i den offentlige sektor til offentlig digital selvbetjening. Samtidig giver et ensartet sikkerhedsniveau mulighed for, at sikkerheden løbende skal kunne overvåges og tilpasses cen-tralt, når der viser sig svagheder Set fra tjenesteudbydernes synsvinkel er der afgørende fordele ved en løsning, der gør det muligt for de offentlige tjenesteudbydere at anvende den NemLog-in-infrastruktur, der er opbygget til web-løsninger. Det betyder, at snitfladen til NemLog-in baseret på OIOSAML også anvendes til mobile enheder. Der vil være store økonomiske gevinster ved at genanvende denne infrastruktur til NemID på mobile enheder. Da nogle tjenesteudbydere kan forventes at opnå størst brugeranvendelse ved en native app-løsning, vil det være en fordel, at en løsning også kan understøtte native apps. Kravet om et højt sikkerhedsniveau skal balanceres mod krav om en løsning, der er økonomisk overkommelig for samfundet, dvs. både for Digitaliseringsstyrelsen som ejer af systemet og for tjenesteudbyderne. I lyset af at der sker en kraftig stigning i udbredelsen af mobile enheder, skal en løsning også kunne etableres rimeligt hurtigt. Flere tjenesteudbydere har etableret egne løsninger, og en fælles løsning bør derfor etableres inden udgangen af 2012. Da NemID blev etableret, var det væsentligt, at der blev skabt en løsning, der bygger på en fæl-les infrastruktur til det offentlige og til bankerne, og som baserer sig på de samme identiteter. Det sikrer en stor udbredelse og dermed en hyppig anvendelse af NemID. Det er derfor også et mål, at NemID for mobile enheder kan anvendes både af myndigheder og private. Da Nem-Log-in ikke anvendes af alle offentlige myndigheder og ikke kan anvendes af private, skal en løs-ning tage højde herfor. I projektets mål ”Borgerne kan betjene sig selv på mobilen” er det ikke nærmere angivet, hvilke offentlige løsninger der forventes at tilbyde mobil adgang. Vurderingen af løsningsmulighederne tager derfor udgangspunkt i, at en bred vifte af offentlige selvbetjeningsløsninger skal anven-de NemID på mobile enheder.

4 https://www.nemid.nu/digital_signatur/oces-standarden/

12


8. TEKNISK OG SIKKERHEDSMÆSSIG ANALYSE

8.1 Om opbygningen af dette afsnit Afsnittet "Teknisk og sikkerhedsmæssig analyse" er målrettet tekniske eksperter og er meget de-taljeret. Dog er dele af afsnittet mindre teknisk præget. I det følgende præsenteres opbygningen af afsnittet. I afsnit 8.2 beskrives indholdet af den tekniske analyse meget kort. I afsnit 8.3 gives baggrundsinformation om den sikkerhedsmæssige analyse. Her beskrives først sikkerhed generelt, og hvordan analysen er gennemført, herunder hvordan risiko og konsekvens er vurderet for at nå frem til en samlet risikovurdering. I resten af dette afsnit beskrives sikkerhedsaspekter stadig mere detaljeret og teknisk. Særligt afsnit 8.3.2, 8.3.3 og 8.3.4 er målrettet eksperter, da de indeholder definitioner af begreber, som anvendes i gennemgangen af de enkelte løsningsvarianter. Herefter gennemgås løsningsvarianter baseret på native apps – afsnit 8.4 - og browserbaserede løsninger (web apps) – afsnit 8.5 I afsnit 8.6 gennemgås hybride apps. Disse løsningsvarianter nedarver egenskaber fra native apps og browserbaserede løsninger, og for at undgå gentagelser, henvises til disse i nogle af af-snittene. I alle tre nævnte afsnit de mest tekniske overvejelser og vurderinger placeret i ramme. Den læ-ser, der ønsker en hurtig gennemlæsning, kan springe til slutningen af hvert afsnit til Risikoana-lyse. I afsnittene 8.7-8.11 samles der op og konkluderes.

8.2 Om den tekniske analyse I den tekniske analyse vurderes, hvilke muligheder og begrænsninger de enkelte løsningsvarian-ter har. Det omfatter bl.a., om teknologien understøttes på de tre operativsystemer, og om hastigheden er tilfredsstillende. På nogle områder lever alle løsningsvarianterne op til de tekniske krav, f.eks. vedrørende krypteringsteknologier.

8.3 Om den sikkerhedsmæssige analyse: sårbarheder og risikoanalyse I sikkerhedsanalysen vurderes de enkelte løsningsvarianter i forhold til sikkerhedsniveau og kendte sårbarheder. Overordnet set kan sikkerheden siges at bygge på følgende hovedelementer:

• Operativsystemet (iOS, Android, WP7) og de medfølgende applikationer, herunder brow-sere. Hvor sikkert er operativsystemet? Hvilke sårbarheder kan konstateres? Og hvilke muligheder er der for at modvirke sårbarheder?

• Den applikation, der håndterer kommunikation med NemID-serverne hos Nets/DanID.

• Brugerens adfærd i form af bevidste ændringer i operativsystem og medfølgende applika-

tioner: jailbreaking, installation af browsere, mv. Sådanne ændringer kan introducere sårbarheder, som kan udnyttes af hackere. Hertil kommer, at flere sikkerhedsbrister in-volverer, at brugeren narres til eller uforvarende handler på en måde, der fører til sår-barheder.

• Kommunikation mellem mobil enhed og Nets/DanID.

13


Sikkerhedsanalysen er gennemført ved en gennemgang af en række angrebstyper og sårbarhe-der. For hver angrebstype/sårbarhed er der gennemført en risikovurdering i forhold til sandsyn-lighed, konsekvens og mulighed for risikominimering (mitigering). Da gevinsterne for hackere ved at bryde sikkerheden er store, kombineret med at risikoen for pågribelse og straf er lille, er erfaringerne, at hackere i stigende grad forsøger at udnytte eksiste-rende såvel som ny-introducerede sårbarheder. Erfaringerne viser ydermere, at kendte og identi-ficerede sikkerhedsbrud er blevet gennemført ved at kombinere flere sårbarheder. Sandsynlighed for brud af sikkerheden er angivet med høj, mellem og lav. Høj angiver, at der forventes mere end 10 brud på sikkerheden i løbet af det kommende år i Danmark. Mellem, at der forventes 1-2 brud på sikkerheden i løbet af det kommende år. Lav, at der forventes 1-2 brud i de kommende tre år. Vurderingen er gennemført på grundlag af de hidtidige erfaringer med brud på sikkerheden i forbindelse med digital signatur og NemID, sat i forhold til de sårbar-heder og mitigeringsmuligheder, der er analyseret. Vurderingen er gennemført som et samlet skøn over sandsynlighed, idet sårbarheder som nævnt kombineres af hackerne. Da vurderingen sker i forhold til offentlige løsninger, hvor brud på sikkerheden kan medføre adgang til data og identitetstyveri, vurderes 10 eller flere brud på sikkerheden som et højt tal. Konsekvens er angivet med stor, mellem og lille. Stor angiver, at brud på sikkerheden medfører, at en hacker får fuld adgang til en borgers data. Mellem angiver, at en hacker får delvis adgang til en borgers data, f.eks. til at se udvalgte dele. Lille konsekvens angiver, at bruddet ikke i sig selv giver adgang til en borgers data. Det kan dog ske i kombination med andre sikkerhedsbrud. Den samlede vurdering af risikoen er produktet af sandsynlighed og konsekvens og er angivet med ”sikker”, ”betinget sikker” og ”ikke tilstrækkeligt sikker”. Der er ingen af løsningsvarianter-ne, der har opnået vurderingen ”sikker”.

8.3.1 Om sikkerhedsbrud og -tiltag Det vurderes, at de væsentligste sårbarheder for angreb for NemID-løsningen på mobile enheder vil være hos brugeren og i selve den mobile enhed. Det er vurderingen, at sårbarheder hos brugeren (valg af sikre koder, sikker brugeradfærd) ikke adskiller sig væsentligt fra PC’en. I vinteren 2011-2012 har phishing mod NemID-bankløsninger været det mest omtalte i medierne, og phishing kan også forventes i forbindelse med mobile en-heder. For at modvirke phishing skal brugeren kunne se på skærmen, hvad han gør, og om han tilgår en legitim tjeneste, ved f.eks. at URL vises. Sårbarheder på den mobile enhed kan findes i alle led, og mulighederne for at styrke modstands-dygtigheden er forskellig for de tre operativsystemer. Sikkerhed er desuden et spil mellem for-svar og angreb, så der vil være en løbende udvikling i sårbarheder, deres størrelse og mulighe-derne for at modvirke dem. Denne udvikling sker som resultat af angribernes udvikling af meto-der og værktøjer til at angribe. Hvis operativsystemet hackes, kan hackeren overtage mobiltelefonen og dermed brugerens log-in. Det samme gælder, hvis de indbyggede browsere hackes. Brugerne kan selv installere andre browsere, og de åbner for en sårbarhed, idet en hacker kan lokke en bruger til at installere en ondsindet eller fejlbehæftet browser eller tilhørende plug-in. Brugeren downloader tilsyneladende legitime apps (f.eks. et gratis spil) som indeholder malware-kode. En løsning med JavaScript, hvor kildekode downloades i klar tekst til den mobile enhed, indebæ-rer en risiko for, at en hacker kan manipulere koden og dermed overtage kontrollen med mobilte-lefonen og kompromittere sikkerheden ved at manipulere med den funktionalitet, som Java-Script-koden oprindelig skulle varetage. En række sårbarheder er knyttet til apps, som det beskrives i det følgende.

14


En app distribueres fra en markedsplads, så sikkerheden afhænger delvist af sikkerheden på markedspladsen og de kontroller, der er ved godkendelsen af en app og den løbende kontrol. Her har Apple og Microsoft den største sikkerhed, mens Android ikke har samme kontrolmeka-nismer på sin markedsplads. Det er desuden muligt for brugere at hente apps fra andre kilder.

8.3.2 Teknisk oversigt over sårbarheder Der arbejdes med følgende sårbarheder i analysen: Jailbreaking/rooting Alle operativsystemer kan knækkes, så brugeren kan tiltvinge sig rettigheder, som operativsy-stemudvikleren ikke ønskede. For mobile operativsystemer giver jailbreaking typisk mulighed for at skifte til en vilkårlig SIM-kortleverandør, at afvikle applikationer med udvidede rettigheder og at installere software, der ikke er certificeret af operativsystemudbyderen. En kombination af en jailbreaket mobiltelefon og en ondsindet applikation, der nu kan køre med udvidede rettigheder, giver en meget alvorlig sikkerhedsbrist (se mere under afsnittet ”Generelle angreb og forsvar”). Phishing Hvis en modstander kan snyde slutbrugeren til at tro, at denne benytter en autoriseret NemID-tjeneste, f.eks. ved at præsentere en webside, en applet eller en native app, der ligner, kan et phishing-angreb initieres. Da NemID anvender one-time-passwords (OTP), hvor brugeren modtager et spørgsmål fra Ne-mID (challenge) og svarer med den tilhørende kode fra OTP-kortet (response), kræver denne form for angreb, at modstanderen er aktiv, imens brugeren prøver at logge på. Modstanderen kan i baggrunden overføre de oplysninger, brugeren indtaster til den rigtige NemID-server, og dermed formidle OTP challenge-response for derpå at misbruge brugerens oplysninger. Man-in-the-browser De autoriserede browsere understøtter aktuelt ikke plug-ins, men det gør flere 3. parts browsere, f.eks. Splodge Browser til Android. Et plug-in kan være en camoufleret trojansk hest, hvis formål er at stjæle brugerens oplysninger, f.eks. via en keylogger. En plug-in vil også kunne ændre de oplysninger, brugeren ser i browseren og derved gennemføre en fiktiv transaktion. Man-in-the-device I et scenarium, hvor det underliggende operativsystem er hacket, kan en modstander modificere netværkskode og andre kritiske funktioner for på den måde at skaffe sig oplysninger om slutbru-geren. Selvom det ikke kan udelukkes, at en mobiltelefon kan hackes via malware downloadet som app eller via drive-by-surfing, vil et man-in-the-device-angreb som regel kræve, at mobilte-lefonen er jailbreaket. Man-in-the-data Hvis modstanderen har held til at aflytte kommunikationen mellem mobiltelefonen og NemID-serverne, kan et man-in-the-data-angreb initieres. Her kan modstanderen manipulere med data sendt begge veje for på den måde at tiltvinge sig adgang til private oplysninger. Manipulation af kode En NemID-komponent, der kører på klienten, er sårbar over for manipulation. Hvis en modstan-der har held med at manipulere koden og få brugeren til at afvikle den på sin enhed, kan person-lige oplysninger blive kompromitteret.

8.3.3 Sikkerhedskriterier Der arbejdes med følgende sikkerhedskriterier i analysen: Sikkerhedsniveau som PC Løsningen skal mindst have samme sikkerhedsniveau som PC-appletten, dvs. det må samlet set ikke være lettere at omgå sikkerheden i den mobile løsning. Derudover må et sikkerhedsbrud på den mobile løsning ikke kompromittere sikkerheden i PC-appletten.

15


NemID-autenticitet Løsningen skal sikre, at TU kan være sikker på autenticiteten af NemID-logikken. Privacy af signerede data Løsningen skal sikre, at brugeren har kontrol over det data, der sendes fra enheden, således at det ikke kan kompromitteres af en tredje part.

8.3.4 Mitigeringsstrategier En række tiltag kan være med til at vanskeliggøre eller forhindre de identificerede angrebsfor-mer. Detektere jailbreak Det er muligt til dels at detektere, om en given mobiltelefon har været udsat for et jailbreak. En NemID-certificeret applikation (se nedenfor), der kører på en sådan enhed, kan derfor medsende oplysningerne om problemet til NemID-serverne eller selv afbryde transaktionen. Desværre er der ikke nogen 100 % garanti for, at koden kan opdage et jailbreak. Digital signering af kode For så vidt at platformen understøtter digital signering med pålidelige rodcertifikater og kan vise slutbrugeren, at den hentede kode er underskrevet samt af hvem, giver denne mekanisme en vis sikkerhed for autenticiteten af NemID-logikken. Hemmeligt billede Brugeren kan out-of-band, f.eks. via en webbrowser på en PC, have logget på NemID og valgt et hemmeligt billede. Dette billede skal så fremover altid vises i mobil NemID, når brugeren logger på. Vises det ikke, bør brugeren ikke afgive akkreditiver. Hemmeligt spørgsmål En variant af det hemmelige billede, hvor brugeren skal svare på et selvvalgt spørgsmål for at komme videre. Denne model minder om den, der f.eks. anvendes af bankerne, når der foretages en internettransaktion. Her anvendes en SecureCode, som brugeren selv har valgt og selv skal besvare ved hver transaktion.

Visning af adressebjælke Slutbrugeren bør i et webscenarium altid kunne se browserens adressebjælke for at vurdere om det er det rigtige site, der kommunikeres med. En sådan vurdering kræver dog en viden om, præcis hvilken URL man skal se efter, og det er selvsagt muligt at lave URL’er, der ligner den rig-tige. Certificering af browsere Alle 3 operativsystemer understøtter 3. parts browsere, og man har således som bruger et valg ud over den browser, som følger med operativsystemet. Dette giver sikkerhedsmæssige udfor-dringer specielt på Android, hvor applikationer ikke verificeres, inden de publiceres til Market, men reelt også på de to andre operativsystemer, i tilfældet hvor ondsindet kodet, f.eks. en key-logger skjult i en app, slipper gennem et review. I et webscenarium kan man derfor vælge at be-grænse, hvilke browsere der må tilgå NemID. Dette hindrer dog ikke man-in-the-browser-angreb (se nedenfor), ligesom det er let for en browser at lade som om, den er en anden – certificeret – browser. Certificering af apps I native app-scenariet kan der indføres en certificeringsmekanisme for apps analogt til browser-certificeringen. En mulighed er at udstede et ”fingeraftryk” til en applikation, når den har passe-ret certificeringstesten. Som en del af log-in sendes dette fingeraftryk så til NemID-servere over en sikret linje, og kun applikationer med fingeraftrykket må efterfølgende udføre NemID-transaktioner. Denne strategi kan dog ikke stå alene, da slutbrugeren – ud over applikationens reelle hensigter – også har brug for at vide, at applikationen faktisk kommunikerer med den rig-tige NemID-server. Fingeraftryk giver ingen stærk sikkerhed, da en modstander med en vis ind-sats vil kunne trække dette ud af programmet og anvende det i sit eget. Certificering af TU Offentlige myndigheder, der anvender NemID, vil som udgangspunkt opfattes som mere trovær-dige end vilkårlige private udbydere af en slutbruger. En proces, hvor NemID certificerer de en-

16


kelte udbydere og kun accepterer signaturer fra de, der er certificerede, kunne derfor muliggøre, at private tjenesteudbydere kunne komme i spil.

Obfuskering En mekanisme, hvor kildekode eller binær kode manipuleres for at gøre den vanskeligere at læ-se. For kodekomponenter, der downloades dynamisk, vil obfuskering gøre reverse engineering og efterfølgende manipulation sværere. Obfuskering er dog på ingen måde nogen garanti, da der findes en række værktøjer til de-obfuskering. Krypteret forbindelse Ved at anvende en krypteret forbindelse (f.eks. via SSL) mellem enheden og NemID-infrastrukturen bliver det vanskeligere at stjæle data under transporten.

8.4 Native app Som angivet i afsnit 6 er der undersøgt tre løsningsvarianter med native apps:

• Statisk indlejret NemID-bibliotek (N1) • Separat NemID-app, hvor kommunikationen mellem TU og NemID apps sker lokalt på

den mobile enhed (N2) • Separat NemID app, hvor kommunikationen mellem de to apps sker via en ekstern ser-

ver (N3). DanID og bankerne introducerer en løsning baseret på native apps med statisk indlejret bibliotek i 2012.

8.4.1 Statisk indlejret NemID-bibliotek I varianten med ”statisk indlejret NemID bibliotek” udvikles et kodebibliotek, som app-udviklere skal indlejre i app-koden. App’en kan nu via et eksponeret API kommunikere med NemID-biblioteket, der igen varetager dialogen med slutbrugeren ift. autentifikation og signering, kryp-tografiske operationer samt den bagvedliggende dialog med NemID-serverinfrastrukturen. Modellen er illustreret på figuren nedenfor. Den røde ramme angiver den del af løsningen, inden for hvilken fuld tillid (trust) er påkrævet. I og med at biblioteket indlejres i en applikation, som kontrolleres af tjenesteudbyderen, er app’en dermed også indlemmet i sikkerhedsperimeteren.

Figur 5: Statisk indlejret NemID bibliotek

17


Løsningen er teknisk gennemførlig, og der anvendes kendte og afprøvede udviklingsteknikker og teknologier i løsningen. Denne løsning er valgt af DanID og bankerne til håndtering af NemID på mobile platforme. Løsningen understøtter ikke kommunikation med NemLog-in og brug af OIOSAML. Der skal fore-tages log-in i hver enkelt native app, og der vil ikke være single sign-on mellem apps. Sikkerhedsmæssigt er det væsentligste forhold, at NemID-biblioteket er kompileret ind i apps, der distribueres bredt. Det er derfor muligt for hackere at tilegne sig biblioteket og efterfølgende manipulere koden for derigennem at indlejre den i egne ondsindede apps. For de øvrige sårbar-heder er det muligt at opnå tilfredsstillende sikkerhed med mitigeringer. Angrebstyper • Jailbreaking/Rooting: Et jailbreak kan detekteres (dog ikke med 100 % garanti). • Phishing: Det er muligt at lave et bibliotek (eller bibliotek look-a-like), der opfører sig som

den officielle NemID-komponent. Alle de identificerede relevante mitigeringstiltag (for hemmeligt billede, hemmeligt spørgsmål etc., se afsnit 8.3.4) til at imødegå truslen er dog understøttet.

• Man-in-the-browser: Ikke relevant. • Man-in-the-device: Kan ikke generelt opdages. • Man-in-the-data: Begrænses i stort omfang af den krypterede forbindelse. • Manipulation af kode: Kode, der kompileres med ind i en anden binær fil, er reelt sårbar

over for manipulation, uanset hvilke tiltag der tages til beskyttelse. Det kan gøres sværere at manipulere koden med obfuskering, men ikke umuligt.

Sikkerhedskriterier • Sikkerhedsniveau som på PC: Koden er ikke beskyttet over for manipulation, og bruge-

ren har ingen mulighed for at verificere, at det er den officielle NemID-komponent, der an-vendes. Sikkerhedsniveauet er derfor lavere end for PC-versionen.

• NemID Autenticitet: Se Sikkerhedsniveau som på PC • Privacy af signerede data: NemID-biblioteket kan beskytte data lokalt på mobiltelefonen,

inden det sendes videre.

Risikoanalyse Det er vurderingen, at sandsynligheden for, at et angreb omgår de anbefalede mitigeringer, er på mellem-niveau (1-2 angreb i det kommende år), og at konsekvensen uden yderligere tiltag for ri-sikominimering vil være mellem, dvs. at der vil være en risiko for at kompromittere en borgers data.

Sandsynlighed Konsekvens Mitigering Samlet risiko-vurdering

Statisk indlej-ret NemID bib-liotek

Mellem Mellem Øgede krav til tjenesteudbydere

Betinget sikker

Konklusionen er, at løsningen er teknisk mulig på alle 3 platforme, men den udfordres sikker-hedsmæssigt af, at NemID-koden bliver gjort tilgængelig for klienten. Anvendelse af denne løs-ningsvariant kræver derfor yderligere tiltag for at minimere risici. Det kan f.eks. være ved at stil-le krav til tjenesteudbyderne om beredskab til opdatering af deres apps med ny NemID-kode og blokering af brugere med gamle versioner af apps. Løsningen indgår på den baggrund i den videre analyse.

18


8.4.2 NemID app lokal

I varianten med ”NemID app lokal” udbydes NemID-logikken i en separat applikation, som instal-leres på brugerens mobiltelefon. Via et helt tyndt bibliotek kommunikerer tjenesteudbyderens app med NemID-app’en, der igen varetager dialogen med slutbrugeren ift. autentifikation og sig-nering, kryptografiske operationer samt den bagvedliggende dialog med NemID-Server-infrastrukturen. Figuren nedenfor illustrerer løsningen, hvor den røde perimeter angiver det område, der kræver fuld tillid (trust). I løsningen er det primært det tynde bibliotek, der er sårbart, idet al NemID-logikken er indkapslet i en separat app.

Figur 6: NemID app lokal

Det tynde bibliotek vil primært fungere som bekvemmeligheds-proxy og ikke selv rumme nogen logik. Løsningen er teknisk gennemførlig på iOS og Android, og der anvendes kendte og afprøvede tek-nikker i løsningen. Den er dog ikke mulig på den nuværende version af Windows Phone 7, men forventes at kunne afvikles på Windows Phone 8. Løsningen understøtter ikke kommunikation med NemLog-in og brug af OIOSAML. Der skal fore-tages log-in i hver enkelt native app, og der vil ikke være single sign-on mellem apps. Sikkerhedsmæssigt er det væsentligste forhold, at det er muligt at lave reverse engineering på NemID-applikationen og lave en falsk version, men da den er installeret som et selvstændigt program via markedspladsen, og brugeren derved har samme muligheder som på PC-versionen for at verificere identiteten, betragtes denne trussel ikke som værre end på PC’en. Verifikationen kan opnås ved, at brugeren vil kunne tjekke certifikatet, som er blevet brugt til at signere Nem-ID-app’en ved udgivelsen for derigennem at verificere, at det er en betroet og den korrekte udgi-ver af app’en. Dette tjek svarer til, at brugeren har muligheden for at tjekke applet-signaturen fra DanID, som er blevet brugt til at signere Java-appletten. Desuden ligger usikkerheden i sikker kommunikation mellem apps, som i sig selv kræver speci-fikke håndteringer på hvert operativsystem. For de øvrige sårbarheder er det muligt at opnå tilfredsstillende sikkerhed med mitigeringer.

19


Angrebstyper • Jailbreaking/Rooting: Et jailbreak kan detekteres (dog ikke med 100 % ga-

ranti).

• Phishing: Det er muligt at lave en app, der opfører sig som den officielle NemID- applikation. Alle de identificerede tiltag (hemmeligt billede, hemme-ligt spørgsmål etc.) til at imødegå truslen er dog understøttet.

1) iOS URL: På iOS vil interapp-kommunikation kræve anvendelsen af en

URL-mekanisme, der ikke er beskyttet. Har en anden app allerede regi-streret sig som værende interesseret i de URL’er, som NemID anvender, vil denne app kunne overtage rollen som NemID.

2) Android Activity: På Android kan en Activity (del af en applikation) startes fra et andet program, hvis det er ønskeligt. Hver Activity har et unikt navn (pakkenavn + klassenavn), og det er ikke muligt at publicere en app på Android Market, der har et pakkenavn, som er identisk med en al-lerede publiceret applikation. Her kan man derfor som udgangspunkt regne med, at det er NemID-applikationen, der svarer via interapp-kald.

3) Windows Phone ikke understøttet: På Windows Phone er interapp-kald

ikke understøttet (eksisterer kun mellem 3. part apps og native system-apps, men ikke mellem 3. part og 3. part).

• Man-in-the-browser: Ikke relevant.

• Man-in-the-device: Ækvivalent til ”Statisk indlejret NemID-bibliotek”.

• Man-in-the-data: Ækvivalent til ”Statisk indlejret NemID-bibliotek”.

• Manipulation af kode: Det er muligt at lave reverse engineering på NemID-

applikationen og lave en falsk version, men da den er installeret som et selv-stændigt program via markedspladsen, og brugeren derved har samme mu-ligheder som på PC-versionen for at verificere identiteten, betragtes denne trussel ikke som værre end på PC’en.

Sikkerhedskriterier • Sikkerhedsniveau som på PC: Sikkerhedsniveauet regnes for at være som

på PC-versionen, idet koden svært kan manipuleres, og det er muligt at veri-ficere, at man har fat i NemID-applikationen.

• NemID Autenticitet: Se ovenfor.

• Privacy af signerede data: Den lokale NemID-app kan beskytte data lokalt på mobiltelefonen, inden de sendes videre. Det lille NemID-bibliotek, der kommunikerer med den lokale NemID-app, har mulighed for at lave digests (beregning af digests betyder, at man genererer en unik ”kode” ud fra det da-ta, som f.eks. skal signeres, hvorefter denne ”kode” f.eks. kan verificere au-tenticiteten af det oprindelige data) af det data, der skal signeres, således at privacy ikke kompromitteres, ved at det fulde data sendes til NemID-app’en.

Risikoanalyse Det er vurderingen, at sandsynligheden for, at et angreb omgår de anbefalede mitigeringer, er på mellem-niveau (1-2 angreb i det kommende år), og at konsekvensen uden yderligere tiltag for ri-sikominimering vil være mellem, dvs. at der vil være en risiko for at kompromittere en borgers data.

20



NemID app lokal

Mellem Mellem Certificering af selve NemID-app’en i kombi-nation med en aktive en-rollment af den enhed, den installeres på. Etablering af sikker kommunikation, f.eks. på iOS i samarbejde med Apple

Betinget sikker

Konklusionen er, at løsningen er teknisk mulig på iOS og Android og ikke på Windows Phone 7. Det er muligt for hackere at lave en ondsindet app, men en avanceret bruger vil som på PC’en kunne afsløre dette. Anvendelse af denne løsningsvariant kræver derfor yderligere tiltag for at minimere risici. Løsningen indgår på den baggrund i den videre analyse.

8.4.3 Interapp ekstern En variant af løsningen med en NemID-app udnytter en ekstern server til at kommunikere mel-lem to apps på samme enhed. På klienten installeres et tyndt bibliotek til at kommunikere med NemID-infrastrukturen. Løsningen kan teknisk implementeres, men de underliggende teknologier (f.eks. iOS push) giver i nogle tilfælde ikke garanti for leverance, og brugeroplevelsen forventes at være generelt dårlig. Samtidig er hastigheden på digital signering udfordret. Da løsningen således ikke kan leve op til tekniske krav om hastighed, indgår den ikke i den vide-re analyse.

8.5 Browserbaserede løsninger (web app) Der er som angivet i afsnit 6 undersøgt fire varianter med browsere. Fælles for dette løsningsde-sign er, at koden til at håndtere log-in med NemID overføres ved hvert log-in fra en server til den mobile enheds browser: W1: Oracle Java Applet W2: Adobe Flash W3: JavaScript W4: Web proxy.

8.5.1 Oracle Java Applet Java Applets er små mobile binære komponenter, der refereres gennem HTML-sider, downloades af klienten og udføres på klienten i browseren. Java Applets er skrevet i Java og afvikles af en virtuel maskine (VM), der kræves installeret på klientsystemet. Denne løsning er identisk med PC-versionen, hvor Java Appletten varetager dialogen med slut-brugeren, autentifikation og digital signering. Java Applets understøttes ikke af hverken iOS, Android eller Phone 7. Konklusionen er, at løsningen ikke er teknisk mulig, da den ikke understøttes på de relevante platforme. Løsningen indgår derfor ikke i den videre analyse.

8.5.2 Adobe Flash Adobe Flash er en multimedieplatform, der konceptuelt understøtter samme brugsmønstre som Oracle’s Java Applets og giver mulighed for at udføre kodekomponenter i browsere. Flash pro-grammer skrives i ActionScript, et sprog der minder en del om JavaScript. Flash-løsningen er analog til PC-versionen, hvor Java Appletten kan erstattes af en Flash-komponent, der udfører samme logik.

21


Flash er i dag tilgængelig til Android og integrerer med den mobile browser i systemet. Flash er ikke tilgængeligt på iOS og vil formodentlig heller ikke blive det, omend Adobes AIR, der benytter samme teknologi som Flash til at levere stand-alone-applikationer, er tilgængelig på iOS. I oktober 2012 meddelte Adobe, at man vil understøtte Flash på andre mobile platforme- herun-der Phone 7, men i november løb rygtet, at dette alligevel ikke var tilfældet, og at Adobe helt ville droppe Flash til nye operativsystemversioner efter pres fra Apple. Det er derfor temmelig usikkert i skrivende stund, hvilken fremtid Flash har på mobile platforme. Konklusionen er, at analysen sandsynliggør, at en NemID-komponent vil kunne udvikles i Flash. Desværre er Flash udelukkende tilgængelig på Android i dag, og det er uklart, om teknologien kommer til Phone 7. Det er dog næppe tænkeligt, at den dukker op på iOS. Teknologien kan alt-så fungere, men kun på én af de tre platforme. Konklusionen er, at løsningen ikke er teknisk mulig, da den ikke understøttes på de relevante platforme. Løsningen indgår derfor ikke i den videre analyse.

8.5.3 JavaScript JavaScript er et Java-lignende dynamisk programmeringssprog, der afvikles direkte af klientens browser, som selv står for at tolke og ofte også kompilere koden. I modsætning til f.eks. Flash el-ler Java er JavaScript-koden derfor direkte tilgængelig for brugeren. I en løsning baseret på JavaScript vil kryptografiske operationer og brugerdialog skulle afvikles i browseren med denne teknologi. Løsningen er illustreret på figuren nedenfor, hvor den del, der kræver fuld tillid (trust), er marke-ret med rødt. I modsætning til Flash-løsningen hentes JavaScript i klartekst, og manipulation af koden er derfor langt mere oplagt. Af denne grund udvides sikkerhedsperimeteren til at omfatte browseren, der nu er mål for f.eks. x-site-scripting (XSS) angreb. Der skelnes normalt mellem server-side (manipulation af et HTML-svar, hvor HTML-koden ændres, inden det sendes tilbage til brugerens browser) og client-side XSS-angreb (hvor man udnytter DOM-baserede sårbarheder i selve browseren til at ændre, indsætte og afvikle ondsindet JavaScript). I det aktuelle eksempel refereres der til client-side XSS-angreb.

22


Figur 7: JavaScript

Det er teknisk muligt at implementere NemID-biblioteket i JavaScript, og der findes eksempler på relevante implementeringer af krypterings-API’er, der kan anvendes som basis. JavaScript lider dog af performancemæssige udfordringer, og det er uklart, om en løsning vil kunne bringes til at køre med høj nok hastighed, dvs. en hastighed, som er sammenlignelig med den eksisterende løsning på PC ’en, eller hvad man kunne forvente, at brugeren ville være i stand til at acceptere på en mobil enhed. Løsningen kan understøtte kommunikation med NemLog-in og brug af OIOSAML. Der vil være single sign-on mellem offentlige tjenester. Sikkerhedsmæssigt er det væsentligste forhold, at i JavaScript kan en ondsindet tjenesteudbyder vælge at indlejre NemID JavaScript-koden i samme frame som egen kode og derved kompromit-tere den. Det hænger også sammen med, at en JavaScript-løsning ikke kan digitalt signeres eller beskyttes særligt godt mod manipulation. Sealing-teknikker kan mitigere risikoen for manipulati-on – men vil selvfølgelig fordyre løsningen. Denne form for mitigering er ikke 100% sikker, da de organisationer, som tjekker og certificerer et site/part eller deres certifikationssoftware ikke med sikkerhed kan fange alle aspekter. En hacker vil ydermere, afhængig af hvordan seal'et vises på en side, kunne snyde med visningen af et seal. Javascript-løsningen har derfor markant lavere sikkerhedsniveau end PC-versionen.

Angrebstyper • Jailbreaking/Rooting: JavaScript har ikke adgang til filsystemet og vil hel-

ler ikke kunne få det. Det er derfor ikke muligt at detektere et jailbreak.

• Phishing: Det er let at lave JavaScript, der imiterer den officielle NemID-kode, og som sender brugeren omkring en modstanders server. Alle de iden-tificerede tiltag (hemmeligt billede, hemmeligt spørgsmål etc.) til at imødegå truslen er dog understøttet af JavaScript.

• Man-in-the-browser: Kan kun til dels imødegås ved at standse download fra browsere, der ikke er certificerede. Dette er dog en svag sikring.

• Man-in-the-device: Kan ikke generelt opdages.

23


• Man-in-the-data: Begrænses i høj grad af den krypterede forbindelse.

• Manipulation af kode: Koden kan obfuskeres, hvilket gør det sværere (men

ikke umuligt) at lave reverse engineering. Koden kan ikke digitalt signeres. Sikkerhedskriterier • Sikkerhedsniveau som på PC: En JavaScript-løsning kan ikke digitalt sig-

neres eller beskyttes særligt godt mod manipulation. Den har derfor markant lavere sikkerhedsniveau end PC-versionen.

• NemID Autenticitet: Da JavaScript-koden er åben for angreb, er det umu-ligt for slutbrugeren generelt at afgøre, om det er NemID ”godkendt” soft-ware, der anvendes til autentifikationsprocessen.

• Privacy af signerede data: JavaScript-koden kan beskytte data lokalt på mobiltelefonen, inden de sendes videre. Det er dog noget lettere at manipule-re med JavaScript-kode, end det er med f.eks. Flash (via f.eks. script injekti-on), og løsningen er derfor som udgangspunkt mere sårbar.

Risikoanalyse Det er vurderingen, at sandsynligheden for, at et angreb omgår de anbefalede mitigeringer, er på højt niveau (10 angreb i det kommende år) på grund af den lette tilgængelighed af JavaScript og de begrænsede mitigeringsmuligheder. Konsekvensen vil være stor, dvs. der vil være en risiko for at kompromittere en borgers data.


JavaScript Høj Stor Udvikling af browserspeci-fikke plug-ins til JavaScript kode-verifikation. Der ek-sisterer dog stadig ingen sikre mitigeringer for DOM-delingsproblemer og XSS.

Ikke tilstrækkelig sikker

En ren JavaScript-løsning er mulig at realisere teknisk set, men lider af alvorlige sikkerhedsmæs-sige problemer. Af denne årsag udgår JavaScript af analysen som selvstændig løsningsmodel. Løsningen indgår derfor ikke i den videre analyse.

8.5.4 Web proxy En mulig løsning anvender alene HTML til at udføre den nødvendige signerings- og valideringslo-gik samt dialog med brugeren. I modellen udstilles logikken via en særlig webside (proxy), som kommunikerer med den eksisterende NemID-infrastruktur, og som kan implementeres og udby-des af DanID eller en anden leverandør. Brugeren bliver sendt forbi denne proxy-server af tjene-steudbyderen, når der er behov for autentifikation eller digital signatur. Websiden brandes med f.eks. NemID-logoet og har en passende URL, der gør det nemt for slutbrugeren at se, at bruge-ren er på den rigtige side. De faktiske kryptografiske operationer foretages via server-server-kommunikation mellem proxy-serveren og DanID. Modellen er illustreret på figuren nedenfor, hvor den del af løsningen, som kræver fuld tillid, er markeret med rødt. I modellen varetages NemID-logikken af proxy-serveren i samspil med brow-seren på brugerens mobile enhed.

24


Figur 8: Web proxy

Det er teknisk muligt at implementere web proxy-løsningen. Løsningen kan understøtte kommunikation med NemLog-in og brug af OIOSAML. Der vil være single sign-on mellem offentlige tjenester samt mulighed for at genbruge brugeradministration, signering og fuldmagt/delegering. Sikkerhedsmæssigt er det væsentligste forhold, at webproxy'en bryder med det grundlæggende princip i NemID PC-løsningen, som er designet til at etablere en ubrudt forbindelse mellem bru-gerens PC og DanID for at sikre enekontrol for brugeren (sole control) over brugerens private nøgle. Herudover er der i denne løsning en øget risiko for phishing og lignende typer angreb, da proxy-serveren er skudt ind mellem brugeren og den eksisterende NemID-infrastruktur. Dette vil også være gældende, hvis DanID selv implementerede og havde ansvar for proxy-serveren. En ondsindet part ville kunne ”lægge sig foran” web proxy’ens hjemmeside og præsentere en tilsva-rende hjemmeside, der ligner den rigtige hjemmeside på web proxy’en. Herefter kan den ondsin-dede part overvåge, og potentielt manipulere, alle interaktioner mellem brugeren og den rigtige hjemmeside, som derved i større udstrækning end i pc-løsningen åbner muligheden for et real-time phishing-angreb. NemID statisk bibliotek og app lokal Web proxy

Figur 9: Krypteret tunnel – ubrudt og i proxy-løsningen

Figuren viser, at den krypterede tunnel (transportlaget) brydes i proxy-løsningen, mens data kan krypteres

end-to-end.

25


Angrebstyper • Jailbreaking/Rooting: HTML har ikke adgang til filsystemet. Det er derfor

ikke muligt at detektere et jailbreak.

• Phishing: Det er muligt at lave en webside, der imiterer den officielle Nem-ID-side, og som sender brugeren omkring en modstanders server. Alle de identificerede tiltag (hemmeligt billede, hemmeligt spørgsmål etc.) til at imø-degå truslen er dog understøttet.

• Man-in-the-browser: Kan kun til dels imødegås ved at standse download fra browsere, der ikke er certificerede. Dette er dog en svag sikring.

• Man-in-the-device: Kan ikke generelt opdages.

• Man-in-the-data: Begrænses i høj grad af den krypterede forbindelse.

• Manipulation af kode: Koden kan ikke manipuleres, med mindre hele NemID proxy-serveren hackes, hvilket betragtes som værende et urealistisk scenarium. NemID proxy-serveren skal dog sikres med alle mulige tiltag, da den vil være et værdifuldt mål.

Sikkerhedskriterier • Sikkerhedsniveau som på PC: Der er udtalte udfordringer med phishing-

angreb, men da den avancerede bruger kan verificere, at denne faktisk kom-munikerer med NemID proxy-serveren via serverens certifikat, og løsningen ellers har lignende sikkerhedsmæssige karakteristika som PC-appletten, vur-deres løsningen som værende sikker nok, men ikke lige så sikker om PC-appletten.

• NemID Autenticitet: Se Sikkerhedsniveau som på PC

• Privacy af signerede data: I proxymodellen er der ingen kryptografiske operationer på klienten, idet al behandling af data foretages på proxy-serveren. Forbindelsen mellem klientens browser og proxy-serveren vil være beskyttet med almindelig SSL, hvilket ikke er så stærkt som den dobbelte tunnel, der anvendes i PC-appletten. Over SSL-tunnelen flyttes brugerens ak-kreditiver og OTP challenge response samt enten data- der skal signeres- el-ler det relevante digest, beregnet lokalt med JavaScript. Løsningen vurderes at være mindre sikker end PC-appletten.

Risikoanalyse Det er vurderingen, at sandsynligheden for, at et angreb omgår de anbefalede mitigeringer, er på mellem-niveau (1-2 angreb i det kommende år). Phishing af en proxy-løsning vil være kendt stof for hackere, mens mulighederne for mitigering i en løsning med høj fokus på sikkerhed vil mind-ske risikoen på enkelte områder. Konsekvensen vil være stor, dvs. at der vil være en risiko for at kompromittere en borgers data.

26



Web proxy Mellem Stor De vigtigste mitigeringer er implementering af fuld end-to-end kryptering på dataniveau, f. eks. v.h.a. brugen af kryptografiske funktioner implementeret i JavaScript på klientsi-den. Dette kombineret med SSL tunneler mel-lem klient-proxy og pro-xy-DanID's servere, ville sikre uønsket adgang på udvalgte informationer mellem klient og DanID. I tillæg, brugen af sik-kerhedsgrafik eller spørgsmål, visning af URL. JavaScript-ændringerne/tilføjelserne vil kræve en revision af protokollen for klient-DanID-kommunikation.


Konklusionen er, at løsningen er teknisk mulig på alle tre operativsystemer, men den udfordres dels af, at web proxyen indskydes mellem DanID og klienten på den mobile enhed og af sårbar-heden i Javascript. Anvendelse af denne løsningsvariant kræver derfor yderligere tiltag for at mi-nimere risici. Ved afviklingen af JavaScript forekommer muligheden for XSS angreb som i W3, som kan give en hacker mulighed for at manipulere med JavaScript koden på klient siden. I W3 løsningen vil al NemID funktionalitet være implementeret i JavaScript, hvor det i W4 kun vil være udvalgte dele af funktionaliteten, der er implementeret i JavaScript. Derfor vil en eventuel kompromittering af afviklingen af JavaScript koden i W4 kun have begrænset konsekvens. Løsningen er attraktiv, da den genbruger NemLog-in infrastrukturen og understøtter single sign-on. Løsningen indgår på den baggrund i den videre analyse.

8.6 Hybrid app Der er som beskrevet i afsnit 6 undersøgt seks løsningsvarianter med hybride apps. Den hybride strategi henfører til løsningsdesign, hvor klienten er en native app, udviklet specifikt til et givent mobilt operativsystem, men hvor applikationen på forskellig vis enten wrapper indholdet fra tje-nesteudbyderen i en browser eller henter oplysninger fra servere i NemID-føderationen via ser-vicekald. I de fire løsninger baseret på dynamisk bibliotek er der analyseret varianter med bå-de”webproxy” og ”Javascript”. Hybridmodellerne kombinerer derfor flere mulige løsningsdesigns, herunder at kommunikation med NemID-serveren udelukkende sker via den native app, udelukkende via den indbyggede/en indlejret browser, eller via en lokal, men selvstændig NemID app. Der er undersøgt følgende løsningsvarianter:

• Hybrid - Indlejret statisk bibliotek intern browser (H1) • Hybrid – NemID app lokal intern browser (H2) • Hybrid - Dynamisk bibliotek intern browser (H3a) • Hybrid - Dynamisk bibliotek intern browser (webservice) (H3b) • Hybrid - Dynamisk bibliotek ekstern browser (H4a) • Hybrid - Dynamisk bibliotek ekstern browser (webservice) (H4b).

27


De hybride varianter ”nedarver” egenskaber fra native apps eller browserbaserede apps. Gen-nemgangen af dem vil afspejle dette.

8.6.1 Hybrid - Indlejret statisk bibliotek intern browser NemID-logikken kan udbydes som et kodebibliotek til de tre platforme, der kompileres med ind i klientapplikationen, som i dette tilfælde wrapper tjenesteudbydernes indhold via en indlejret browser. Klienten kan nu via et eksponeret API kommunikere med NemID-biblioteket, der igen varetager dialogen med slutbrugeren ift. autentifikation og signering, kryptografiske operationer samt den bagvedliggende dialog med NemID-infrastrukturen. Løsningen er vist på figuren nedenfor. Den røde ramme angiver den del af løsningen, inden for hvilken fuld tillid (trust) er påkrævet. I og med at biblioteket indlejres i en applikation, som kon-trolleres af tjenesteudbyderen, er app’en dermed også indlemmet i sikkerhedsperimeteren.

Figur 10: Hybrid med indlejret statisk bibliotek

Løsningen ligner teknisk set løsningsvarianten ”Statisk indlejret NemID-bibliotek” med den for-skel, at efter et succesfuldt login vises tjenesteudbyderens hjemmeside i en indlejret browser frem for at hente oplysninger fra servere i NemID-føderationen via servicekald. Løsningen er teknisk mulig og har samme sikkerhedsniveau som ”Statisk indlejret NemID-bibliotek”. Løsningen kan understøtte kommunikation med NemLog-in og brug af OIOSAML. Normalt vil den hybride løsning kun kalde én offentlig tjeneste, og der vil så ikke være single sign-on mellem of-fentlige tjenester. Det er dog muligt at tilvejebringe SSO-funktionalitet ved at udstille links til fle-re tjenester i wrapperen eller ved at give brugeren mulighed for selv at angive URL til andre tje-nester i den indlejrede browser. Løsningen indgår på den baggrund i den videre analyse.

8.6.2 Hybrid – NemID app lokal intern browser I stedet for at kompilere hele NemID-logikken ind i hver eneste hybrid applikation, kan denne udbydes i en separat applikation, som installeres ved siden af hybrid klientprogrammet på bruge-rens mobiltelefon. Via et helt tyndt bibliotek kommunikerer klientapplikationen nu med NemID-applikationen, der igen varetager dialogen med slutbrugeren ift. autentifikation og signering, kryptografiske operationer samt den bagvedliggende dialog med NemID-infrastrukturen. Figuren nedenfor illustrerer løsningen, hvor den røde perimeter angiver det område, der kræver fuld tillid (trust). I løsningen er det primært det tynde bibliotek, der er sårbart, idet al NemID-

28


logikken er eksternaliseret i en separat app. Det tynde bibliotek vil primært fungere som be-kvemmeligheds-proxy og ikke selv rumme nogen logik udover potentielt logik til at skabe signe-rede data.

Figur 11: Hybrid – NemID app lokal intern browser

Løsningen ligner teknisk set løsningsvarianten for ”NemID app lokal” med den eneste forskel, at efter et succesfuldt log-in, ved at benytte sig af den eksterne, men lokale NemID app, vises tje-nesteudbyderens hjemmeside i en indlejret browser frem for at hente oplysninger fra servere i NemID-føderationen via servicekald. Løsningen er teknisk mulig og har samme sikkerhedsniveau som NemID app lokal. Løsningen kan understøtte kommunikation med NemLog-in og brug af OIOSAML. Normalt vil den hybride løsning kun kalde én offentlig tjeneste, og der vil så ikke være single sign-on mellem of-fentlige tjenester. Løsningen indgår på den baggrund i den videre analyse.

8.6.3 Hybrid - Dynamisk bibliotek intern browser Denne løsningsvariant for NemID på mobile platforme bygger på, at hybrid-klienten henter be-skyttede websider via en indlejret browser. Forudsætningen i denne model er, at al kommunika-tion med serveren sker via den indlejrede browser. Løsningen kan implementeres enten ved at anvende JavaScipt-model eller Web proxy-model til at håndtere NemID-logikken (se afsnit 8.5.3 og 8.5.4) Løsningen er illustreret på figuren nedenfor, hvor den del, der kræver fuld tillid (trust), er marke-ret med rødt. For web proxy-løsningen er sikkerhedsperimeteren begrænset til proxy-serveren. JavaScript hentes dog i klartekst, og manipulation af koden er derfor langt mere oplagt. Af denne grund udvides sikkerhedsperimeteren for JavaScript til at omfatte browseren, som illustreret med den stiplede linje, idet denne nu er mål for f.eks. x-site-scripting-angreb.

29


Figur 12: Hybrid - Dynamisk bibliotek intern browser

Angrebstyper (ved JavaScript-model) • Jaibreaking/Rooting: JavaScript har ikke adgang til filsystemet og vil heller

ikke kunne få det. Det er derfor ikke muligt at detektere et jailbreak. • Implementeres denne funktionalitet derimod i selve wrapper’en, vil jailbreak

kunne detekteres (dog ikke med 100 % garanti). • Phishing, Man-in-the-browser, Man-in-the-device, Man-in-the-data,

Manipulation af kode: Alle førnævnte evalueringskriterier er ækvivalente til kriterierne i løsningsmodellen ”JavaScript”, som beskrevet for webmodellen. Phishing er dog yderligere problematisk, idet løsningen kører i en wrappet browser.

Sikkerhedskriterier (ved JavaScript model) • Sikkerhedsniveau som på PC: En JavaScript-løsning kan ikke digitalt sig-

neres eller beskyttes særligt godt mod manipulation. Den har derfor markant lavere sikkerhedsniveau end PC-versionen.

• NemID Autenticitet: Da JavaScript-koden er åben for angreb, er det umu-

ligt for slutbrugeren generelt at afgøre, om det er NemID ”godkendt” soft-ware, der anvendes til autentifikationsprocessen.

• Privacy af signerede data: JavaScript-koden kan beskytte data lokalt på

mobiltelefonen, inden det sendes videre. Det er dog noget lettere at manipu-lere med JavaScript-kode, end det er med f.eks. Flash (via f.eks. script injek-tion), og løsningen er derfor som udgangspunkt mere sårbar.

Angrebstyper (ved Web proxy model) • Jaibreaking/Rooting: JavaScript har ikke adgang til filsystemet og vil heller


kunne detekteres (dog ikke med 100 % garanti).

30


• Phishing, Man-in-the-browser, Man-in-the-device, Man-in-the-data:,

Manipulation af kode: Alle førnævnte evalueringskriterier er ækvivalente til kriterierne i løsningsmodellen Web proxy, som beskrevet for webmodellen.

Sikkerhedskriterier (ved Web proxy-model) • Sikkerhedsniveau som på PC: Da brugeren kan verificere, at denne faktisk

kommunikerer med NemID proxy-serveren via serverens certifikat, og løs-ningen ellers har samme sikkerhedsmæssige karakteristika som PC-appletten (måske endda bedre, idet koden aldrig er i hænderne på slutbrugeren), vur-deres løsningen som værende lige så sikker.

• NemID Autenticitet: Se Sikkerhedsniveau som på PC • Privacy af signerede data: I proxy-modellen er der ingen kryptografiske

operationer på klienten, idet al behandling af data foretages på proxy-serveren. Forbindelsen mellem klientens browser og proxy-serveren vil være beskyttet med almindelig SSL, hvilket ikke er så stærkt som den dobbelte tunnel, der anvendes i PC-appletten. Over SSL-tunnelen flyttes brugerens akkreditiver og OTP challenge response samt data- der skal signeres. Løsnin-gen vurderes at være mindre sikker (men ikke usikker) end PC-appletten.

Risikoanalyse Det er vurderingen, at sandsynligheden for, at et angreb omgår de anbefalede mitigeringer, er på højt niveau (10 angreb i det kommende år) for JavaScript-modellen på grund af den lette tilgæn-gelighed af JavaScript og de begrænsede mitigeringsmuligheder og på mellem-niveau for web proxy-modellen (1-2 angreb i det kommende år). Konsekvensen for begge modeller vil være stor, dvs. at der vil være en risiko for at kompromittere en borgers data.


Hybrid - dynamisk bibliotek intern browser

Høj (JavaScript) Høj (Web proxy)

Stor Se Javascript og Web proxy oven-for


JavaScript-variant af denne model indgår ikke i den videre analyse. Phishing er mere problematisk end i web proxy-løsningsvarianten, idet løsningen kører i en wrappet browser. Brugeren har ikke en reel mulighed for at stole på den indlejrede (wrappede) browser, da selve wrapper app’en kan monitorere eller manipulere med både de indtastede og vi-ste data, og brugeren har derfor ikke samme muligheder for at tjekke certifikater og URL’er for tjenesteudbyderen, som ved brug af en native browser. Det er derfor svært for brugen at stole på autenticiteten af tjenesteudbyderen. Derfor indgår denne variant ikke i den videre analyse.

8.6.4 Hybrid – Dynamisk bibliotek intern browser (webservice) En variant af hybrid model med intern browser benytter sig stadig af OIOSAML-modellen til at gennemføre autentifikationen, men skifter derpå til identitetsbaserede webservices til kommuni-kation med tjenesteudbyder backenden i stedet for at vise websider. For at foretage dette skridt kræves det, at det bootstrap token, der udstedes i forbindelse med brugerens log-on, veksles til et identity token via OIOIDWS. Bootstrap token skal derfor løftes ud af den interne browser, og derpå skal der foretages et kald til føderationens STS for at veksle dette til et token, som kan an-vendes til konkrete webservice-kald.

31


Figur 13: Hybrid - Dynamisk bibliotek intern browser (webservice)

Der er ikke i dag foretaget en profilering af, hvordan OIOSAML og OIOIDWS arbejder sammen, og der ligger derfor et specifikations- og standardiseringsarbejde samt en efterfølgende imple-mentering til grund, før denne løsning kan tages i brug. Det lokale NemID-bibliotek i tjenesteudbyderens app vil skulle håndtere et bootstrap token, og da biblioteket kompileres med ind i app’en, vil hele løsningens sikkerhedsmæssige egenskaber være sammenlignelige med ”Hybrid - Indlejret statisk bibliotek intern browser” med den yderlige-re tilføjelse, at perimeteren også omfatter det hentede JavaScript/proxy-serveren. Rene webservice-løsninger fordrer et større udviklingsarbejde, der først kræver en profilering af OIOIDWS og OIOSAML til at arbejde sammen. Dette arbejde vurderes at være så omfattende, at det ikke er realistisk at gå efter denne type løsning i første omgang, hvis tidsplanen for NemID på mobile enheder skal holde. Løsningen indgår derfor ikke i den videre analyse.

8.6.5 Hybrid – Dynamisk bibliotek ekstern browser Dette løsningsdesign for NemID på mobile platforme bygger på en model, hvor klienten henter beskyttede websider i en indlejret browser, men hvor kommunikationen med NemID foregår via den indbyggede (native) browser. Forudsætningen i denne model er, at al kommunikation med NemID-serveren sker via den indbyggede browser, og efter et succesfuldt log-in vises tjeneste-udbyderens hjemmeside i en indlejret browser i klienten.

32


Figur 14: Hybrid - Dynamisk bibliotek ekstern browser

Angrebstyper (ved JavaScript-model) • Jaibreaking/Rooting: JavaScript har ikke adgang til filsystemet og vil heller


kunne detekteres (dog ikke med 100 % garanti). • Phishing: Evalueringskriteriet er ækvivalent til kriteriet i løsningsmodellen

”JavaScript”, som beskrevet for webmodellen. For interapp-delen af denne model er kriteriet ækvivalent til kriteriet i løsningsmodellen ”Interapp”, som beskrevet for native app-modellen.

• Man-in-the-browser, Man-in-the-device, Man-in-the-data, Manipulati-

on af kode: Alle førnævnte evalueringskriterier er ækvivalente til kriterierne i løsningsmodellen ”JavaScript”, som beskrevet for webmodellen.

Sikkerhedskriterier (ved JavaScript-model)

• Sikkerhedsniveau som på PC: En JavaScript-løsning kan ikke digitalt signeres eller beskyttes særligt godt mod manipulation. Den har derfor markant lavere sikkerhedsniveau end PC-versionen.

• NemID Autenticitet: Da JavaScript-koden er åben for angreb, er det

umuligt for slutbrugeren generelt at afgøre, om det er NemID ”godkendt” software, der anvendes til autentifikationsprocessen.

• Privacy af signerede data: JavaScript-koden kan beskytte data lokalt

på mobiltelefonen, inden de sendes videre. Det er dog noget lettere at manipulere med JavaScript-kode, end det er med f.eks. Flash (via script injektion), og løsningen er derfor som udgangspunkt mere sårbar.

33


Angrebstyper (ved web proxy-model) • Jaibreaking/Rooting: JavaScript har ikke adgang til filsystemet og vil heller


kunne detekteres (dog ikke med 100 % garanti). • Phishing: Evalueringskriteriet er ækvivalent til kriteriet i løsningsmodellen

”JavaScript”, som beskrevet for webmodellen. For interapp-delen af denne model er kriteriet ækvivalent til kriteriet i varianten ”Interapp”, som beskre-vet for native app-modellen.

• Man-in-the-browser, Man-in-the-device, Man-in-the-data:, Manipula-

tion af kode: Alle førnævnte evalueringskriterier er ækvivalente til kriterier-ne i løsningsmodellen ”web proxy”, som beskrevet for webmodellen.

Sikkerhedskriterier (ved web proxy-model) • Sikkerhedsniveau som på PC: Da brugeren kan verificere, at denne faktisk

kommunikerer med NemID proxy-serveren via serverens certifikat, og løs-ningen ellers har samme sikkerhedsmæssige karakteristika som PC-appletten (måske endda bedre, idet koden aldrig er i hænderne på slutbrugeren), vur-deres løsningen som værende lige så sikker.

• NemID Autenticitet: Se Sikkerhedsniveau som på PC • Privacy af signerede data: I web proxy-modellen er der ingen kryptogra-

fiske operationer på klienten, idet al behandling af data foretages på proxy-serveren. Forbindelsen mellem klientens browser og proxy-serveren vil være beskyttet med almindelig SSL, hvilket ikke er så stærkt som den dobbelte tunnel, der anvendes i PC-appletten. Over SSL-tunnelen flyttes brugerens ak-kreditiver og OTP challenge response samt data, der skal signeres. Løsningen vurderes at være mindre sikker (men ikke usikker) end PC-appletten.

Risikoanalyse Det er vurderingen, at sandsynligheden for, at et angreb omgår de anbefalede mitigeringer, er på højt niveau (10 angreb i det kommende år) for JavaScript-modellen på grund af den lette tilgæn-gelighed af JavaScript og de begrænsede mitigeringsmuligheder og på mellem-niveau for web proxy-modellen (1-2 angreb i det kommende år). Konsekvensen for begge modeller vil være stor, dvs. at der vil være en risiko for at kompromittere en borgers data.


Hybrid - dynamisk bibliotek ekstern browser

Høj (JavaScript) Høj (web proxy)

Stor Se Javascript og web proxy ovenfor


JavaScript-variant af denne model indgår ikke i den videre analyse. Phishing er mere problematisk end i web proxy-løsningsvarianten, idet løsningen kører i en wrappet browser. Derfor indgår denne variant ikke i den videre analyse.

8.6.6 Hybrid - Dynamisk bibliotek ekstern browser (webservice) En variant over løsningen med ekstern browser benytter sig stadig af OIOSAML modellen til at gennemføre autentifikationen, men skifter derpå til identitetsbaserede webservices til kommuni-kation med TU backenden i stedet for at vise websider. For at foretage dette skridt kræves det at det bootstrap token, der udstedes i forbindelse med brugerens logon, veksles til et identity token via OIOIDWS. Bootstrap token skal derfor løftes ud af den eksterne browser og derpå skal der fo-retages et kald til føderationens STS for at veksle dette til et token, som kan anvendes til konkre-te web service kald.

34


Figur 15: Hybrid - Dynamisk bibliotek ekstern browser (webservice)

Løsningens egenskaber er som ”Hybrid – Dynamisk bibliotek intern browser (webservice)”, bort-set fra at det udstedte bootstrap token gemmes lokalt af tjenesteudbyderens app, hvorfor der kræves yderligere tillid (trust) til denne, og at phishing-angreb lettere kan mitigeres i denne løs-ningsvariant. Rene webservice-løsninger fordrer et større udviklingsarbejde, der først kræver en profilering af OIOIDWS og OIOSAML til at arbejde sammen. Dette arbejde vurderes at være så omfattende, at det ikke er realistisk at gå efter denne type løsning i første omgang, hvis tidsplanen for NemID på mobile enheder skal holde.

8.7 Opsamling på teknisk og sikkerhedsmæssig vurdering Opsamlingen på den tekniske og sikkerhedsmæssige vurdering er, at ingen løsninger har et sik-kerhedsniveau, der gør, at de kan vurderes som værende på niveau med NemID på PC’er. Teknisk

vurdering Risikovurdering OIOSAML Single

sign-on

Native App – Indlejret statisk bibliotek (N1)

� Betinget sikker

Native App – NemID app lokal (N2)

� Betinget sikker

Native App – NemID app ekstern (N3)

Web – Java Applets (W1) Web – Flash (W2) Web – JavaScript (W3) � Ikke tilstrækkelig

sikker

Web – Proxy (W4) � Ikke tilstrækkelig sikker

� �

Hybrid – Indlejret statisk bib-liotek intern browser (H1)

� Betinget sikker � � *



Hybrid – Dynamisk bibliotek intern browser (H3a)

� Ikke tilstrækkelig sikker

� � *

Hybrid – Dynamisk bibliotek intern browser (webservice) (H3b)

Hybrid – Dynamisk bibliotek ekstern browser (H4a)

� Ikke tilstrækkelig sikker

� � *

Hybrid – Dynamisk bibliotek ekstern browser (webservice) (H4b)

35


Note: Der er kun anført risikovurdering og vurdering af OIOSAML og single sign-on for løsninger, der er tek-

nisk gennemførbare.

* Note: For de hybride løsninger afhænger single sign-on funktionalitet af, hvordan app'en implementeres.

Der er single sign-on i app-konteksten. Der er fem løsninger, hvor det er relevant at gennemføre en mere dybtgående analyse, herunder at afdække mulighederne for samlet set at skabe den nødvendige sikkerhed. Da fire af løsningerne kombinerer native app med en hybridløsning, er der tale om to løsningspar og en løsning:

• App med indlejret NemID-kode (N1) og hybridløsningen (H1) • NemID app (N2) og hybridløsningen (H2) • Web proxy-mitigering (W4).

I det følgende beskrives mitigeringsløsningerne samt de forhold, der gælder for distributionen af apps.

8.8 Mitigeringsløsninger Her uddybes de tiltag, der er beskrevet under de enkelte løsningsvarianter, som kan bidrage til at mindske risici for brud på sikkerheden og modvirke konsekvenserne heraf. Risikovurderingen er angivet med disse mitigeringer. Trods mitigeringerne er sikkerheden i løs-ningerne dog ikke på det ønskede niveau.

8.8.1 Statisk indlejret NemID-bibliotek (N1) og Hybrid - Indlejret statisk bibliotek intern browser (H1) For at mindske de sikkerhedsmæssige risici ved det indlejrede NemID-bibliotek, skal der stilles krav til tjenesteudbyderne og deres løbende opfølgning på sikkerhedsproblemer, f. eks. ved at forpligte sig til at opdatere apps og udfase versioner med sikkerhedsproblemer, dvs. at brugere af apps, der benytter gamle biblioteker, simpelthen ikke får lov til at logge på, krav til tidsrum for en ny opdatering af tjenesteudbyderes app ved frigivelse af nyt NemID-bibliotek.

8.8.2 NemID app lokal (N2) og Hybrid – NemID app lokal intern browser (H2) Certificering af selve NemID app’en i kombination med en aktiv enrollment af den enhed, som den installeres på. Etablering af sikker kommunikation, f.eks. på iOS i samarbejde med Apple.

8.8.3 Web proxy (W4) De vigtigste mitigeringer er implementering af fuld end-to-end kryptering på dataniveau, f.eks. v.h.a. brugen af kryptografiske funktioner implementeret i JavaScript på klientsiden. Dette kom-bineret med SSL tunneler mellem klient-proxy og proxy-DanID servere ville sikre imod uønsket adgang på udvalgte informationer mellem klient og DanID. Der vil yderligere kunne tilføjes brug af sikkerhedsgrafik eller spørgsmål og visning af URL. Selv med disse mitigeringsløsninger vil OCES-standardens krav om enekontrol (sole control), som er etableret gennem en sikret, ubrudt forbindelse mellem brugerens pc og DanID fortsat ikke være opfyldt. JavaScript-ændringerne/tilføjelserne vil kræve en revision af protokollen for klient-DanID-kommunikation."

8.9 Hvad skal en hybrid app give adgang til Såfremt der vælges en hybrid løsningsvariant, kan tjenesterne pakkes på flere måder, som kan have betydning for, i hvilket omfang der er single sign-on mellem løsninger. En app kan pakke et link til en tjeneste eller til en gruppe af tjenester. F.eks. kan en app pakke tjenester for forældre, for uddannelsessøgende osv. Der vil være single sign-on til den samlede pakke. Det betyder, at brugerforventningen om single sign-on i et vist omfang kan imødekom-mes ved at pakke tjenesterne i forhold til brugeradfærden. Såfremt der vælges en implementering, hvor brugeren selv kan vælge tjeneste, ved at brugeren selv kan indtaste URL’en i adressefeltet, vil der være fuld single sign-on.

8.10 Distribution og sikkerhedsniveau på app markets Tjenesteudbydere, der skal distribuere apps via app markets skal følge og eventuelt underskrive de betingelser, der gælder for markederne.

36


De tre operativsystemer har forskellige løsninger og spilleregler for dette. iOS Apple har organiseret distributionen i App Store, som Apple kontrollerer tæt. Tjenesteudbydere, der vil distribuere apps, skal underskrive betingelserne for App Store. Apples skarpe betingelser betyder også, at hver app skal gennemgå en kontrol, og der har været eksempler på, at samme app fik forskellig behandling i forskellige lande. Det betyder en risiko for, at løsninger med samme indlejrede kode kan blive bedømt forskelligt fra gang til gang. Den-ne risiko kan muligvis mindskes ved at indgå dialog med markedsejer. Mobile enheder, der anvender iOS, kan kun afvikle apps, der er downloaded fra App Store. Samlet set understøtter styringen af enheder og App Store et højt sikkerhedsniveau. Android Google har organiseret distributionen i Android Market. Tjenesteudbydere, der vil distribuere apps, skal følge betingelserne for Android Market. Android Market implementerer en begrænset brugerbaseret kontrol, hvor det er brugerne selv, der anmelder og kommenterer apps, og de kan også se, hvor mange andre brugere der har downloadet en app. Brugerne kan herefter rapportere ondsindede apps direkte til Google, hvis der er mistanke eller bevis herfor. Hvis nok brugere klager over en app, vil Google fjerne det fra markedspladsen, og de kan derefter også fjern-afinstallere app’en fra enheder, hvorpå de er ble-vet installeret. Mobile enheder, der anvender Android, kan som udgangspunkt kun afvikle apps, der er downloa-ded fra Android Market, men brugeren har mulighed for at godkende apps fra andre sites og fra en tilsendt mail. Samlet set gør det sikkerhedsniveauet for Android apps lavere sammenlignet med Apple App Sto-re. Windows Phone Microsoft håndterer sin markedsplads, Windows Phone Marketplace, meget lig Apple App Store, dvs. den er tilsvarende stramt styret. Microsoft skal godkende alle apps, før de kan distribueres via markedspladsen, og Microsoft håndhæver ligesom Apple dette på alle enheder via en certificeringsproces. En enhed vil og kan ikke køre en app, medmindre den er underskrevet med et Microsoft Authenticode certifikat. Som i tilfældet hos Apple vides det ikke, hvor meget Microsoft tester og gennemgår de apps, som er til godkendelse, men Microsoft tilbyder derimod et ”Marketplace Preparation Test Kit”, som au-tomatiserer dele af – og tilbyder manuelle test, som en del af – at teste, om en app overholder certificeringskravene. Samlet set forventes WP7 at understøtte styringen af enheder og Marketplace et højt sikkerheds-niveau, men løsningen er så ny, at det endnu ikke er testet i praksis.

8.11 Konklusion på den teknisk-sikkerhedsmæssige vurdering På grundlag af den teknisk-sikkerhedsmæssige analyse kan de fleste af de skitserede løsnings-modeller fravælges. De fem løsningsvarianter, der er relevante i den videre vurdering, kan på forskellig måde opnå højere sikkerhed gennem mitigeringstiltag, men kommer ikke op på det ønskede niveau. Det er også samlet set vurderingen, at de analyserede app-baserede løsninger vil kunne distribu-eres via de respektive markedspladser. De fem løsningsvarianter analyseres og vurderes i de efterfølgende afsnit.

37


Teknisk

vurdering Risikovurdering OIOSAML Single sign-on


� Betinget sikker


� Betinget sikker � *

Web - Proxy (W4) � Ikke tilstrækkelig sikker

� �




� Betinget sikker �

* Note: For de hybride løsninger afhænger single sign-on funktionalitet af, hvordan app'en implementeres.

Der er single sign-on i app-konteksten.

38


9. OMKOSTNINGER TIL DRIFT OG UDVIKLING

I de beskrevne løsninger indgår en række løsningskomponenter i forskellige kombinationer. Disse komponenter beskrives her, hvorefter løsningernes brug af komponenterne beskrives i de efter-følgende afsnit. De økonomiske skøn har en betydelig usikkerhed, og er baseret på skøn på basis af Rambølls ge-nerelle erfaringer.

9.1 Overblik over tekniske komponenter i løsningerne De tre løsninger er teknisk set forskellige og stiller forskellige krav til parterne i relation til udvik-ling af back-end komponenter og komponenter, der afvikles på de mobile enheder.

9.1.1 Statisk indlejret NemID bibliotek (N1) og Hybrid – Indlejret statisk bibliotek intern browser (H1) Disse løsninger kræver, at der til NemID-infrastrukturen udvikles back-end-komponenter, der håndterer kommunikation og funktionalitet til tjenesteudbydernes NemID-klienter på mobile en-heder. Disse komponenter vurderes til teknisk set at kunne basere sig på de infrastrukturelle elementer, der er udviklet i forbindelse med bankernes kommende løsning. Desuden skal Digitaliseringsstyrelsen sørge for, at der udvikles et statisk bibliotek til de under-støttede platforme, som skal distribueres til udviklerne og indlejres i tjenesteudbydernes apps (de grønne felter i figuren). Dette statiske bibliotek vil i stor udstrækning teknisk set kunne bestå af samme kode, som anvendes i bankernes kommende løsning. Tjenesteudbyderne skal udvikle apps til de understøttede platforme med den indlejrede kode (med en wrapper til indlejret browser for H1 modellen) – blå felter i figuren. For N1 modellen skal der desuden udvikles snitflader til indholdstjenester (f. eks. REST eller SOAP) og sikkerhed.

Figur 16: Komponenter i Statisk indlejret NemID bibliotek og hybrid

For offentlige tjenesteudbydere er en væsentlig fordel ved Hybrid - Indlejret statisk bibliotek intern browser (H1), at den tillader brug af den eksisterende NemLog-in-infrastruktur. Det be-tyder, at de offentlige tjenesteudbydere kan anvende den nuværende webserverinfrastruktur.

39


Hybridløsningen understøtter dog ikke single sign-on mellem tjenester (se dog afsnit 8.9, der be-skriver muligheder for at tilvejebringe SSO funktionalitet i denne model).

9.1.2 NemID app lokal (N2) og Hybrid – NemID app lokal intern browser (H2) Disse løsninger kræver, at der til NemID-infrastrukturen udvikles back-end-komponenter, der håndterer kommunikation og funktionalitet til NemID-applikationen på mobile enheder. Disse komponenter vurderes til teknisk set at kunne basere sig på de infrastrukturelle elementer, der er udviklet i forbindelse med bankernes kommende løsning. Digitaliseringsstyrelsen skal sørge for, at der udvikles en NemID-app (grønne felter) til de under-støttede platforme, der skal kunne håndtere dialog med NemID back-end, og som skal kunne kommunikere med tjenesteudbydernes apps. NemID-app vil i stor udstrækning bestå af samme kode, som anvendes i bankernes kommende løsning med statisk bibliotek. Digitaliseringsstyrelsen skal sørge for, at der udvikles et bibliotek til at kalde NemID app’en. Det-te bibliotek skal indlejres i tjenesteudbydernes apps. Tjenesteudbyderne skal udvikle apps, der kommunikerer med NemID app (med en wrapper til indlejret browser for H2 modellen) – de blå felter. For N2-modellen skal der desuden udvikles snitflader til indholdstjenester (f.eks. REST eller SOAP) og sikkerhed.

Figur 17: NemID app lokal og hybrid

For offentlige tjenesteudbydere er en væsentlig fordel ved Hybrid – NemID app lokal intern browser (H2), at den tillader brug af NemLog-in-infrastrukturen. Det betyder, at de offentlige tjenesteudbydere kan anvende den nuværende webserverinfrastruktur. Hybridløsningen under-støtter dog ikke single sign-on mellem tjenester (se dog afsnit 8.9).

9.1.3 Web proxy (W4) Her skal Digitaliseringsstyrelsen sørge for, at der implementeres en web proxy (sandsynligvis tæt på eksisterende NemID-infrastruktur) samt udvikles mitigering med JavaScript, der varetager kommunikation mellem den mobile enhed og proxy-serveren.

40


Det vil desuden være nødvendigt at ændre DanIDs infrastruktur, så sikker forbindelse via proxy til klienten understøttes bedst muligt. For web proxy-modellen skal tjenesteudbydere alene tilpasse deres eksisterende web-løsninger til mobile platforme.

Figur 18: Web proxy

For offentlige tjenesteudbydere er en væsentlig fordel ved web proxy-løsningen, at den tillader brug af NemLog-in-infrastrukturen. Det betyder, at de offentlige tjenesteudbydere kan anvende den nuværende webserver-infrastruktur. Tjenesteudbyderne skal ikke afholde udgifter til apps. Løsningen understøtter single sign-on mellem tjenester.

9.2 Omkostningskomponenter 9.2.1 Digitaliseringsstyrelsens omkostninger til Statisk indlejret NemID bibliotek og NemID app lokal

Disse komponenter består af de kodeelementer, der præsenterer en brugergrænseflade, der er ækvivalent til PC-versionen, varetager kommunikationen med DanID og tjenesteudbyderen, samt tilvejebringer visse kryptografiske operationer herunder dele af signeringsprocessen. Det forudsættes, at det er Digitaliseringsstyrelsen, der er ejer af koden/app’en. Mulige leverandører er DanID, som har udviklet tilsvarende kode til bankernes løsning. Kompo-nenten forventes teknisk set at kunne bygge videre på erfaringer og kodeelementer fra banker-nes løsning. Løsningen kan udvikles af andre leverandører, hvilket i så fald skal ske i tæt samar-bejde med DanID af hensyn til kommunikationen med DanIDs NemID back-end. Omkostningen til udvikling af koden til tre operativsystemer inkl. testforløb skønnes at være et tocifret millionbeløb. Der forventes samme omkostning til indlejret kode og til en selvstændig app. Det vil kræve en forhandling med DanID for at afklare, om den kode, der er udviklet for banker-ne, kan indgå i udviklingen og på hvilke betingelser.

41


De centrale omkostninger til drift vil omfatte:

• tilpasninger til nye sårbarheder • udvikling til nye operativsystemer og versioner heraf

Der kan forventes øget hacker-interesse i takt med, at der bliver flere mobile løsninger, ikke mindst på bankområdet. Det kræver en løbende overvågning og udvikling af mitigeringer og dermed løbende omkostninger. Da der forventes forandringer i markedet for mobile operativsystemer med mulige nye spillere og nye versioner, vil der samtidig være behov for udvikling af nye versioner. Det betyder, at de årlige drifts- og vedligeholdelsesomkostninger skønnes at ville udgøre 20-40 % af anskaffelsesudgiften. Den indlejrede kode skal distribueres til tjenesteudbydernes udviklere, som skal inkludere den i app koden. Tjenesteudbyderne vil have løbende udgifter til indlejring af nye versioner. Disse om-kostninger behandles nedenfor.

9.2.2 Digitaliseringsstyrelsens omkostninger til de hybride løsninger De to hybride løsninger er udbygninger af Statisk indlejret NemID bibliotek (N1) og NemID app lokal (N2) med komponenter til kald af tjenester i den interne browser. Der forudsættes at det er Digitaliseringsstyrelsen der er ejer af app’en. Mulige leverandører er DanID. Løsningen kan udvikles af andre leverandører, hvilket i så fald skal ske i tæt samarbejde med DanID. Omkostningen til udvikling af koden inkl. test er den samme som til det indlejrede bibliotek og app’en. Hertil skal lægges udgifter til at håndtere browserkald i den hybride variant. Den samlede omkostning skønnes af DanID til et tocifret millionbeløb, der er 20-30% højere end til det indlej-rede bibliotek. De centrale omkostninger til drift vil omfatte

• tilpasninger til nye sårbarheder • udvikling til nye operativsystemer og versioner heraf.

De årlige drifts- og vedligeholdelsesomkostninger skønnes at ville udgøre 20-40 % af anskaffel-sesudgiften.

9.2.3 Digitaliseringsstyrelsens omkostninger til DanIDs snitflade og back-end Dette omfatter DanIDs omkostninger til snitflade og backend til NemID indlejret kode og NemID app, sikkerhedstest, projektledelse, dokumentation og øvrige forretningsopgaver. Det er antagelsen, at den eksisterende protokol på back-enden kan genbruges her, hvilket be-grænser udgifterne. Disse opgaver kan alene løses af DanID. Den samlede omkostning skønnes af DanID til at koste et etcifret millionbeløb. Det vil kræve en forhandling med DanID for at afklare, om den infrastruktur, der er udviklet for bankerne, kan indgå i udviklingen og på hvilke betingelser.

9.2.4 Digitaliseringsstyrelsens omkostninger til web proxy En løsning med web proxy kræver:

• Etablering af en web proxy med høj sikkerhed. Den skal etableres i et sikret miljø, hvilket sandsynligvis taler for etablering hos DanID eller evt. hos NNIT dvs. i forbindelse med NemID eller evt. NemLog-in.

• JavaScript. Der skal udvikles kode til at sikre kommunikation til proxy-serveren.

42


De samlede omkostninger til selve proxyen og til forøgelse af sikkerheden med Javascript skøn-nes med test at koste et etcifret millionbeløb og 20-30 % heraf i årlig drift.

9.2.5 Digitaliseringsstyrelsen omkostninger til DanIDs snitflade og backend til web proxy Kravene til at øge sikkerheden i web proxy-løsningen kræver ændringer i DanIDs back end, her-under ændringer i OTP protokollen. DanID har ikke skønnet denne udgift, men på grundlag af ovenstående skøn vurderes omkost-ningen at være et tocifret millionbeløb.

9.2.6 Tjenesteudbydernes omkostninger til native app I de løsninger, hvor tjenesteudbyderne skal basere sig på native apps (N1 og N2), skal tjeneste-udbyderen udvikle og distribuere en app, hvor der indlejres NemID-kode. Opgaven er af samme størrelse for indlejret kode og selvstændig NemID app, hvor der også skal indlejres kode. Omkostningerne til udvikling af apps afhænger af funktionalitet, men den første app vil koste 200.000-300.000 kr. Tilpasning til de to øvrige operativsystemer vil koste 50 % heraf, i alt 300.000-500.000 kr. Der er her taget udgangspunkt i en minimumsløsning – ønsker tjenesteud-byderen en meget rig app, vil omkostningen være større. I en ren app-løsning skal tjenesteudbyderne desuden udvikle snitflader til kommunikation mellem app og back-endens database- og applikationsservere, dels til indhold (100.000-200.000 kr.) og dels til sikkerhed (200.000-300.000 kr.). De samlede omkostninger for en tjenesteudbyder til etablering af en app-baseret løsning skønnes derfor at være på 600.000-1.000.000 kr. Der er eksempler på at en sådan løsning har kostet flere millioner kroner.

9.2.7 Tjenesteudbydernes omkostninger til hybride app I de løsninger, hvor tjenesteudbyderne skal indbygge et bibliotek i en hybrid app, hvor der ikke kræves nye snitflader til back-end, vil apps med bibliotek og browserkald kunne løses af tjene-steudbyderne til 100.000-200.000 kr.

9.2.8 Tjenesteudbydernes omkostninger til browserbaserede løsninger (web app) Tjenesteudbyderne vil ikke have omkostninger til tilpasning til NemID-løsningen, såfremt de an-vender browserbaseree løsninger (web apps). Tjenesteudbyderne vil have omkostninger til at tilpasse brugergrænseflader til de mobile enhe-der. Omfanget af disse omkostninger afhænger af vurderingen af borgernes behov og hvordan der opnås størst mulig brug af selvbetjeningsløsningerne samt af de teknologier, der anvendes til selvbetjeningsløsningerne. Denne type omkostninger indgår ikke i omkostningsberegningerne, da tjenesteudbyderne i princippet kan tilbyde de nuværende løsninger på mobile enheder.

9.2.9 Tjenesteudbydernes samlede omkostninger Tjenesteudbydernes samlede omkostninger afhænger dels af den enkelte tjenesteyders omkost-ninger, dels antallet af tjenesteudbydere, der vil anvende løsningen. Antallet af tjenester – selvbetjeningsløsninger - på mobile enheder, afhænger af flere forhold. Er selvbetjeningsløsningens indhold og brugergrupper velegnet til mobile enheder, og kan myndig-hederne opnå øget brug ved at understøtte mobile enheder? I den vurdering vil tjenesteudbyder-nes omkostninger spille en væsentlig rolle. Antallet af tjenesteudbydere vurderes ud fra de 130 borgerrettede løsninger på NemLog-in primo 2012 med en forventet stigning til 200. Der er 70 virksomhedsrettede løsninger, som overføres fra virk.dk’s log-in til NemLog-in i 2012. Der forventes yderligere tilslutninger i de kommende år. I vurderingen af de samlede omkostninger bliver det forventede antal tjenester, som vil anvende løsningen, væsentlig. Rambøll har derfor til beregningsformål skønnet et antal tjenester for løs-ningerne. Skønnet er baseret på en vurdering af, hvor meget de skønnede omkostninger vil be-tyde, for tjenesteudbydernes beslutning om implementering. Det skal bemærkes, at de samlede omkostninger er meget følsomme overfor antallet, hvorfor der er valgt er forsigtigt antal.

43


Det vurderes til omkostningsberegningen, at 30 tjenester vil implementere den dyre native app-løsning, mens 50 tjenester vil anvende en billigere hybrid løsning.

Tabel 3: Oversigt over tjenesteudbydernes omkostninger

Antal tje-nesteud-bydere skønnet

Omkostning pr tjenesteudbydere

Omkostninger tjeneste-udbydere i alt


30 ½-1 mio. kr. 15-30 mio. kr.


50 1-200.000 kr. 5-10 mio. kr.


30 ½-1 mio. kr. 15-30 mio. kr.


50 1-200.000 kr. 5-10 mio. kr.

Web Proxy (W4) 200 0 kr. 0 kr.

9.3 Oversigt over omkostninger i løsningerne På grundlag af oversigten over de enkelte omkostningselementer præsenteres i dette afsnit et skøn over omkostningsniveauerne for de enkelte løsningsvarianter. Da skønnet over fælles omkostninger er meget usikkert, er omkostningsniveauet angivet med smileys, hvor en rød smiley viser et beløb over 8 mio. kr. og dermed højere end budgettet i initi-ativ 9.1.5

Tabel 4: Oversigt over omkostninger

Fælles om-kostninger

Omkostninger tjenesteudbydere

Samlede omkostninger for det offentlige









Web Proxy (W4) Over budget 0 kr. Ikke tilfredsstillende

Oversigten over omkostninger viser, at de to løsninger med native apps vil blive dyre for tjene-steudbyderne, og at de hybride løsninger kun vil have lidt mindre omkostninger for tjenesteud-byderne. De skønnede omkostninger for alle scenarier er betydeligt højere end de omkostninger der er estimeret i initiativ 9.1. Omkostningerne bygger som nævnt på Rambølls skøn på grundlag af ge-nerelle erfaringer, og en endelig omkostningsmæssig vurdering vil kræve en mere detaljeret be-regning på grundlag af detaljerede krav og eventuelt et tilbud.

5 http://www.digst.dk/Digitaliseringsstrategi/Digitaliseringsstrategiens-

initiativer/~/media/Files/Digitaliseringsstrategi/Initiativbeskrivelserne/91.ashx

44


10. BRUGERVENLIGHED

Et afgørende kriterium for udvælgelse af en løsning er, at den er brugervenlig. For brugerne vil log-in være en del af den samlede brugeroplevelse, som vil være bestemt af tje-nestens design og tilpasning til brugerens brugssituation og den mobile enheds skærm. For bru-geren vil det være den samlede brugeroplevelse, der har betydning for brugervenligheden, mens denne analyse alene har fokus på log-in funktionen. Her vil brugervenlighed blive vurderet ud generelle kriterier: er log-in løsningen let at lære og let at huske, effektiv og rar at bruge samt tilgængelig. Brugernes baggrund vil indgå gennem vurde-ring af brugernes IKT-kompetenceniveau og brugernes forventninger til, om der anvendes native app eller browser (web app). Til brug for evalueringen heraf arbejder vi med to personas i forhold til de to tekniske veje. App-persona er en IKT-kompetent bruger af sin mobile enhed og har allerede installeret og an-vendt en række apps. For ham er apps den naturlige og foretrukne måde at hente information og kommunikere med omverdenen. Denne persona er den mest udbredte smartphonebruger i dag. Web-persona er en bruger af en mobil enhed, der ikke kender til eller er uvant med anvendelse af apps og anvender smartphonens browser til at surfe på nettet. I takt med at web apps bliver bedre, vil denne brugergruppe blive større. Web personas forventes generelt at have lavere ge-nerelle IKT-færdigheder. For at sikre at den færdige log-in løsning har den ønskede brugervenlighed og tilgængelighed skal der ved implementeringen gennemføres usability tests, hvor brugervenlighed og tilgængelig-hed vurderes systematisk og i forhold til de forventede brugergruppers færdigheder.

Figur 19: App use case

Denne use case beskriver forløbet for en borger, der ønsker at tilgå en tjeneste, og derfor starter med at søge efter tje-nesten i sin app-store eller er linket til den fra en hjemmeside eller annonce. • Gå til app-store • Fremsøg tjenesteudbyders app • Download og installer app • Start app • NemID log-in • Brug tjeneste i app • Forlad tjeneste (skift til desktop)

Handlingerne i forbindelse med at hente app i app-store vil være lette at bruge for app-personas, mens web-personas med lave IKT-færdigheder vil finde dem van-skelige. App use casen dækker også hybride apps.med den forskel at tjenesten tilgås i en browser. Der gælder samme vurdering af brugervenlighed for denne løsningsvari-ant. I løsningsvarianterne med separat NemID app vil der være et ekstra trin, hvor NemID app'en skal fremsøges og downloades.

45


Figur 20: Web use case

Denne use case beskriver forløbet for en borger, der bruger en browser (web app) • Gå til tjenesteudbyder • Vælg tjeneste • Vælg log-in (log-in med proxy) • Brug tjeneste • Forlad tjeneste (SSO til andre

tjenester?)

Begge personas vurderes at være relevante målgrupper for NemID på mobile enheder. App per-sonas vurderes at være den aktuelt mest udbredte. Med udbredelse af HTML5-løsninger forven-tes der en vækst i antallet af web personas.

10.1 Er løsningen let at lære og let at huske Det er en forudsætning, at brugerne kan genkende indtastningsbilledet til NemID på PC (applet-ten). Det giver genkendelighed og bidrager til sikkerheden, at brugerne har mulighed for at skel-ne mellem et ægte og falsk indtastningsbillede. App personas forventes at kunne anvende browsere uden besvær, mens en web-persona vil skul-le overvinde nogle barrierer før han kan bruge en app:

• Han skal oprette en konto i app-store, dvs. at der skal indtastes brugeroplysninger, dan-nes kodeord og betingelserne skal ”læses” og godkendes

• Herefter kan app’en downloades – den installerer sig selv • Først nu kan app’en anvendes

En persona, der aldrig har brugt apps, vil således finde en mobil webløsning lettere at bruge. En app-persona vil ikke have problemer med at anvende browsere (web apps) – men han vil for-vente en løsning med et design, der har samme look-and-feel som en app. Den samlede vurdering er, at forskellene mellem apps og browsere (web apps) er små og i høj grad vil være persona-afhængigt.

10.2 Er løsningen effektiv at bruge Apps kræver et eller to ekstra trin, afhængigt af, om der skal downloades en NemID app eller om tjenesteudbyderens app har indlejret NemID kode. Da der forventes opdateringer af apps vil bru-gerne skulle downloade nye versioner en gang imellem. Med en separat NemID app vil den mobile enheds brugergrænseflade vise den ekstra app, som tager plads. Det kan opleves forvirrende og muligvis irriterende for brugere, der har mange apps åbne samtidigt. Løsningsvarianterne med en separat NemID app (N2 og H2) har derfor lavere brugervenlighed.

46


Da download af apps er velkendt for app-personas, vurderes forskellen mellem apps (med indlej-ret bibliotek – N1 og H1) og browser (web apps) (W4) ikke at have betydning.

10.3 Er løsningen rar at bruge Her er fokus på brugervenlighed i forhold til anvendelse af NemID-indtastningsbilledet og på, om de forskellige løsningsmuligheder har forskellig grad af brugervenlighed. Da NemID-indtastningsbilledet forventes at være stort set identisk i de forskellige løsninger, vil der ikke være forskel her.

10.4 Tilgængelighed Endelig indgår tilgængelighed som parameter, nærmere bestemt om løsningsmulighederne er forskellige i forhold til tilgængelighed. Tilgængeligheden på mobile enheder er grundlæggende bestemt af enhedens fysiske forhold, men operativsystemerne giver forskellige muligheder for at understøtte tilgængelighed. Både iOS og Android understøtter skærmlæsere, mens det ikke gælder for Windows Phone 7. Desuden har udformningen af løsningen stor betydning, hvilket falder uden for denne analyse. Samlet set er det vurderingen, at de skitserede løsninger i samme grad kan leve optil krav om tilgængelighed, såfremt der sættes fokus på dette i udvikling af brugergrænsefladerne. Det er muligt at udvikle løsninger til blinde og svagtseende til iOS og Android, men ikke til den nuværende version af Windows Phone 7.

10.5 Samlet vurdering

Tabel 5: Brugervenlighed

Let at læ-re/huske

Effektiv at bruge

Rar at bruge

Tilgæn-gelighed

Samlet vurde-ring


Ja Ja Ja Ok God

Hybrid - Indlejret sta-tisk bibliotek intern browser (H1)

Ja I mindre grad - kræver 2 apps

Ja OK Mindre god


Ja Ja Ja Ok God


Ja I mindre grad - kræver 2 apps

Ja OK Mindre god

Web Proxy (W4) Ja Nej Ja Ok God

De hybride løsninger (H1 og H2) har lavere brugervenlighed, da de kræver download og vedlige-hold af en ekstra app. Native apps (N1/N2) og proxy (W4) har samme niveau af brugervenlighed. Som nævnt skal der ved implementeringen gennemføres usability tests, hvor brugervenlighed og tilgængelighed vurderes systematisk og i forhold til de forventede brugergruppers færdigheder.

47


11. DÆKNING AF PRIVATE TJENESTEUDBYDERE

Den primære målgruppe for de undersøgte løsninger er offentlige tjenesteudbydere, den samme gruppe, som allerede anvender eller skal anvende NemLog-in ifølge eDag3-kravene. Det indgår som et af vurderingskriterierne, om løsningen også kan anvendes af private. Bag-grunden for det er ønsket om at have en fælles løsning på tværs af offentlige og private tjene-steudbydere, parallelt med PC-løsningen. Det vil være til fordel for borgerne, som ikke skal hånd-tere flere typer af løsninger. Særligt ved NemID-app-løsningen vil det være uhensigtsmæssigt, hvis borgerne skal have to NemID-apps på deres enhed, en til offentlige og en til private tjene-steudbydere. Det kan også give den fordel for det offentlige, at udviklings- og driftsomkostninger kan fordeles på flere. Løsningen ”App med indlejret kode” (N1) svarer til den løsning, som implementeres af DanID og bankerne. Det gør, at løsningen ud fra kriteriet om at dække private er attraktiv. De sikkerheds-mæssige krav til de tjenesteudbydere, der skal implementere løsningen gør dog, at det kun vil være en begrænset gruppe af tjenesteudbydere, der kan blive godkendt til at implementere løs-ningen og vil have ressourcer til at etablere og vedligeholde den. Løsningen NemID-app lokal (N2) vil kunne udbredes til private. De hybride løsninger (H1 og H2) er målrettet det offentlige i kraft af samspillet med NemLog-in. DanID kan etablere tilsvarende løsninger for private eller udbrede app-løsningen (N1 og N2). Løsningen web proxy vil ikke umiddelbart kunne understøtte private tjenesteudbydere, idet den vil blive opbygget med henblik på offentlige tjenesteudbydere i kraft af samspillet med NemLog-in. Det vil dog være muligt for f. eks. DanID at opbygge en løsning til private tjenesteudbydere.

Tabel 6: Dækning af private tjenesteudbydere

Dækning af private tjenesteudbydere


Teknisk muligt


NemLog-in er for offentlige Teknisk muligt at lave løsning til private


Teknisk muligt


NemLog-in er for offentlige Teknisk muligt at lave løsning til private

Web Proxy (W4) NemLog-in er for offentlige Teknisk muligt at lave løsning til private

For alle løsninger gælder, at udbredelse til private vil afhænge af DanIDs vurdering af markedet og vilje til at afholde udgifterne hertil.

48


12. KONSEKVENSER FOR REGLER OG STANDARDER OG FOR STYRING AF OMRÅDET

Det har været en forudsætning, at de anbefalede løsninger lever op til sikkerhedskravene i den nuværende OCES standard6, som i version 4 for personcertifikater dækker NemID med OTP. Standarden er udformet generelt, og et afgørende krav i forhold til NemID på mobile enheder er kravet om, at borgeren skal have enekontrol (sole control) over adgangen til sin private nøgle.

Certifikatindehaverens private nøgle må ikke kunne anvendes, uden at cer-tifikatindehaveren i hvert tilfælde har autoriseret anvendelsen, således at certifikatindehaveren opretholder enekontrol over sin private nøgle. https://www.nemid.nu/digital_signatur/oces-standarden/oces-

certifikatpolitikker/POCES_Certifikatpolitik_version_4.pdf, afsnit 7.2.8 Kravet er implementeret i designet af den tekniske løsning af NemID, hvor der er sikret en ubrudt, stærkt dobbeltkrypteret linje mellem borgerens udstyr og DanIDs back-end. DanID forventer, at implementeringen af mobil NemID til netbank i 2012 vil leve op til samme høje krav, som gælder for PC-versionen. Det sker bl.a. ved at stille høje sikkerhedskrav til de tjenesteudbydere, der implementerer den mobile version. For de app-baserede og hybride løsningsvarianter, der er undersøgt i denne rapport, er det vur-deringen, at de kan leve op til kravet om enekontrol gennem opretholdelse af den dobbeltkrypte-rede forbindelse, men at der er en række sikkerhedsmæssige sårbarheder, der gør dem risikable. For proxy-løsningen er det beskrevet, hvordan proxyen bryder den ubrudte forbindelse mellem borgerens mobile enhed og DanIDs back-end (afsnit 8.5.4). Denne løsningsvariant følger således ikke de facto standarden i forbindelse med kravet om enekontrol i PC-løsningen. JavaScript-ændringerne/ tilføjelserne, som skal sikre datakryptering, vil kræve en revision af protokollen for klient-DanID-kommunikation. Som det fremgår, er markedet for mobile enheder i kraftig udvikling, hvor antallet af brugere sti-ger, og hvor der kan forventes forskydninger i markedsdækningen af de forskellige operativsy-stemer. Der er derfor brug for at fastsætte regler og strukturer for governance af NemID-udvikling til mobile enheder. Disse procedurer mm. skal sikre, at de mest anvendte systemer un-derstøtter NemID, dvs. angiver, hvordan man træffer beslutninger om, hvornår der skal udvikles NemID-understøttelse til et nyt operativsystem eller nye versioner af allerede understøttede sy-stemer. Dette er særligt relevant i forbindelse med native app-baserede løsninger. Parallelt med udviklingen i brugertal kan der forventes en stigning i forsøg på at bryde sikkerhe-den. Traditionelt stiger antallet af sikkerhedsbrud med udbredelsen i markedet. Det betyder be-hov for en løbende overvågning af sikkerhedsrisici og et beredskab, der kan hæve sikkerheden i den valgte løsning eller skifte løsning. Leverandørerne kommer løbende med nye versioner og løsninger, som kræver vurdering af sik-kerhedsrisici og eventuelle tiltag for at imødegå dem. Dette er særligt relevant i forbindelse med native app-baserede løsninger. Såfremt en af de fem løsningsvarianter vælges som løsning til mobile enheder, skal Digitalise-ringsstyrelsen vurdere, om der er behov for en justering af OCES-standarderne, primært i form af en præcisering af forhold af betydning for mobile enheder. Der vil desuden som følge af den kraftige udvikling på markedet for mobile enheder være brug for øget opfølgning samt et beredskab til at ændre implementering og øge sikkerheden som følge af opståede og udnyttede sårbarheder.

6 https://www.nemid.nu/digital_signatur/oces-standarden/oces-certifikatpolitikker/

49


13. KONSEKVENSER I FORHOLD TIL KONTRAKT

Denne dimension omfatter en vurdering af, hvilke komponenter der skal udvikles og driftes af Nets/DanID og NNIT som følge af tekniske bindinger. Nets/DanID vurderes, da de er leverandør af NemID, mens NNIT er leverandør af NemLog-in. For de komponenter, hvor der ikke er tekniske bindinger, skal det vurderes, om der inden for kontrakterne og udbudsreglerne er mulighed for, at Digitaliseringsstyrelsen kan vælge at lade de to leverandører udføre opgaven eller anskaffe komponenterne hos andre leverandører.

13.1 Udbudsretlig vurdering af DanIDs kontrakter Nets/DanID's levering af digital signatur infrastrukturen sker på baggrund af to kontrakter indgå-et med Digitaliseringsstyrelsen (oprindeligt indgået mellem DanID og Videnskabsministeriet v. IT- og Telestyrelsen). Der er ikke i kontrakten stillet krav om, at infrastrukturen skal understøtte mobile enheder eller levering af applikationer til mobile enheder. De indledende afklaringer peger i retning af, at omkostningerne til de fornødne tilretninger i in-frastrukturen og udvikling af applikationer hver for sig vil overstige tærskelværdierne, hvorfor det må overvejes, om gennemførelsen heraf i øvrigt er udbudspligtig, eller om der er mulighed for helt eller delvist at foretage et direkte køb hos Nets/DanID. I afsnit 13.1.1 nedenfor foretages en udbudsretlig vurdering af, i hvilket omfang at tilretning af den eksisterende infrastruktur har karakter af en udbudspligtig ydelse. En tilsvarende vurdering foretages i afsnit 13.1.2 i forhold til udvikling af applikationer til brug for installation på mobile enheder.

13.1.1 Tilretninger af infrastruktur Den offentliggjorte udbudsbekendtgørelse for kontrakten vedrørende Digital Signatur, der fast-sætter den overordnede ramme for, hvad der er afløftet udbudspligt for, har følgende tekst: ”IT- og Telestyrelsen udbyder levering, vedligeholdelse, videreudvikling og drift af digital signatur in-frastruktur (…)”. Kontrakten med DanID indeholder ligeledes en adressering af videreudvikling som et element, der er omfattet af kontrakten. Det er ikke specificeret nærmere, hvad den pågældende ret til videreudvikling dækker over. Det må dog antages, at retten til at bestille videreudviklingsopgaver hos DanID må omfatte sådanne tilretninger i selve infrastrukturen, der er nødvendige for at kunne understøtte tidssvarende tje-nester til brugerne.

13.1.2 Udvikling af applikationer til brug for infrastrukturen Understøttelsen af digital signatur på mobile enheder forudsætter i nogle af løsningsvarianterne, at der udvikles applikationer, der skal installeres på mobile enheder hos brugerne. Som beskrevet ovenfor, indeholder kontrakten en ret til at bestille videreudviklingsopgaver hos Nets/DanID. Det er dog forbundet med en væsentlig usikkerhed, om udvikling af applikationer mm. uden for infrastrukturen ligeledes er omfattet af kontraktens "videreudviklingsret". Hvis udviklingsopgaven kan løftes af en tredjepart, og hvis opgaven har en ikke-ubetydelig øko-nomisk værdi, peger dette desuden i retning af, at den ikke er omfattet af kontrakten. Såfremt det vurderes, at udvikling af applikationer af tekniske og evt. rettighedsmæssige grunde alene kan udføres af Nets/DanID, kan købet af ydelser evt. foretages i medfør udbudsdirektivets artikel 31, stk. 1, litra b. I praksis gennemføres der i denne forbindelse et udbud efter forhand-ling uden forudgående offentliggørelse. Det skal dog understreges, at artikel 31, stk. 1, litra b, har karakter af en snæver undtagelse til den generelle pligt om konkurrenceudsættelse. Hvis ar-tikel 31, stk. 1, litra b, anvendes, bør det overvejes at supplere med en frivillig annoncering af den påtænkte anskaffelse efter § 4 i lov om håndhævelse af udbudsreglerne. Hvis det er muligt at konkurrenceudsætte udviklingen af applikationer, må det forventes, at Nets/DanID vil være en potentiel byder på en sådan opgave. Det er derfor vigtigt, at evt. konkur-

50


rencefordele, Nets DanID måtte have, som følge af at de er leverandør til den grundlæggende in-frastruktur, skal søges minimeret mest muligt. I denne forbindelse er det væsentligt at sikre, at DanID ved tilretning af egen infrastruktur med henblik på at muliggøre understøttelse af mobile enheder ikke etablerer en sådan situation, at de har en særlig konkurrencefordel. Opstår et sådant forhold, kan Digitaliseringsstyrelsen være for-pligtet til at afvise DanID i en kommende udbudsforretning.

13.2 Udbudsretlig vurdering af NNITs kontrakt NNITs leverance af NemLog-in sker på grundlag af kontrakt med Digitaliseringsstyrelsen (oprin-deligt indgået mellem NNIT og Økonomistyrelsen). NNIT er i henhold til kontraktens § 12 forplig-tet til at levere videreudviklingsydelser. Videreudvikling sker efter kontraktens bilag 15. Et af de emner, der er nævnt i bruttolisten over mulige videreudviklingsaktiviteter, er: ”Understøttelse af andre platforme, som f.eks. mobile en-heder, smart phones etc.” På den baggrund er udbudspligten afløftet for de tilretninger i selve infrastrukturen, der er nød-vendige for at kunne understøtte mobile tjenester til brugerne. Parallelt med det anførte i afsnit 13.1.2 kan der være usikkerhed om, hvorvidt udvikling af løs-ninger som web proxy uden for NNITs infrastruktur er omfattet af kontraktens "videreudviklings-ret". Web proxy kan udvikles uafhængigt af NemLog-in eller NemID, men der vil være sikker-hedsmæssige fordele ved, at serverne står i samme netværkszone som NemLog-in's eller Da-nID's back-ends, for ikke at introducere for mange nye angrebsvektorer. Udvikling af Javascript til forøgelse af sikkerheden i web proxy-løsningen forventes at ligge over udbudsgrænsen og vurderes ikke at være en opgave, der er dækket af kontrakten med NNIT.

Tabel 7: Udviklingsopgaveplacering

Teknisk vurdering af opgave-placering

Udbudsvurdering

Apps og hybrid (N1, N2, H1, H2)

• Snitflade og back-end DanID – ud-vikling og drift

Kun DanID Mulig

• Kode til app – ud-vikling og drift

DanID eller 3. parts-leverandør? Kræver udbud

Web proxy (W4) • Snitflade og back-

end DanID Kun DanID Mulig

• Etablering og drift af proxy

NNIT eller DanID. 3. parts-leverandør mulig men mindre sikker

Kan være dækket af NNITs kontrakt

• JavaScript til kli-ent

DanID, NNIT eller 3.parts-leverandør?

Udbud

På den baggrund kan det konkluderes, at der for alle fem løsningsvarianter skal gennemføres ud-bud for dele af opgaven.

51


14. PROJEKTRISICI

En faktor i vurderingen af løsningsvarianterne er, om de kan gennemføres inden for tid og bud-get. Her indgår det foregående afsnits vurdering af, om der skal gennemføres EU-udbud.

14.1 Løsningernes tekniske robusthed, performance og modenhed Markedet for mobile enheder er i rivende udvikling, hvilket betyder, at der ikke er etableret stan-darder på tværs af leverandørerne for sikkerhedsløsninger. Det betyder også, at vilkårene for sikkerhed ændrer sig fra version til version. Også leverandørernes udbredelse i markedet ændrer sig. Analysen dækker iOS, Android og Win-dows Phone 7, hvor det sidste er introduceret i 2011 og først forventes at blive udbredt i 2012. I de kommende år kan der således forventes ændringer i operativsystemernes udbredelse, som kan betyde ændringer i den offentlige NemID-løsning. Løsningen ”Statisk indlejret NemID-bibliotek” er udviklet til bankerne, og der er dermed erfaring med løsningen og dens samspil med NemID. Bankerne er i færd med at udvikle native apps til iOS og Android. Løsningen ”NemID app lokal” er ikke anvendt i andre sammenhænge, og operativsystemerne un-derstøtter ikke inter-app-kommunikation på en sikker, ensartet og brugervenlig måde. Der er in-ternationale erfaringer med elementer af denne løsningsmodel. Løsningen ”Web proxy” er ikke anvendt i andre sammenhænge. Den bygger delvist på velkendte komponenter, men sammensætningen er ikke kendt. Desuden skal der nyudvikles sikkerhedsløs-ninger med Javascript, som skal testes. Endelig skal DanID ændre protokoller i back-enden. Der er flere eksempler på native apps, der kalder en browser, f. eks. Skadestueapp fra Region Syddanmark. Byvejret fra DMI til Android starter en browser for at vise nyheder. Medicintjek fra Lægemiddelstyrelsen starter en browser for at vise nyheder. De findes dog kun til iOS og Android. Generelt gælder, at web apps bygger på serverbaserede komponenter, hvor kode, der skal afvik-les på den mobile enhed, overføres dynamisk hver gang, den skal bruges. Det betyder, at koden kan ændres hurtigt uden distributionsomkostninger. For native apps gælder, at koden efter færdig udvikling skal uploades til de tre app-markeder, eventuelt godkendes, hvorefter brugerne skal downloade dem før brug. Der er mekanismer i markederne til at håndtere, at brugeren får besked om at opdatere sin app. Denne proces bety-der, at apps skal testes langt mere grundigt før distribution, fordi rettelser har store omkostnin-ger (herunder brugernes holdninger til tjenesteudbyderen) og kan tage lang tid. Samlet set vurderes løsningen ”Statisk indlejret NemID-bibliotek” at være mest moden og der-med give færrest risici.

14.2 Projekt- og tidsplan Det samlede projektforløb rummer følgende hovedaktiviteter:

• Planlægning af løsning • Udarbejdelse af standarder • Udarbejdelse af krav og eventuelt øvrigt udbudsmateriale • Anskaffelse (eventuelt udbud, valg af leverandør, indgåelse af kontrakt) • Udvikling og implementering af fælles løsninger, integrationstestfaciliteter • Udvikling af tjenesteudbyderløsninger.

Tidsforbruget i de forskellige aktiviteter vil variere meget afhængigt af opgavens omfang, og af om anskaffelsen kan ske inden for gældende kontrakter, eller om der skal gennemføres EU-udbud.

52


Det samlede tidsforbrug vil desuden afhænge af, om der skal ventes på beslutninger og beman-ding af aktiviteterne. Planlægning af løsning Denne aktivitet kan gennemføres på 2-4 kalenderuger på grundlag af de løsninger, der beskrives i denne rapport. Udarbejdelse af standarder Hvis valg af en løsning kræver en ændring af en standard, skal dette indarbejdes i tidsplanen. Den tekniske udarbejdelse kan udføres på 4-8 kalenderuger, hvorefter der vil være en høringsfa-se på 30 dage. Hertil kommer efterbehandling på 2-4 uger samt afventning af møde i standardi-seringsudvalg. Det samlede tidsforbrug til ændring af en standard vil således være 3-4 måneder. Udarbejdelse af krav og eventuelt øvrigt udbudsmateriale Arbejdet med krav og udbudsmateriale vil afhænge af løsningens karakter, og af om anskaffelsen kan ske under gældende kontrakt, eller der skal gennemføres EU-udbud. Udarbejdelse af krav til DanID og NNIT kan ske på 4-8 kalender uger til mindre løsninger, og de gældende kontrakter vil dække opgaven. Såfremt der skal gennemføres EU-udbud, skal der afsættes 2-4 måneder til udarbejdelse af ud-budsmateriale. Udarbejdelse af krav og udbudsmateriale kan ske parallelt med udarbejdelse af standarder. Tidsangivelse forudsætter, at der kan allokeres de nødvendige ressourcer i perioden. Ressource-behovet vil afhænge af den valgte løsning. Anskaffelse (eventuelt udbud, valg af leverandør, indgåelse af kontrakt) Anskaffelse under gældende kontrakt kan gennemføres hurtigt, idet leverandørerne skal give estimater på en løsning med korte frister. Det vil tage 4-6 uger. Hvis der skal gennemføres et EU-udbud, skal der forventes et tidsforbrug på 4 måneder til gen-nemførelse af udbud med de gældende tidsfrister.

Tabel 8: Tidsplan for EU-udbud

Tid i dage Dato Aktivitet

0 14. maj Indrykning af udbudsbekendtgørelse i EF-tidende 32 14. juni Frist for modtagelse af anmodninger om prækvalifikation 46 30. juni Meddelelse om resultatet af prækvalifikation sendes til al-

le ansøgere. Udbudsmateriale afsendes til de udvalgte le-verandører.

87 10. august Frist for modtagelse af tilbud 107 30. august Meddelelse om resultatet af udbuddet sendes til tilbudsgi-

vere 119 12. september Indgåelse af kontrakt (tidligst 11 dage efter meddelelse

om resultatet) Tidsplanen er dog problematisk, da den pålægger leverandørerne at udarbejde tilbud i sommerfe-rieperioden, hvilket betyder, at der bør tillægges fire uger til tidsplanen. Anskaffelsen kan gennemføres som miniudbud under SKI 2.18, der løber til den 30. juni. Udvikling, implementering og test af fælles løsninger, integrationstestfaciliteter Udvikling, implementering og test vil afhænge af løsningens karakter og omfang. Da der er tale om en sikkerhedsløsning med høje sikkerhedskrav, skal der regnes med mindst 1-2 måneder til test af løsningen. Hvis der i projektet er krav om prototyping eller proof-of-concept, vil det betyde en længere ud-viklingsperiode.

53


Udvikling, implementering og test af fælles løsninger vil tage 3-6 måneder. Til sammenligning kan nævnes, at DanID har brugt mere end et halvt år på udvikling af app-løsningen til bankerne. Udvikling af tjenesteudbyderløsninger Udvikling af tjenesteudbydernes løsninger kan ske parallelt med udvikling og test af de fælles løsninger, og test af fælles løsninger vil forudsætte, at der er nogle tjenesteudbydere, der vil ind-gå i dette testforløb. Tjenesteudbyderne kan forberede deres løsninger fra det tidspunkt, hvor kravspecifikationen er færdig, med mindre der ligger afklaringer i udviklingsfasen, der kan få betydning for, hvilke løs-ninger der vælges. Samlet tidsplan

Figur 21: Projektplan

Den samlede tidsplan viser, at det kræver stram projektstyring og udvikling under eksisterende kontrakter at nå at levere en løsning inden udgangen af 2012. Da der som nævnt ovenfor vil ind-gå EU-udbud i alle løsningerne, vil det således ikke være muligt at implementere nogen af løs-ningsvarianterne inden 2013.

14.3 Risikoanalyse Formålet med risikoanalysen er dels at vurdere, hvilke risici der er de alvorligste i forhold til at nå en målsætning om NemID til mobile enheder, dels at finde strategier for at overkomme og redu-cere disse risici. En risiko består altid af sandsynligheden for, at et eller andet hænder samt kon-sekvensen af den pågældende hændelse. Reduktion af risikoen kan derfor foretages på to områ-der; dels reduktion af sandsynligheden for at det pågældende problem vil opstå (forebyggelse), dels reduktion af konsekvenserne af den forventede hændelse (afhjælpning). De identificerede risici vurderes som lille, middel eller stor. Baseret på denne scoring prioriteres de potentielle risici, der skal arbejdes videre med. Risikoanalysen foretages på baggrund af projektets målsætning om at etablere NemID til mobile enheder inden udgangen af 2012. Da projektet involverer flere parter, vil risikoanalysen behandle: • Hvilke risici er der i interessenternes projekter? • Hvad er konsekvensen af disse risici og deres sandsynlighed? • Hvilke tiltag er der og kan iværksættes for at imødegå disse risici?

54


Tabel 9: Risici

Nr. Beskrivelse Gælder for Sand-synlighed

Konse-kvens

Tiltag

1 Den stramme tidsplan kan ikke holdes

Alle Middel Middel Stram styring, valg af basale løsninger

2 Den valgte løsning imødekommer ikke tjenesteudbydernes behov

N1, N2, del-vist H1, H2

Middel Middel Valg af fleksibel løsning, infor-mation til tjene-steudbyderne

3 Den valgte løsning skaber politisk debat, der kræver justering i løsningen

W4 Middel Middel Valg af løsning

Samlet vurderes, at alle fem løsninger har høje projektrisici.

14.4 Vurdering i forhold til tidsplan og projektrisici

Tabel 10: Tidsplan og projektrisici

Tidsplan Projektrisici

Native App - Indlejret sta-tisk bibliotek (N1)

Kan ikke gennemføres i 2012 Ikke tilfredsstillende





Hybrid – NemID app lokal intern browser (H2)


Web Proxy (W4) Kan ikke gennemføres i 2012 Ikke tilfredsstillende

55


15. SAMLET VURDERING

Analysen har opstillet og vurderet 13 løsningsvarianter inden for tre grundlæggende løsningsde-signs. Det ene løsningsdesign baserer sig på native apps, det andet på web apps, mens det tred-je kombinerer de to veje i hybride løsninger. Af de 13 løsningsvarianter er de 8 sorteret fra, fordi de ikke er teknisk mulige, eller fordi de har store sikkerhedsmæssige svagheder. Tilbage er fem løsningsvarianter, der er teknisk mulige, og som på forskellig måde kan opnå hø-jere sikkerhed gennem mitigeringstiltag, dvs. tiltag for at øge sikkerheden. De fire løsningsvarianter danner to par baseret på native apps, hvor native app-løsningen er sup-pleret med en hybrid løsning, der kan genbruge NemLog-in-infrastrukturen. Hertil kommer web proxy-løsningen, som er en web app. Sikkerheden i de fem løsninger er præget af, at operativsystemerne til mobile enheder på nogle områder er mere sikre end PC-operativsystemer. De tre mobile operativsystemer understøtter dog ikke samme sikkerhedstiltag, og det er derfor vanskeligt at finde fælles løsninger, der under-støtter de høje krav til sikkerhed, som kræves i forbindelse med anvendelse af NemID. Det vurderes, at de væsentligste sårbarheder for angreb for NemID-løsningen på mobile enheder vil være hos brugeren og i selve den mobile enhed. Det er vurderingen, at sårbarheder hos brugeren (valg af sikre koder, sikker brugeradfærd) ikke adskiller sig væsentligt fra PC’en. I vinteren 2011-2012 har phishing mod NemID-bankløsninger været det mest omtalte i medierne, og phishing kan også forventes i forbindelse med mobile en-heder. For at modvirke phishing skal brugeren kunne se på skærmen, hvad han gør, og om han tilgår en legitim tjeneste, ved f.eks. at URL vises. Sårbarheden i den mobile enhed er bestemt af, at det ikke er muligt at anvende Java applet-teknologien på mobile enheder. På PC’er giver applet-teknologien en meget høj sikkerhed (den downloades hver gang og er signeret af DanID), mens der ikke er tilsvarende sikre løsninger for den kode, der skal afvikles på den mobile enhed. Da gevinsterne for hackere ved at bryde sikkerheden er store, kombineret med at risikoen for pågribelse og straf er lille, er erfaringerne, at hackere i stigende grad forsøger at udnytte eksiste-rende såvel som ny-introducerede sårbarheder. Erfaringerne viser ydermere, at kendte og identi-ficerede sikkerhedsbrud er blevet gennemført ved at kombinere flere sårbarheder. De fem løsninger er derefter vurderet i forhold til:

• Omkostninger til drift og udvikling • Brugervenlighed • Dækning af private tjenesteudbydere • Konsekvenser for regler og standarder • Konsekvenser i forhold til Digitaliseringsstyrelsens kontrakter • Projektrisici, herunder tidsplaner

Omkostningsvurderingen omfatter både de centrale, fælles omkostninger og tjenesteudbyder-nes omkostninger til at implementere log-in. Derimod indgår omkostninger til at tilpasse tjene-sternes design til de mobile enheders skærmformater ikke. For de fælles komponenter er omkostningsniveauet for alle løsninger over 8 mio. kr., som er budgettet for NemID på mobile enheder i Digitaliseringsstrategien. Oversigten over omkostninger viser, at de to løsninger med native apps vil blive dyre for tjene-steudbyderne, og at de hybride løsninger kun vil have lidt mindre omkostninger for tjenesteud-byderne. Omkostningerne kan betyde, at nogle tjenesteudbydere vil fravælge den mobile løsning. Brugervenligheden er vurderet ud fra forskellige dimensioner (er løsningen let at lære og let at huske, effektiv og rar at bruge samt tilgængelig).

56


For brugerne vil log-in være en del af den samlede brugeroplevelse, som vil være bestemt af tje-nestens design og tilpasning til brugerens brugssituation og den mobile enheds skærm. For bru-geren vil det være den samlede brugeroplevelse, der har betydning for brugervenligheden, mens denne analyse alene har fokus på log-in funktionen. De hybride løsninger har lavere brugervenlighed, da de kræver download og vedligehold af en ekstra app. Native apps og proxy har samme niveau af brugervenlighed. Tilgængeligheden er den samme for løsningerne, men der er forskelle på operativsystemerne. Det er muligt at udvikle løsninger til blinde og svagtseende til iOS og Android, men ikke til den nuværende version af Windows Phone 7. Ved implementeringen skal der gennemføres usability tests, hvor brugervenlighed og tilgænge-lighed vurderes systematisk og i forhold til de forventede brugergruppers færdigheder. De fem undersøgte løsninger vil kunne tilbydes til private tjenesteudbydere. For alle løsninger gælder, at udbredelse til private vil afhænge af DanIDs vurdering af markedet og vilje til at af-holde udgifterne hertil. Ingen af de fem løsninger forventes at kræve ændringer i regler og standarder. Dog er web proxy-løsningen ikke i overensstemmelse med praksis i PC-løsningen for kravet om enekontrol i OCES-standarden, og det kan medføre ændringer i DanIDs protokol. Som følge af den kraftige udvikling på markedet for mobile enheder vil der være brug for øget opfølgning samt et beredskab til at ændre implementering og øge sikkerheden som følge af op-ståede og udnyttede sårbarheder. De fem løsninger består hver af flere komponenter, hvoraf nogle kan leveres inden for Digitali-seringsstyrelsens kontrakter med DanID og NNIT. Der indgår i alle fem løsninger komponen-ter, der har en størrelse, så de skal anskaffes gennem udbud. Det forhold, at komponenterne har en størrelse, der medfører krav om udbud, har også konse-kvenser for projektrisici, herunder tidsplaner. Det betyder, dels at der skal afsættes tid til udvikling og test af løsningerne, dels at der i alle løsninger indgår komponenter, der skal anskaf-fes gennem EU-udbud. Ingen af de fem løsninger vil derfor kunne blive etableret inden udgangen af 2012. Den samlede vurdering af de fem løsningsvarianter er, at ingen af dem lever op til kravene om høj sikkerhed. De fælles omkostninger vil for alle løsningerne overstige budgettet til Digitalise-ringsstrategiens initiativ 9.1: Sikker digital selvbetjening på mobilen. Hertil kommer, at fire løs-ninger (app og hybride) vil medføre omkostninger for tjenesteudbyderne. To af løsningerne lever ikke op til krav om brugervenlighed.

Tabel 11 Samlet vurdering

Sikkerhed Samlet øko-nomi

Brugervenlighed



God

Hybrid - Indlejret statisk bib-liotek intern browser (H1)


Mindre god



God



Mindre god

Web Proxy (W4) Ikke sikker Ikke tilfredsstillende

God

Også i forhold til de øvrige kriterier som tid og risiko er løsningsvarianterne mangelfulde.

Documents

NemID på Mobile Enheder