NemID på Mobile Enheder - Appendix

Til

Digitaliseringsstyrelsen

Dokumenttype

Teknisk arbejdspapir

Dato

Marts 2012

DIGITALISERINGS-STYRELSEN NEMID PÅ MOBILE ENHEDER APPENDIKS – NYE LØS-NINGSMODELLER

DIGITALISERINGSSTYRELSEN APPENDIKS – NYE LØSNINGSMODELLER

NemID på mobile enheder - Teknisk og sikkerhedsmæssig afklaring Appendiks – Nye løsningsmodeller

Revision 1.1 Dato 29-03-2012

3

INDHOLD

1. Baggrund og formål 1

1.1 Om denne rapport 1

1.2 Baggrund og formål 1

2. Opstilling af løsningsmodeller 1

2.1 Om assurance level 2 1

3. Teknisk og sikkerhedsmæssig analyse 2

3.1 Native app med assurance level 2 2

3.2 Native app med assurance level 2 4

3.3 Web proxy med assurance level 2 4

3.4 Angrebstyper 5

3.5 Sikkerhedskriterier 6

3.6 Fælles app med indlejret statisk bibliotek og intern browser 6

3.7 Opsamling på teknisk og sikkerhedsmæssig vurdering 8

3.8 Log-in og signering 9

4. Omkostninger til drift og udvikling 9

4.1 Overblik over tekniske komponenter i løsningerne 9

4.1.1 Native app med assurance level 2 9

4.1.2 Web proxy med assurance level 2 10

4.1.3 Fælles central app – Indlejret statisk bibliotek og intern browser 11

4.2 Omkostninger 11

4.2.1 Digitaliseringsstyrelsens omkostninger til etablering og drift af databasesystem til aktivering af assurance level2. 11

4.2.2 Digitaliseringsstyrelsens omkostninger til assurance level 2 mobil log-in side 12

4.2.3 Digitaliseringsstyrelsens omkostninger til native app med assurance level 2 12

4.2.4 Digitaliseringsstyrelsens omkostninger til fælles central app 12

4.2.5 Digitaliseringsstyrelsens omkostninger til DanIDs snitflade og back-end 13

4.2.6 Digitaliseringsstyrelsens samlede omkostninger 13

4.2.7 Tjenesteudbydernes omkostninger til native app 13

4.2.8 Tjenesteudbydernes omkostninger til tilpasning til level2 14

4.2.9 Tjenesteudbydernes omkostninger i forbindelse med fælles app 15

4.2.10 Tjenesteudbydernes samlede omkostninger 15

4.3 Oversigt over omkostninger i løsningerne 15

5. Brugervenlighed 16

5.1 Er løsningen let at lære og let at huske 16

5.2 Er løsningen effektiv at bruge 16

5.3 Er løsningen rar at bruge 16

5.4 Tilgængelighed 16

5.5 Samlet vurdering 17

6. Dækning af private tjenesteudbydere 17

7. Konsekvenser for regler og standarder og for styring af området 17

8. Konsekvenser i forhold til kontrakt og udbud 18

9. Projektrisici 19

9.1 Løsningernes tekniske robusthed, performance og modenhed 19

9.2 Projekt- og tidsplan 19

4

9.3 Risikoanalyse 19

9.4 Vurdering i forhold til tidsplan og projektrisici 20

10. Samlet vurdering 20

OVERSIGT OVER TABELLER OG FIGURER

Tabel 1: Oversigt over Digitaliseringsstyrelsens samlede omkostninger........ 13

Tabel 2: Oversigt over tjenesteudbydernes omkostninger .......................... 15

Tabel 3: Oversigt over omkostninger ..................................................... 15

Tabel 4: Brugervenlighed ..................................................................... 17

Tabel 5: Dækning af private tjenesteudbydere ........................................ 17

Tabel 6: Udviklingsopgaveplacering ....................................................... 19

Tabel 7: Risici .................................................................................... 20

Tabel 8: Tidsplan og projektrisici ........................................................... 20

Tabel 9: Samlet vurdering ................................................................... 22

Figur 1: Native app med assurance level 2 ................................................ 3

Figur 2: Web proxy med assurance level 2 ................................................ 5

Figur 3: Fælles app med indlejret statisk bibliotek og intern browser ............. 7

Figur 4: N5 Omkostningskomponenter ................................................... 10

Figur 5: W5 komponenter .................................................................... 10

Figur 6: Komponenter i Statisk indlejret NemID bibliotek og hybrid ............. 11

Figur 7: Selvbetjening på brondby.dk .................................................... 14

1

NemID på mobile enheder - Teknisk og sikkerhedsmæssig afklaring – Appendiks – Nye løsningsmodeller

1. BAGGRUND OG FORMÅL

1.1 Om denne rapport Denne rapport er udarbejdet som et appendix til hovedrapporten "NemID på mobile enheder" fra marts 2012. Rapporten forudsætter, at hovedrapportens indhold er læseren bekendt, idet forklaringer og ud-dybninger findes i hovedrapporten.

1.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. Hovedanalysen har undersøgt 13 løsningsvarianter. Den samlede vurdering er, at ingen af dem lever op til kravene om høj sikkerhed svarende til kravene til NemID på PC'er. De fælles omkost-ninger vil for alle løsningerne overstige budgettet til Digitaliseringsstrategiens initiativ 9.1: Sikker digital selvbetjening på mobilen. Hertil kommer, at fire løsninger (app og hybrid-løsninger) vil medføre omkostninger for tjenesteudbyderne. På den baggrund blev det på styregruppemøde d. 1. marts besluttet at undersøge yderligere tre varianter for implementering af NemID funktionalitet på mobile enheder. De to varianter adskiller sig ved at bygge på et lavere sikkerhedsniveau i forhold til brugerens autenticitet, nemlig assurance level 2, hvilket betyder, at de kun kan anvendes til tjenester, hvis krav til sikkerhed kan dækkes af level 2. Den tredje variant implementerer NemID på mobile en-heder med samme sikkerhedsniveau som på PC'er, men adskiller sig ved at koble tjenester og sikkerhed i samme app. Der er knyttet en række begrænsninger til den tredje model, herunder begrænsninger i selve modellen og i relation til selve brugen samt udvalget af tiltænkte tjeneste-udbydere.

2. OPSTILLING AF LØSNINGSMODELLER

De tre undersøgte løsningsmodeller i den supplerende analyse er:

• N5 - En native app med assurance level 2 (dette begreb forklares nedenfor), hvor der gi-ves begrænset adgang til tjenester. Løsningen forudsætter NemID log-in og første gangs NemID autentificering fra en PC. Dette er reelt en variation over model N1 i hoveddoku-mentet. Modellen anvendes af f. eks. e-boks.

• W5 - En web app med assurance level 2- en løsning hvor der gives begrænset adgang til tjenester med OIOSAML med assurance level 2. Løsningen forudsætter NemID log-in og første gangs NemID autentificering fra en PC. Dette er i realiteten en variant af web proxy modellen - W4.

• H5 - Fælles central app til borgere. Det er en variant af H1 modellen dvs. app med indlej-ret statisk NemID bibliotek med intern browser, der gennem wrapper giver adgang til fle-re udvalgte offentlige tjenester. Denne fælles app giver adgang til de vigtigste offentlige tjenester og på den måde tilveje-bringes single sign-on funktionalitet i denne model.

2.1 Om assurance level 2 Begrebet assurance level kan oversættes til sikkerhedsniveau og er defineret af de amerikanske National Institute og Standards and Technology (NIST). Kort sagt er assurance level 2 autentifikation med brugernavn og password, mens assurance le-vel 3 er autentifikation med f. eks. nøglekort som NemID1. Som det fremgår af "Vejledning vedrørende niveauer af autenticitetssikring" skal tjenesteudby-derne vurdere sikkerhedsbehovet i deres tjenester og vælge et dækkende niveau af autentitets-

1 http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf

2


sikring2. Tilsvarende vil en log-in-løsning til mobile enheder, der har assurance level 2, kræve at tjenesteudbyderne vurderer, om deres tjenester må tilgås med denne løsning, og om tjenesterne eventuelt kræver tilpasning til dette assurance level. 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 Det skal dog bemærkes, at der ikke er en tæt sammenhæng mellem assurance level 2 eller 3 og sikkerhedsbekendtgørelsens krav om sikkerhed i forbindelse med behandling af personoplysnin-ger. Set fra borgernes synsvinkel kan introduktion af log-in baseret på assurance level 2 krav betyde endnu et log-in, hvor der skal holdes styr på brugernavn og password – hvis man vælger bruger-navn og password, der er forskellige fra dem, der anvendes med assurance level 3 dvs. NemID. Dog vil dette eventuelle nye sæt af brugernavn og password være fælles for flere offentlige løs-ninger.

3. TEKNISK OG SIKKERHEDSMÆSSIG ANALYSE

3.1 Native app med assurance level 2

I denne løsning logger slutbrugeren først på et NemID beskyttet website via en PC og slår mobil-adgang til. Brugeren bliver via websitet præsenteret for en aktiveringskode, der så sammen med brugernavn eller CPR nummer samt password indtastes i app’en på den mobile enhed. Fremover kan brugeren tilgå data fra tjenesteudbyderen ved blot at indtaste brugernavn eller CPR nummer samt password i den mobile enheds app. En konsekvens ved en sådan model er, at man kan vælge at afkoble løsningen fra NemID infrastrukturen efter den initiale autentifikation, hvis det er ønskeligt. Man kan dog også vælge at integrere log-in-logikken i det statisk indlejrede bibliotek med dele af NemID infrastrukturen, for at sikre en tovejs korrelation, ved f. eks. oprettelse og ændringer, mellem valgt brugernavn og password i NemID på PC løsningen og den mobile løs-ning. Vi vil i det følgende referere til det indlejrede bibliotek som level 2 log-in biblioteket og ikke NemID biblioteket. Modellen sænker autentifikationsniveauet fra assurance level 3 til 2, idet der skiftes fra 2-faktor til 1-faktor log-in, og sikkerheden derfor ikke er på højde med PC-versionen af NemID. En sådan forringelse af sikkerheden vil kun være acceptabel for så vidt typen af operationer, brugeren kan udføre og typen af information brugeren kan se, begrænses. I en bankløsning kunne man fore-stille sig, at pengeoverførsler ikke var mulige, men at det dog var muligt at se kontoudtog (uden en kompromittering af persondata). Specifikt bør det ikke tillades at udføre digital signering un-der denne model, grundet det lavere sikkerhedsniveau, hvilket netop er affødt af, at man ikke kan sikre brugerens autenticitet på et tilstrækkeligt niveau. Log-in logikken udbydes som et kodebibliotek til de tre platforme, som kompileres med ind i kli-entapplikationen, men hvor sikkerhedsniveauet sænkes til assurance level 2. Det er så Tjeneste-udbyderens ansvar på serversiden at tjekke, hvilket autentifikationsniveau den medsendte SAML assertion har, og følgelig begrænse adgangen. Klienten kan nu via et eksponeret API kommunikere med level 2 log-in biblioteket, der igen vare-tager dialogen med slutbrugeren ift. autentifikation, kryptografiske operationer, samt den bag-vedliggende dialog med level 2 log-in server og infrastruktur. Modellen er meget lig N1 og illustreret på figuren nedenfor. Den røde ramme angiver den del af løsningen indenfor 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 sikker-hedsperimeteren.

2 http://digitaliser.dk/resource/363424

3


Figur 1: Native app med assurance level 2

Løsningen er teknisk mulig på alle 3 platforme, men udfordres sikkerhedsmæssigt af, at level 2-koden bliver gjort tilgængelig for klienten. Sidstnævnte mitigeres dog ved at skifte til assurance level 2 og dermed begrænse skaden ved hacking. Løsningen understøtter ikke brug af OIOSAML og kommunikation med NemLog-in. Angrebstyper Jaibreaking / Rooting: Et jailbreak kan detekteres (dog ikke med 100% garanti). Phishing: Det er muligt at lave et bibliotek eller en lignende brugergrænseflade, der opfører sig som det officielle level 2 log-in bibliotek. Alle de identificerede tiltag (hemmeligt billede, hemmeligt spørgsmål etc.) 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 høj grad af den krypterede forbindelse. Manipulation af kode: Kode, der kompileres med ind i en anden binær fil er reelt sårbar overfor 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 overfor manipulation og brugeren har ingen mulighed for at verificere, at det er det officielle level 2 log-in bibliotek, der anvendes. Samtidig sænkes assurance level til 2 og sikkerhedsniveauet er derfor lavere end for PC versio-nen. NemID Autenticitet (level 2 server autenticitet): Se ovenfor. Privacy af signerede data: Signering af data bør ikke tillades i denne model, da tjenesteud-byderens sikkerhed for brugerens autenticitet ikke er høj nok (assurance level 2).

4


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). Konsekvensen vil være lille, da risikoen for at kompromittere en borgers data kun vedrører level 2 data. Sandsynlighed Konsekvens Mitigering Samlet risiko-

vurdering Native app med assurance level 2

Mellem Lille Begrænset ad-gang til sensitive informationer og service Governance ift TU'er

Sikker ift authentifi-cation level 2

Konklusionen er, at løsningen er teknisk mulig på alle 3 platforme, men den udfordres sikker-hedsmæssigt af, at level 2 log-in-koden bliver gjort tilgængelig for klienten. Ved at sænke autentifikationsniveauet til assurance level 2 forhindres misbrug af meget sensitive data og operationer, da disse simpelthen ikke vil være tilgængelige fra serveren. Det skal poten-tielt sættes en governance- og overvågningsmodel op, som løbende tjekker, hvorvidt tjenesteud-bydere overholder det begrænsede udbud af operationer. Reduktionen i assurance level niveauet betyder samtidig, at løsningen lettere kan tilbydes til både private og offentlige tjenesteudbyde-re. Løsningen indgår på den baggrund i den videre analyse.

3.3 Web proxy med assurance level 2 Dette er en variant over proxy løsningen W4 i hoveddokumentet, som fungerer som i N5 ved at brugeren først logger sig på et NemID beskyttet site og registrerer sig som bruger af mobile løs-ninger. Brugeren får nu en aktiveringskode, der sammen med brugernavn samt password skal bruges ved en autentifikation. En konsekvens ved en sådan model er, at man kan vælge at afkoble løsningen fra NemID infra-strukturen efter den initiale autentifikation, hvis det er ønskeligt. Man kan dog også vælge at in-tegrere log-in-logikken implementeret på proxy serveren med dele af NemID infrastrukturen for at sikre en tovejs korrelation, ved fx oprettelse og ændringer, mellem valgt brugernavn og pass-word i NemID på PC løsningen og denne løsning. Det indlejrede bibliotek vil blive referet til som level 2 log-in biblioteket og ikke NemID biblioteket. I denne model vil brugeren blive sendt omkring proxy serveren, når vedkommende via mobilen forsøger at tilgå tjenesteudbyderens beskyttede website. På proxy serveren vil brugeren autenti-ficere sig med brugernavn samt password for derpå at få udstedt en assurance level 2 SAML as-sertion, for derefter at blive redirected tilbage til TU websitet. Her vil tjenesteudbyderen skulle tjekke, at den pågældende brugers SAML token er level 2. Da autentifikationsniveauet, som i N5, er sænket fra 3 til 2 bør signeringsoperationer ikke tilla-des, da tjenesteudbyderen ikke har en høj nok grad af sikkerhed for brugerens autenticitet. 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 al kommunikation med level 2 log-in-serveren af proxy serveren og perimeteren er derfor reduceret til denne.

5


Opret bruger

Figur 2: Web proxy med assurance level 2

Løsningen opfylder alle tekniske kriterier og er teknisk set mulig på alle tre platforme. Level 2 databasen kan genbruges af N5. Løsningen kan understøtte kommunikation med brug af OIOSAML, og der vil være single sign-on mellem offentlige tjenester. Omfanget af genbrug af dele af NemLog-in-infrastrukturen vil af-hænge af en vurdering af, hvad man vil tillade under assurance level 2. Signering bør ikke tilla-des. grundet det lavere sikkerhedsniveau, hvilket netop er affødt af, at man ikke kan sikre bruge-rens autenticitet på et tilstrækkeligt niveau. Sikkerhedsmæssigt er det væsentligste forhold (som i W4 modellen), at i løsningen er proxy-serveren skudt ind mellem brugeren og level 2 log-in-serveren. Det øger risikoen for phishing og lignende. En ondsindet part vil kunne ”lægge sig foran” web proxy’ens hjemmeside og præsente-re en tilsvarende hjemmeside lig den rigtige hjemmeside på web proxy’en. Herefter kan den ond-sindede part overvåge, og potentielt manipulere, alle interaktioner mellem brugeren og den rigti-ge hjemmeside, som derved åbner muligheden for et realtime phishing-angreb. Angrebstyper Jaibreaking / Rooting: HTML har ikke adgang til filsystemet. Det er derfor ikke muligt at de-tektere et jailbreak. Phishing: Det er muligt at lave et website, der imiterer den officielle level 2 log-in side og som sender brugeren omkring en modstanders server. Alle de identificerede tiltag (hemmeligt bille-de, hemmeligt spørgsmål etc.) til at imødegå truslen er dog understøttet. Det ydermere muligt at lave en native app som wrapper den officielle level 2 log-in proxy side, som derved kan af-lytte akkreditiverne, og følgelig kompromittere brugerens autenticitet. Skaden er dog begræn-set grundet valget af assurance level 2 adgangen (hvis der er sammenfald mellem brugernavn og password i denne løsning og NemID på PC platformen, ville dette til dels kompromittere sik-kerheden i sidstnævnte løsning. Dog skal en hacker stadig kompromittere OTP spørgsmål/svar for at udnytte informationer til egen vinding). Man-in-the-browser: Kan kun til dels imødegås ved at standse download fra browsere, der

6


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 level 2 log-in proxy ser-veren hackes, hvilket betragtes som værende et urealistisk scenarie. Level 2 log-in proxy ser-veren skal dog sikres med alle mulige tiltag, da den vil være et værdifuldt mål. Sikkerhedskriterier Sikkerhedsniveau som på PC: Sikkerhedsniveauet er lavere end på PC versionen, idet der opereres med assurance level 2 for brugerens autenticitet. Dette er dog et bevidst valg og mu-liggør – i og med at tjenesteudbyderen begrænser hvilke data og operationer der tillades – at proxy løsningen kan anvendes. NemID Autenticitet(Level 2 log-in server autenticitet): Se ovenfor samt afsnittet om phishing. Privacy af signerede data: Signering af data bør ikke tillades i denne model, da tjenesteud-byderens sikkerhed for brugerens autenticitet ikke er høj nok (assurance level 2). 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. Konsekvensen vil være lille, da risikoen for at kompromittere en borgers data kun vedrører level 2 data. Sandsynlighed Konsekvens Mitigering Samlet risikovur-

dering Web proxy med assur-ance level 2

Mellem Lille Begrænset adgang til sensitive informationer og service Governance ift tjeneste-udbydere

Sikker ift authen-tification level 2

Konklusionen er, at løsningen er teknisk mulig på alle tre operativsystemer og ikke lider af grave-rende sikkerhedsmæssige udfordringer. Da autentifikationsniveauet i denne variant er sænket fra 3 til 2 er der dog begrænsninger på, hvilke data og operationer der kan anvendes mobil. Løsningen er attraktiv, da den genbruger NemLog-in infrastrukturen og understøtter single sign-on med SAML level 2. Løsningen indgår på den baggrund i den videre analyse.

3.6 Fælles app med indlejret statisk bibliotek og intern browser Denne model (ligesom H1 model i hoveddokumentet) anvender et indlejret bibliotek til at håndte-re NemID logikken, og henter derpå websider via en indlejret browserkomponent. Løsningen kan understøtte kommunikation med NemLog-in og brug af OIOSAML, incl signering og afgivelse af fuldmagt. Modellen forsøger at adressere en væsentligt sikkerhedsmæssig udfordring, der er i H1. I H1 mo-dellen skal alle TU’er indlejre biblioteket, som derpå er sårbart overfor reverse engineering, og den indlejrede browser gør det i praksis umuligt for slutbrugeren at verificere webstedets auten-ticitet. H1 modellen er derfor meget sårbar overfor phishing. Denne risiko mindskes med én central applikation, der skal hentes af slutbrugeren for alle de websites, der skal tilgå NemID:

7


1) slutbrugeren henter én gang for alle en ”NemID” applikation, og kan under installationen verificere, at applikationen kommer fra NemID udbyderen.

2) indholdet af applikationen er certificeret af NemID applikationen og slutbrugeren kan der-for være tryg i relation til autenticiteten af de websites, der tilgås.

Måden hvorpå brugeren tilgår websites via denne løsning kan realiseres på flere måder. I over-ordnede træk kan man enten indlejre en portal (selvstændig hjemmeside), som herefter linker videre til de tjenesteudbydere, som er udvalgt til at være en del af løsningen, eller man ville kunne ”indbage” links til tjenesteudbyderne direkte i app’en. Hvis man vælger at lade brugeren indtaste vilkårlige URL’er som en led i at kunne tilgå vilkårlige tjenester, er muligheden for at en ondsindet tjenesteudbyder kan lave et website, der imiterer den officielle level 2 login side, og som brugeren kunne snydes til at tilgå dog blevet langt større. Alle de identificerede mitige-ringstiltag er dog understøttede. Portalløsningen åbner dog op for en oplagt phishing mulighed. Den giver mulighed for at lokke brugeren over på en ondsindet side, som herefter kan udnyttes til at gennemføre et phishing an-greb. Denne sårbarhed er således knyttet til anvendelse af en portal og ikke til den mobile an-vendelse. I modellen med ”indbagning” af links introduceres et yderligere vedligeholdelses- og opdateringskrav, da en ændring af listen over tjenesteudbydere, kræver en opdatering af selve app’en. Der er varianter af disse to løsninger, som kan undersøges i forbindelse med implementeringen. Man kunne f. eks. i relation til sidstnævnte model dynamisk generere links i app’en og i relation til portalløsningen ville man kunne introducere en whiteliste af tjenesteudbydere, som app’en kunne benytte i relation til at tjekke godkendte links og sites. Løsningen er vist på figuren nedenfor. Den røde ramme angiver den del af løsningen indenfor hvilken fuld tillid (trust) er påkrævet. I og med at biblioteket indlejres i en applikation, som kon-trolleres af NemID udbyderen er app’en dermed også indlemmet i sikkerhedsperimeteren.

Figur 3: Fælles app med indlejret statisk bibliotek og intern browser

Løsningen er teknisk mulig og har samme sikkerhedsniveau som NemID på PC. Løsningen kan understøtte brug af OIOSAML og kommunikation med NemLog-in som i PC-løsningen. Der vil være single sing-on mellem tjenester i app'en. Angrebstyper Jailbreaking / Rooting: Et jailbreak kan detekteres (dog ikke med 100% garanti).

8


Phishing: Det er muligt at lave en app, der opfører sig som NemID applikationen, men alle de identificerede mitigeringstiltag er understøttede. Man-in-the-browser: Det er muligt til dels at sikre, at det kun er den NemID indlejrede brow-ser, der kan tilgå websites. 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: Der kan sættes en række mitigeringer op for at begrænse muligheden for kode manipulation. Det vil altid være muligt at lave reverse engineering af en app, men det vil være tæt på umuligt at lave en digital signeret udgave af den hackede version, hvilket kan udnyttes i kommunikationen med serveren til at forhindre uautoriserede versioner af app’en at kommunikere med backend. Sikkerhedskriterier Sikkerhedsniveau som på PC: Idet applikationens autenticitet under download kan verificeres af slutbrugeren, og da der kun er én NemID app, som derpå giver adgang til et veldefineret sæt af tjenester, er de sikkerhedsproblemer som H1 lider af ikke til stede. Det vurderes derfor, at sikkerhedsniveauet, betinget af de beskrevne begrænsninger, for denne løsning er som i PC ver-sionen. NemID Autenticitet: Se ovenfor. Privacy af signerede data: NemID biblioteket kan beskytte data lokalt på telefonen inden det sendes videre. Risikoanalyse Det er vurderingen, at sandsynligheden for, at et angreb omgår de anbefalede mitigeringer, er på lavtniveau (1-2 angreb over de kommende tre år), og at konsekvensen uden yderligere tiltag for risikominimering vil være mellem, dvs. at der vil være en risiko for at kompromittere en borgers data.

Sandsynlighed Konsekvens Mitigering Samlet risiko-vurdering

Fælles central app med indlej-ret statisk bib-liotek og intern browser

Lav Mellem Applikationen gi-ver adgang til veldefineret sæt af tjenester

Sikker for veldefine-ret sæt af tjenester

Konklusionen er, at løsningen er teknisk mulig på alle 3 platforme og er sikker for et veldefineret sæt af tjenester på niveau med NemID på PC’er. Løsningen indgår på den baggrund i den videre analyse.

3.7 Opsamling på teknisk og sikkerhedsmæssig vurdering Opsamlingen på den tekniske og sikkerhedsmæssige vurdering er, at de to level 2 løsninger er sikre målt ud fra kravene til dette sikkerhedsniveau. Den fælles app er sikker på niveau med NemID på PC’er. Teknisk

vurdering Risiko-vurdering OIOSAML Single

sign-on N5: Native app med as-surance level 2

� Sikker ift. authenti-fication level 2

W5: Web proxy med as-surance level 2

� Sikker ift. authenti-fication level 2

� �

H5: Fælles central app med indlejret statisk bibli-otek og intern browser

� Sikker � � *

9


* Note: For H5 afhænger single sign-on funktionalitet af, hvordan app'en implementeres. Der er single sign-

on i app-konteksten.

OIOSAML kan understøttes af web proxy level 2 (W5) og fælles app (H5). Single sign-on funktio-nalitet understøttes fuldt ud i web proxy mellem level 2 tjenester. Afgivelse af fuldmagt under-støttes ikke. I fælles app understøttes single sign-on mellem tjenester i samme app. Det vil være muligt at etablere level 2 løsningerne med integration til NemID, således at bruger-navn og password fra NemID kan anvendes, svarende til bankernes Konto-kig-løsninger. Det vil være en brugervenlig løsning, da brugeren så ikke skal skabe og huske nyt brugernavn og pass-word. Sikkerheden vil dog blive styrket ved at etablere level 2 løsningerne helt dekoblet fra Ne-mID, således at NemID ikke kan kompromitteres ved at skaffe sig adgang til brugernavn og password ved at hacke level 2 løsningerne. Teknisk deler native app level 2 og web proxy level 2 teknologi. Det betyder, at Digitaliserings-styrelsen kan vælge at starte med web proxy og senere sørge for udvikling af et level 2 bibliotek, der kan kommunikere med web proxyens database.

3.8 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. I kraft af den lavere sikkerhed for brugerens autenticitet anbefales det ikke at understøtte signe-ring på assurance level 2. Signering understøttes således kun af H5. 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.

4. 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 med udgangspunkt i Rambølls generelle erfaringer og dialog med leverandører i markedet. Der er til den supplerende undersøgelse indhentet yderligere oplysninger om omkostninger, herunder er NNIT (eksisterende leverandør af NemLog-in infrastruktur) blevet bedt om at bidrage med information.

4.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.

4.1.1 Native app med assurance level 2 I denne løsning indgår følgende fælles komponenter

• En aktiveringsdel med brugergrænseflade og database • Et statisk indlejret level2 bibliotek, som tjenesteudbyderne skal indbygge i deres apps

Tjenesteudbyderne skal sørge for følgende

• En app, hvor level2 biblioteket indlejres • Snitflader i backend-app til sikkerhed og indhold • Tilpasning af tjenester (services og indhold/data) til assurance level2

10


Applikation

Statisk indlejret

Level2 bibliotek

Telefon

Level2 database

N5

BrugOpret

DanID

Log-in

Opret bruger

Tjeneste hvor bruger

aktiverer

mobil adgang

NemID

applet

Tjenesteudbyder

REST/SOAP

interface

Sikkerhed

interface

Statisk indlejret

Level2 bibliotekStatisk indlejret

NemID bibliotekFælles

komponent

Statisk indlejret

NemID bibliotek

Tjenesteyder

komponent

Level2 database

Tilpas data

Level 2

Figur 4: N5 Omkostningskomponenter

4.1.2 Web proxy med assurance level 2

I denne løsning indgår følgende fælles komponenter • En aktiveringsdel med brugergrænseflade og database • En mobil log-in side

Tjenesteudbyderne skal gennemgå deres tjenester. Hvis de ønsker at udstille dem på mobile si-der med level 2, skal de sikre, at indholdet svarer hertil.

Browser

Telefon

Level2 database

W5

BrugOpret

DanID

Log-in

Opret bruger

Tjeneste hvor bruger

aktiverer

mobil adgang

NemID

applet

Statisk indlejret

NemID bibliotekFælles

komponent

Statisk indlejret

NemID bibliotek

Tjenesteyder

komponent

Level2 database

Tilpas data

Level 2

Tjenesteudbyder

HTTP

OIOSAML

Figur 5: W5 komponenter

Modellen tillader brug af den eksisterende NemLog-in infrastruktur og tilvejebringer single sign-on funktionalitet ved at udstille flere services i browseren.

11


4.1.3 Fælles central app – Indlejret statisk bibliotek og intern browser I løsningen skal Digitaliseringsstyrelsen sørge for, at der udvikles én fælles app med et statisk NemID bibliotek til de understøttede operativsystemer, som efter en succesfuld log-in skal inde-holde mulighed for at tilgå tjenesteudbydernes services gennem en wrapper til indlejret browser. Tjenesteudbyderne skal alene tilpasse design i deres eksisterende services til en mobil web versi-on. Denne omkostning indgår ikke i beregningerne. Der skal ikke i øvrigt ske ændring i de tilbud-te services og indhold, da man fastholder assurance level 3 i denne model.

Figur 6: Komponenter i Statisk indlejret NemID bibliotek og hybrid

Modellen tillader brug af den eksisterende NemLog-in infrastruktur og tilvejebringer single sign-on funktionalitet til de services, der er adgang til i en indlejret browser.

4.2 Omkostninger

4.2.1 Digitaliseringsstyrelsens omkostninger til etablering og drift af databasesystem til aktivering af assurance level2. Disse omkostninger indgår i model N5 og W5. Løsningen består af en registreringsside, hvor brugeren loggen ind med NemLog-in på en PC og opretter en mobil-profil med brugernavn og password. Løsningen kvalitetssikrer brugernavn og password (entydigt brugernavn og tilstrækkeligt sikkert password). Løsningen skal håndtere ændring af password, fornyelse efter f. eks. 1 eller 2 år, og blokering ved for mange forkert indtastede passwords samt genåbning. Til løsningen skal der etableres en support-ordning til at håndtere blokering, genåbning, besva-relse af spørgsmål, udstedelse af nye akkreditiver mv. Data gemmes i en sikker database med højt sikkerhedsniveau, da der håndteres brugerakkrediti-ver til flere tjenester. Databasen skal kunne tilgås fra den app, der er beskrevet i N5 eller fra en mobil log-in-side, som beskrevet i W5.

12


En mulig leverandør er NNIT, som kan levere løsningen som en mindre udvidelse af NemLog-in infrastrukturen. Løsningen kan navngives og brandes som del af NemLog-in eller med selvstæn-digt brand. De samlede omkostninger til aktivering med database skønnes med test at koste 1-2 mio. kr. og 20-30 % heraf i årlig drift. Skønnet bygger på et overslag fra NNIT (det lave skøn) og tillagt eks-tra hardware og yderligere funktionalitet (det høje skøn).

4.2.2 Digitaliseringsstyrelsens omkostninger til assurance level 2 mobil log-in side Disse omkostninger indgår i model W5. Løsningen består af en mobil log-in side, der er designet til visning på mobile enheder i en mobil web browser. Siden tillader log-in med brugernavn og password. Løsningen udsteder OIOSAML-tokens med personidentifikation og med assurance level 2. Løsningen har sikkerhedsfunktioner, så der foretages blokering af bruger ved f.eks. 3 forkerte indtastninger af password. Da denne løsning er serverbaseret, vil den være robust over for ændringer i de mobile operativ-systemer. Da ændringer kun skal opdateres på den centrale server, vil de desuden være lettere at opdatere løbende, og det vil mindske krav til test. Det betyder lavere vedligeholdelsesomkost-ninger end de app-baserede løsninger. De samlede omkostninger til mobil log-in side skønnes med test at koste 3-5 mio. kr. og 20-25 % heraf i årlig drift. Skønnet bygger på et overslag fra NNIT (det lave skøn) og tillagt ekstra hardware og yderligere funktionalitet (det høje skøn). Såfremt der vælges en anden udbyder, skal tallene tillægges et millionbeløb til etablering af sikker infrastruktur.

4.2.3 Digitaliseringsstyrelsens omkostninger til native app med assurance level 2 Disse omkostninger indgår i model N5. Denne komponent består af de kodeelementer, der styrer brugergrænsefladen til log-in med brug af level2 databasen med akkreditiver, som brugeren har oprettet i aktivering af den mobile løs-ning. Det forudsættes, at det er Digitaliseringsstyrelsen, der er ejer af koden/app’en. De centrale omkostninger til drift vil omfatte:

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

Da der forventes forandringer i markedet for mobile operativsystemer med mulige nye spillere og nye versioner, vil der samtidig være behov for udvikling og implementering 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. Omkostningen til udvikling af koden til tre operativsystemer inkl. testforløb skønnes at være 4-6 mio. kr. Der er flere leverandører, der har leveret tilsvarende løsninger (e-Boks).

4.2.4 Digitaliseringsstyrelsens omkostninger til fælles central app Disse omkostninger indgår i model H5. Løsningen med en fælles app med statisk indlejret NemID bibliotek vil dels kræve udvikling af statisk indlejret NemID-bibliotek, dels udvikling og løbende tilpasning af præsentation af de tje-nester, app'en giver adgang til. En fælles app skal præsentere de inkluderede tjenester i et bru-gervenligt design. Da der kan forventes en løbende tilpasning af, hvilke tjenester, der skal indgå i app'en, skal der afsættes midler til denne løbende tilpasning. Der forudsættes at det er Digitaliseringsstyrelsen der er ejer af app’en.

13


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. Der er omkostninger til udvikling af koden inkl. test. Hertil skal lægges udgifter til at håndtere browserkald. Det kan ske ved statisk indlejring i koden eller ved at der kaldes dynamisk indhold fra en webside. Da koden ikke skal distribueres til flere udviklere, vil omkostningerne til hærd-ning af koden være mindre. Den samlede omkostning skønnes at være 14-20 mio. kr. 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.

4.2.5 Digitaliseringsstyrelsens omkostninger til DanIDs snitflade og back-end Disse omkostninger er relevante for model H5. 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 være 6-9 mio. kr.

4.2.6 Digitaliseringsstyrelsens samlede omkostninger Oversigten viser Digitaliseringsstyrelsens omkostninger i de tre løsningsvarianter.

Tabel 1: Oversigt over Digitaliseringsstyrelsens samlede omkostninger

Omkostninger Digitaliseringsstyrelsen i alt

Native app med assurance level 2 • App • Level2 aktivering • I alt

4-6 mio. kr. 1-2 mio. kr. 5-8 mio. kr.

Web proxy med assurance level 2 • Level2 aktivering • Log-in • I alt

1-2 mio. kr. 3-5 mio. kr. 4-7 mio. kr.

Fælles central app med indlejret statisk bibliotek og intern browser

• App • DanID backend • I alt

14-20 mio. kr. 6-9 mio. kr.

20-29 mio. kr.

4.2.7 Tjenesteudbydernes omkostninger til native app Disse omkostninger er relevante for model N5. I N5 skal tjenesteudbyderen udvikle og distribuere en app, hvor der indlejres level2-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.

14


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.). Tilpasning af indhold til level 2 er indeholdt i dette. 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.

4.2.8 Tjenesteudbydernes omkostninger til tilpasning til level2 Disse omkostninger er relevante for model W5. Ved introduktion af log-in med assurance level 2 skal tjenesteudbyderne udføre en række opga-ver. Alle løsninger med log-in skal gennemgås for at klarlægge om indholdet kræver level 2 eller 3, og om det kan tilpasses til level 2. Desuden skal tjenesteudbyderne sikre, at de har implementeret kontrol af assurance level i OIOSAML-token. Dette indgår som et krav i vilkårene for tilslutning til NemLog-in, men der er en risiko for, at dette ikke er sket, og introduktion af assurance level 2 i NemLog-in vil derfor kræve en kontrol. Opgaven vil kræve, at alle tjenesteudbydere gennemgår tjenesterne. Det forventes at tage 10-20 timer i gennemsnit pr løsning, i alt 1-2 mio. kr. for de godt 200 tjenester tilsluttet NemLog-in. For nogen tjenester vil det vise sig, at de skal ændre dataindhold og/eller snitflader for at leve op til kravet om at tjekke assurance level. Omkostningen vil variere, men med test og kontrol vur-deres det at koste 50.000-100.000 for anslået 20 løsninger, i alt 1-2 mio. kr. Alternativt kan der etableres en whitelist i forbindelse med level 2 mobil log-in side til ½-1 mio. kr. Brugere, der surfer på offentlige hjemmesider, skal kunne se relevante links til mobil log-in, på samme måde som der er links til log-in med NemID. Tilpasning af hjemmesider (som Brøndbys vist herunder) vil kræve 1-2 mio kr.

Figur 7: Selvbetjening på brondby.dk

De samlede udgifter til tilpasning til assurance level 2 skønnes at være 3-6 mio. kr. Det indebæ-rer også udgifter for tjenester, der ikke vil anvende mobil log-in, med mindre der etableres en whitelist.

15


4.2.9 Tjenesteudbydernes omkostninger i forbindelse med fælles app Dette er relevant for model H5. Da den fælles app understøtter assurance level 3, kan den teknisk set anvendes på nuværende tjenester. I praksis skal tjenesteudbyderne tilpasse design til mobile enheder, men dette indgår ikke i omkostningsberegningen.

4.2.10 Tjenesteudbydernes samlede omkostninger Tjenesteudbydernes samlede omkostninger afhænger dels af den enkelte tjenesteyders omkost-ninger, dels antallet af tjenesteudbydere, der vil anvende løsningen. 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. Det vurderes til omkostningsberegningen, at 30 tjenester vil implementere den dyre native app-løsning (N5).

Tabel 2: Oversigt over tjenesteudbydernes omkostninger

Antal tje-nesteud-bydere skønnet

Omkostning pr tjenesteudbydere

Omkostninger tjeneste-udbydere i alt

Native app med assur-ance level 2

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

Web proxy med assur-ance level 2

- - 3-6 mio. Kr.


- - -

4.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.

Tabel 3: Oversigt over omkostninger

Fælles omkost-ninger

Omkostninger tjenesteudbydere

Samlede omkost-ninger for det of-

fentlige Native app med assur-ance level 2 (app og Lev-el2 aktivering)

5-8 mio 15-30 mio 20-38 mio

Web proxy med assur-ance level 2 (Level2 akti-vering og log-in)

4-7 mio 3-6 mio 7-13 mio

Fælles central app med indlejret statisk bibliotek og intern browser (app og DanID backend)

20-29 mio - 20-29 mio

Oversigten over omkostninger viser, at de to løsninger med assurance level2 vil betyde udgifter for tjenesteudbyderne, mens den fælles app kan etableres uden udgifter. Til gengæld vil den fæl-les app være dyrest i fælles omkostninger. Alle tre løsninger vil medføre omkostninger til eventu-elle tilretninger af design til mobile enheder. Der er tale om store omkostninger til de fælles komponenter i forhold til almindelige tjenester. Det skyldes, at kravene til sikkerhed er meget høje, og at det kræver en stor indsats at afdække hele viften af sårbarheder, finde mitigeringer samt at gennemføre udtømmende tests for at sikre,

16


at løsningen lever op til de stillede krav. Hertil kommer at med højere sikkerhed stiger udgifterne til ekstern kontrol (f. eks. revisorkontrol) af softwareudvikling, installation og drift. Da apps des-uden skal distribueres og kun vanskeligt kan opdateres, er der store omkostninger til kvalitets-kontrol inden distribution.

5. BRUGERVENLIGHED

Hovedrapportens generelle observationer om brugervenlighed gælder også for de tre undersøgte.

5.1 Er løsningen let at lære og let at huske Det er en forudsætning for den fælles app (H5), at brugerne kan genkende indtastningsbilledet til NemID på PC (appletten). Det giver genkendelighed og bidrager til sikkerheden, at brugerne har mulighed for at skelne mellem et ægte og falsk indtastningsbillede. For level 2 løsningerne gælder, at de adskiller sig fra PC-løsningen, og at brugeren derfor skal lære en ny løsning at kende. Desuden skal brugeren aktivere den mobile løsning og vælge bru-gernavn og password. For både native app level 2 (N5) og fælles app (H5) gælder, at der skal downloades en app, hvor web proxy løsning (W5) er umiddelbart tilgængelig via en browser. Brugernes forudsætninger og situation har betydning for hans opfattelse af brugervenligheden, og det er derfor den generelle vurdering, at alle tre løsninger er lette at lære og huske.

5.2 Er løsningen effektiv at bruge Apps kræver et ekstra trin til download af app. De to assurance level 2 løsninger (N5 og W5) kræver aktivering, og at brugeren skal skabe og huske ekstra brugernavn/password. Desuden er de begrænsede i, hvilke tjenester, de giver ad-gang til, og hvilke funktioner, der kan udføres (der kan ikke signeres). I den daglige brug vil løsningen dog kunne opfattes som lettere at bruge, da der ikke skal anven-des nøglekort. Den samlede vurdering af effektivitet vil afhænge af brugerens situation. For nogle brugere vil begrænsningerne ikke være et problem, mens det for andre vil være en ulempe. Samlet set vur-deres løsningerne derfor alle at være effektive at bruge.

5.3 Er løsningen rar at bruge Den fælles app (H5) anvender samme brugervenlige indtastningsbillede som NemID. For level 2 løsningerne (N5 og W5) kan der designes et indtastningsbillede med samme niveau af brugervenlighed. For at sikre, at level 2 løsningerne har den ønskede brugervenlighed og tilgængelighed skal der ved implementeringen gennemføres usability tests, hvor brugervenlighed og tilgængelighed vur-deres systematisk og i forhold til de forventede brugergruppers færdigheder. På den baggrund vurderes løsningerne at have samme niveau.

5.4 Tilgængelighed 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.

17


5.5 Samlet vurdering

Tabel 4: Brugervenlighed

Let at læ-re/huske

Effektiv at bruge

Rar at bruge

Tilgæn-gelighed

Samlet vurde-ring

Native app med assur-ance level 2

Ja Ja Ja Ok God

Web proxy med assur-ance level 2

Ja Ja Ja Ok God

Fælles central app med indlejret statisk biblio-tek og intern browser

Ja Ja Ja OK God

De to level 2 løsninger har marginalt lavere brugervenlighed på grundlag af det ekstra trin med aktivering.

6. DÆKNING AF PRIVATE TJENESTEUDBYDERE

Native app med assurance level 2 (N5) kan anvendes af private tjenesteudbydere, såfremt akti-veringsløsningen også stilles til rådighed for privat anvendelse. Løsningen indebærer, at hver tje-nesteudbyder laver egen app, og private kan derfor opnå de markedsføringsmæssige gevinster herved. Web proxy med assurance level 2 (W5) kan teknisk set bruges af private. Her skal både aktive-ringsdelen og log-in-delen stilles til rådighed. For begge løsninger gælder, at de fællesoffentlige komponenter skal stilles til rådighed for priva-te. I NemLog-in sammenhæng har dette spørgsmål været drøftet, men der er ikke fundet en af-klaring af, om det er ønskeligt og muligt. Fælles central app (H5) vil principielt også kunne anvendes af private tjenesteudbydere. Der skal i så fald afklares governance af sådan en app, herunder ikke mindst dens finansiering, ejerskab og styring.

Tabel 5: Dækning af private tjenesteudbydere

Dækning af private tjenesteudbydere

Native app med assurance level 2

Teknisk mulig

Web proxy med assurance level 2

Kan tilbydes private i forhold til aktivering – om der kan trækkes log-in kræver afklaring ifht NemLog-in for private eller om løsningen kører separat


Svarer til bankernes fælles løsning Kan teknisk set tilbydes private

Samlet gælder, at det er teknisk muligt at tilbyde løsningerne til private tjenesteudbydere, men at der er en række juridiske, kommercielle og governancemæssige forhold, der skal afklares.

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

For de to løsninger med assurance level 2 (N5 og W5) er det er bevidst valg, at de ikke følger OCES-standarden men har et lavere sikkerhedsniveau. Det medfører et behov for at afklare, hvil-ke af det offentliges tjenester, der har sikkerhedskrav, der kan løses af dette assurance level.

18


Fællesoffentligt vil der være behov for fortolkninger af regler og retningslinjer for den enkelte tjenesteudbyders arbejde med at afklare valg af assurance level og behovet for tilpasninger af de enkelte løsninger. I mange tilfælde vil tjenesteudbydernes analyse være på detaljeret niveau i forhold til tjenestens enkelte felter. Behovet for fortolkninger og retningslinjer skal ses i lyset af, at myndighederne gennem mange år kun har skullet forholde sig til NemID (og digital signatur). Kan level 2 løsninger f. eks. anvendes til at indberette helbredsoplysninger som måleresultater fra telemedicinsk udstyr? Falder det ind under Persondatalovens §7 om følsomme data eller er måleresultater dækket af §6? Tjenesteudbyderne skal også forholde sig til, om indberetninger og ansøgninger af forskellig art som Skat og boligstøtte kan dækkes af level 2 uden signering. Hvis sikkerheden i løsningen øges ved kun at dække tjenester på en whitelist, skal f. eks. Digita-liseringsstyrelsen vedligeholde en whitelist. Det kan ske på grundlag af borger.dk's OPIS-løsning. Den fælles app (H5) vil også kræve fælles indsats til løbende at registrere de løsninger, der dæk-kes af app'en og afklare uoverensstemmelser mellem myndigheder om deltagelse og placering. Der kan også blive behov for at gøre indholdet ensartet på tværs af tjenester, fordi indholdet nu præsenteres i en fælles løsning. For tjenesteudbyderne vil denne løsning betyde, at deres time-to-market vil være afhængig af Digitaliseringsstyrelsens beslutninger. Den fælles app vil desuden kræve en tæt opfølgning fra Digitaliseringsstyrelsen for at fastholde høj sikkerhed i samarbejde med DanID. I alle tre løsninger kan der blive behov for at styre sammenhænge og brugervenlighed på tværs. Dette behov vurderes dog at være størst for den fælles app.

8. KONSEKVENSER I FORHOLD TIL KONTRAKT OG UDBUD

Til native app med assurance level 2 (N5) skal der dels udvikles en app, dels en level 2 aktive-ringsløsning. App'en er hverken del af DanIDs eller NNITs infrastruktur, og den forventes at have en pris, så den skal i EU-udbud. Level 2 aktiveringen er også en del af web proxy med assurance level 2 (W5), hvor der også skal udvikles en log-in side. Begge komponenter kan med fordel udvikles og drives som del af Nem-Log-in infrastrukturen. Baggrunden for det er, at løsningen skal have høj sikkerhed, som vil kun-ne opnås billigere ved, at den bygger på sikkerheden i NemLog-in. Det vil desuden være en for-del for tjenesteudbyderne, at OIOSAML-tokens udstedes af samme udbyder som NemLog-in. Vælges en anden udbyder skal tjenesteudbyderne tilpasse deres løsninger til to udbydere af SAML-tokens med certifikathåndtering mv. Løsningen vurderes at kunne løses af NNIT som en del af kontrakten for NemLog-in. Fælles central app med indlejret statisk bibliotek og intern browser (H5) kræver dels udvikling af den fælles app, dels tilretning i DanIDs infrastruktur. Sidstnævnte kan dækkes af kontrakten med DanID. Udvikling af den fælles app er ikke dækket af kontrakterne og skal i EU-udbud.

19


Tabel 6: Udviklingsopgaveplacering

Teknisk vurdering af opgave-placering

Udbudsvurdering

Level 2 app (N5) 3. parts leverandør Kræver udbud Level 2 aktivering og log-in

NNIT Dækket af kontrakten med NNIT

Fælles app (H5) • 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

På den baggrund kan det konkluderes, at web proxy level 2 (W5) kan gennemføres uden udbud, mens de to andre løsninger kræver EU-udbud.

9. PROJEKTRISICI

En faktor i vurderingen af løsningsvarianterne er, hvor hurtigt de kan gennemføres. Her indgår det foregående afsnits vurdering af, om der skal gennemføres EU-udbud.

9.1 Løsningernes tekniske robusthed, performance og modenhed Både native app level 2 (N5) og web proxy level 2 (W5) bygger på velkendte teknologier med stor modenhed. Løsningen ”Statisk indlejret NemID-bibliotek” er udviklet til bankerne, og der er dermed erfaring med løsningen og dens samspil med NemID. Bankerne har udviklet native apps til alle tre operativsystemer. Disse erfaringer kan anvendes på den fælles hybride app.

9.2 Projekt- og tidsplan Da web proxy level 2 (W5) ikke skal i udbud og da den bygger på modne teknologier, er det vur-deringen, at den kan etableres i 2012. For de to øvrige løsninger er der krav om EU-udbud, hvilket betyder, at løsningerne først vil kun-ne etableres i 2013.

9.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?

20


Tabel 7: 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

Alle Middel Stor 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

Alle Middel Middel Valg af løsning

4 De grundlæggende teknologier (herunder operativsystemer) ændres, således at løsningen kræver sto-re vedligeholdelses-omkostninger.

N5 og H5 W5

Høj (N5 og H5 er operativsy-stemafhængi-ge) Lav (W5 er ikke operativsy-stemafhæn-gig, er baseret på HTML og kan gennem-føres hurtige-re)

Stor Lille

Forudseenhed i design og høj grad af modula-ritet Som N5 og H5

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

9.4 Vurdering i forhold til tidsplan og projektrisici

Tabel 8: Tidsplan og projektrisici

Tidsplan Projektrisici


2013 Ikke tilfredsstillende





10. SAMLET VURDERING

Den supplerende analyse har opstillet og vurderet yderligere 3 løsningsvarianter inden for tre grundlæggende løsningsdesigns. Det ene løsningsdesign baserer sig på native apps, det andet på web apps, mens det tredje kombinerer de to veje i en hybrid løsning. De to varianter adskiller sig ved at bygge på et lavere sikkerhedsniveau, nemlig assurance level 2, hvilket betyder, at de kun kan anvendes til tjenester, hvis krav til sikkerhed kan dækkes af le-vel 2. Den tredje variant implementerer NemID på mobile enheder med samme sikkerhedsniveau som på PC'er, men adskiller sig ved at koble tjenester og sikkerhed i samme app. Sikkerheden i de to løsninger på level 2 lever op til de stillede krav og er derfor god i forhold til denne præmis. Sikkerheden i den fælles app (H5) er svarende til PC-løsningen.

21


De tre 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. Oversigten over omkostninger viser, at løsningen med native app vil blive dyr for tjenesteudby-derne. For den enkelte tjenesteudbyder er der omkostninger på ½-1 mio. kr., hvilket kan betyde, at et begrænset antal tjenesteudbydere vil anvende løsningen. Web proxy level 2 vil have lavere omkostninger for tjenesteudbyderne, mens fælles app ikke vil have omkostninger for tjenesteud-byderne. 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). Brugervenligheden i de tre varianter vil afhæn-ge meget af brugerens situation, og overordnet set er forskellene i brugervenlighed derfor små. Generelt set er brugervenligheden god i alle tre løsninger. De tre undersøgte løsninger vil teknisk set kunne tilbydes til private tjenesteudbydere. For alle løsninger gælder, at der er en række juridiske, kommercielle og governancemæssige forhold, der skal afklares. De to af løsningerne bygger på assurance level 2, hvilket betyder et behov for fortolkninger af regler og retningslinjer. Behovet for fortolkninger og retningslinjer skal ses i lyset af, at myndig-hederne gennem mange år kun har skullet forholde sig til NemID (og digital signatur). Hvis sikkerheden i løsningen øges ved kun at dække tjenester på en whitelist, skal der påregnes en opgave med vedligeholdelse af en whitelist. Den fælles app (H5) vil også kræve fælles styringsmæssig indsats til løbende at registrere de løsninger, der dækkes af app'en og afklare eventuelle forskellige synspunkter om deltagelse og placering. Der kan også blive behov for at gøre indholdet ensartet på tværs af tjenester, fordi indholdet nu præsenteres i en fælles løsning. I alle tre løsninger kan der blive behov for at styre sammenhænge og brugervenlighed på tværs. Dette behov vurderes dog at være størst for den fælles app. 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 tre løsninger består hver af flere komponenter, hvoraf nogle kan leveres inden for Digitalise-ringsstyrelsens kontrakter med DanID og NNIT. I N5 og H5 indgår der komponenter, der har en størrelse, så de skal anskaffes gennem udbud. W5 kan anskaffes under kontrakten med NNIT. 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 to af løsninger indgår komponenter, der skal an-skaffes gennem EU-udbud. Kun web proxy (W5) vil derfor kunne blive etableret inden udgangen af 2012. Den samlede vurdering af de tre løsningsvarianter er, at de alle adskiller sig fra PC-løsningen. Såfremt denne præmis accepteres, kan alle tre løsningsvarianter anvendes til log-in på mobile enheder.

22


Tabel 9: Samlet vurdering

Sikkerhed Samlet økonomi Brugervenlighed


Sikker ift. as-surance level 2

20-38 mio. kr. God


Sikker ift. assu-rance level 2

7-13 mio. kr. God

Fælles central app med ind-lejret statisk bibliotek og in-tern browser

Sikker 20-29 mio. kr. God

Signaturforklaring:

Brugervenlighed: Grøn smiley=God.

De to løsninger med assurance level 2 deler teknologi og kan ses som ét alternativ. Det vil være relevant at starte med at udvikle web proxy level 2 (W5) og senere vurdere om native app (N5) skal udvikles. Det vil give mulighed for hurtig time-to-market. Den fælles centrale app (H5) er det andet alternativ, som giver samme sikkerhed som NemID på PC.

Documents

NemID på Mobile Enheder - Appendix