NemID Signering. Diplom-IT Eksamenprojekt Kasper Poulsen

Transkript

1 NemID Signering Diplom-IT Eksamenprojekt 2010 Kasper Poulsen Studienummer: s Eksamensprojekt: NemID Signering Afsluttende eksamens nummer: IMM-B.Eng DTU vejleder: Stig Høgh (SH) Diplomingeniør retning: IT Firma: KMD A/S Afdeling: Produkt- og Konsulentforretningen

2 Danmarks Tekniske Universitet Institut for Informatik og Matematik Modellering Bygning 321, DK-2800 Kongens Lyngby, Danmark Telefon , Fax

3 Abstrakt Implementering af signeringsdelen af den ny NemID løsning fra DanID. Se: m_nemid/ Kontekst: I forbindelse med overgangen til den nye digitale signatur, NemID. Der bliver fremtidens digitale signatur, hvilket også skal være en del af NemKonto. Dette betyder for NemKonto, at deres signeringsdel nu skal tilpasses den nye Digitale Signatur. Opgave: Tilpasse NemKonto til ny signeringsapplet (client-side) Tilpasse NemKonto layout til ny signeringsapplet (client-side) Ny serverside funktionalitet til håndtering af input fra ny applet Ny XMLDSig Validering Ny signatur- valideringsservice (baseret på DanIDs toolkit) Tilpasning af den gamle digital signatur Diverse Som teknologi anvendes primært ASP Classic, samt JavaScript.

4 ii

5 FORORD Eksamensprojektet er afsluttende projekt på vores IT Diplom uddannelse på Danmarks Tekniske Universitet og er svarende til 20 ECTS points. Projektet er udført i forlængelse af ingeniørpraktik hos KMD A/S. Vejledere på projektet har været projektleder Lars Jokumsen og Kaj Henriksen fra KMD og Stig Høgh fra IMM DTU. Lyngby, 1.juli 2010 Kasper Poulsen

6 iv

7 Page 1 of 79 Indholdsfortegnelse 1 Indledning DanID Signaturgruppen A/S Planlægning Planlægning Analysen/Design Implementering Test Arbejdsindsats: Risikoanalyse Virksomheds involverede Teknologiske udfordringer Fejl-implementeringer Projekt ændringer Projektafgræsning Sygdom Data tab Delkonklusion Analyse Kravspecifikation Funktionelle krav NON-Funktionelle Krav: Succeskriterier Servermiljø Programmeringssprog ASP Classic JavaScript Sessions Signering Certifikater Personlige certifikater(gammel digital signatur) NemID personlige certifikater... 24

8 Page 2 of DanID s validerings løsning Konklusion Signaturgruppens Valideringskomponent NemID Applet med OTP step mode step mode Signeringstekst Gammel digital signatur 3-step mode signeringsflow Delkonklusion Design Sikkerhed NemID Replay attacks: Man in the middle Kommunikation Opsætning af Parametre Brugergrænseflade Signering Gammel digital signatur Den Ny Digitale signatur Validering af Certifikat (NemID) Delkonklusion Implementering Struktur Logon biblioteket Sign biblioteket Opsætningsfiler Web.Config: Global.asa Application_OnStart: Signering Certifikat Data Signering af data med NemID Opsætning af NemID applet... 49

9 Page 3 of NemID applet kommunikation Validering SignedAgreement.asp Signering med anvendelse af digital signatur Spærreliste check: Fejlhåndtering Delkonklusion Test Blackbox test Borger signerer Tekst med NemID Borger signerer tekst med Digital signatur Test af OcesUtility komponent API et: Delkonklusion Konklusion Forbedrelser: Litteraturliste Bilag Vedlagt CD Signering med Digital Signatur Oces I Test af OcesUtility API OcesUtility API beskrivelse Lanceringstilbud Fakta om NemID... 77

10 Page 4 of 79 1 Indledning Afdelingen Produkt- og konsulentforretningen I KMD A/S har i forbindelse med den ny Digitale Signatur(NemID 1 ) indgået en aftale med IT-Styrelsen, om at være med i et testforløb af signaturløsningen som DanID 2 har lavet. Den ny digitale signatur bliver skudt i luften d.1juli 2010 og her ønsker IT-Styrelsen at have så mange kommuner og offentlige services til at være klar. For at denne løsning bliver så succesfuld som muligt er der mange fra det offentlige som er med i testfasen op til d.1juli Formålet med pilotprojektet er at teste integration til NemID (dens overordnede koncept, komponenter, ydelser m.m.), inden løsningen frigives i fuld skala. Min opgave er så at få integreret NemID til NemKonto 3 systemet, og mere præcist er det for mit vedkommende, kun signeringsdelen som jeg skal tage mig af. Et kort eksempel på dette kunne være en borger der loggede ind på sin Nemkonto og ville ændre sit kontonummer, i denne forbindelse vil borgeren blive præsenteret for en tekst og blive bedt om signerer dette. At jeg så også blev tildelt opgaven omkring login senere i forløbet er så en anden del som jeg ikke vil komme ind på i dette projekt her, da det skete sent i forløbet. NemKonto systemet Frontend er baseret på ASP Classic og JavaScript, hvilket er det jeg også vil gøre brug af. Jeg står selv for integrationen og implementeringen af NemID signering, men vil have møder med min projektleder løbende, samt blive rådført af en ITarkitekt. I forbindelse med testdelen, bliver denne udført i samarbejde med en tester. Produktet er således blevet udviklet igennem metoden vandfaldsmodellen bestående af disse faser: Analyse, Design, Implementering og Test. Jeg har tænkt mig at gå i dybden og sætte mig ind i Nemkonto logon og signering, samt sætte mig ind i hele DanID s løsningsbeskrivelse af NemID. Jeg kan derefter lave en analyse af hele Nemkontos signeringsfunktionalitet og ud fra det analysere hvilke problemer og valg der må træffes, for at den nye signeringsfunktionalitet vil blive en succes. Samtidig skal Den Digital signatur vi har i dag, fungere succesfuldt i samspil med NemID de næste 2 1 NemID: DanID s løsning på den nye digitale signatur. 2 DanID: et selskab i PBS koncernen, som har vundet udbuddet på at udvikle og viderefører den nye digital signatur, de næste 5 år. 3 NemKonto: er den bankkonto, som alle offentlige myndigheder bruger, når de skal overføre penge til en borger.

11 Page 5 of 79 år frem. Herefter vil selve designet af signeringsfunktionalitet blive beskrevet, efterfulgt af implementering og test. Da jeg oprindeligt ikke skulle være på login delen skyldes dette at den var tildelt nogen andre, dette forløb dog ikke planlagt og 1,5 måned henne i forløbet, besluttede vi, at hvis vi skulle nå både login og signering måtte vi ud og hente en Valideringskomponent, som vil blive beskrevet senere. Rapporten er blevet delt op i hovedafsnit således: -Indledning Indeholder en introduktion til projektet. -Planlægning Beskriver hvilke arbejdsmetoder der er brugt, samt en tidsplan for projektet og en risikoanalyse af projektet. -Analyse Der findes her en kravspecifikation for projektet og hvilke valg der er truffet før implementeringen. -Design Denne del forklarer hvordan projektet fungerer og hvordan det hele er bygget op. -Implementering Denne del beskriver hvordan projektet er sat sammen og hvordan alle de nye funktioner fungerer, opsætningen og strukturen. -Test Der bliver her konstateret om den nye funktionalitet er i orden vha. Black Box test. -Konklusion Der vil her blive sammenfattet alle mål som er nået i dette projekt og eventuelle tilbageværende problemer. -Litteraturliste Indeholder henvisninger til de kilder som er blevet brugt til projektet. -Bilag Indeholder relevante dokumenter, som der er henvisninger til, som ikke er medtaget i rapporten. 1.1 DanID Kort om DanID: Et selskab i PBS koncernen Udpeget af videnskabsministeriet til at udvikle og viderefører den Digitale Signatur de næste 5 år

12 Page 6 of 79 Ansvar for at udvikle og drive den nye fælles netbank sikkerhed Overtaget TDC s digital Signatur forretning Får omkring 1 milliard for udvikling af den nye digitale signatur og vedligeholdelse de næste 5 år 1.2 Signaturgruppen A/S Kort om Signaturgruppen: Signaturgruppen er dannet 2006 af en masse erfarne Digital Signatur specialister i Danmark. En del fra TDC som stod for OpenOces signaturen. Producerer professionelle signaturløsninger og deltager i rådgivnings- og arkitekturarbejde.

13 Page 7 of 79

14 Page 8 of 79 2 Planlægning Jeg valgte at arbejde primært med udviklingsmetoden Vandfaldsmodellen, dette skyldes bl.a. at det var NemID som skulle migreres til Nemkonto ud fra DanID s løsningsbeskrivelse. Eftersom størstedelen af alle krav var sat af DanID og IT-Styrelsen ville chancen for store pludselige ændringer være meget lille og derfor var vandfaldsmodellen at foretrække, samt at der var udarbejdet en løsningsbeskrivelse af DanID som et forslag hvordan dette skulle migreres. Kundens specifikationer var dermed udarbejdet og med sikkerhed ville der ikke blive lavet store ændringer. Der var dog stadig planlagt ugentlige møder med min projektleder og der var deadlines som skulle overholdes, således vi havde et stort overblik over projektet. Det kan også argumenteres for, at der er lagt en smule XP(Xtreme Programming) i forløbet, da der har været en mulighed for at ændre en smule på kravene i kravspecifikationen, samt er der blevet gjort brug af blackbox test. Den traditionelle vandfaldsmodel (Analyse, Design, Implementering og Test, udført adskilt og i nævnte rækkefølge) kan således i denne situation have sin berettigelse. En række ting som gør sig gældende for vandfaldsmodellen og hvorfor den er at foretrække: Det giver en god synlighed over projektet og gør det hele lettere at styre. Man får en god dokumentation. Modellen passer bedst til situationer, hvor kravene kan specificeres, er forståelige, og senere ændringer er begrænsede, hvilket de i dette tilfælde vil være. Ændringshåndtering er lidt vanskelig, men bliver som sagt i dette tilfælde argumenteret for hvorfor det højst sandsynlig ikke vil ske i projektet, da alle krav er mere eller mindre fastlagt fra start. Der gås fra fase til fase sekventielt.

15 Page 9 of Planlægning Herunder ses planlægningen for hele projektforløbet. Der vil blive vist møder med projektleder, arkitekt og Signaturgruppen. Mødet med Signaturgruppen foregik i KMD, hvor jeg selv og en arkitekt var til stede, for at vurdere om denne Valideringskomponent levede op til de krav vi havde, det blev det efterfølgende besluttet at det gjorde den, og der blev aftalt en dag til at holde en workshop. Denne workshop blev brugt til at blive enig om hvordan det ville være nemmest at bruge den i NemKonto systemet, hvor der også blev lavet proof og context. Møderne med projektleder foregik ugentligt og blev næsten afholdt alle de aftalte gange. Figur 1: Tidslinje

16 Page 10 of 79

17 Page 11 of 79 Som det ses på figuren, gav DanID først adgang til noget af deres Testmiljø den 8. februar. Det var også her, at de havde lovet at komme med første hele TU 4 -Pakke, som skulle være en beskrivelse af deres løsningsforslag til NemID. Denne skulle indeholde alt nødvendig information om NemID, samt en sikkerhedspakke som primært skulle stå for validering af login og signering. Denne pakke kom bare ikke d.8 men blev udskudt helt til sidst på måneden. Dokumentationen hertil vidste sig dog at være en smule mangelfuld og der blev løbende lavede opdateringer af denne løsningspakke, både beskrivelse og til dels kode. Sikkerhedspakken bestod af Java eksempler, hvilket vi ikke ville bruge til NemKonto, som jo er baseret på ASP Classic, og kører på en IIS 6.0. Derudover kom de med en anden løsning som baserede sig på et OOAPI Open Oces 5 API, som er en.net løsning, denne kræver at man selv implementerer kaldene til alle de forskellige valideringsservices Analysen/Design I løbet af analysedelen som ses i ovenstående figur fandt jeg ud af at det var en alt for stor og tidskrævende opgave for en enkelt person at implementere hele valideringen, så det blev besluttet at finde nogen som var klar med denne sikkerhedspakke eller snarere selve valideringen af signering og logon. Signaturgruppen kom her ind i billedet med en komponent de kaldte OcesUtility, denne vil blive forklaret senere i analyse afsnittet. Analysedelen af NemID forløb som den skulle, dog var DanID forsinket godt 3 uger med deres Tjeneste Udbyder Løsning, hvilket som et resultat pressede mit bachelorprojekt ca. med en lille måned, såvel som projekt for KMD. Da dette er et testforløb af DanID s løsning, er formålet også at få DanID s løsning 100 % klar til den 1.juli. Dette gjorde også at der var forventet at blive fundet en mængde fejl som DanID skulle have rettet Implementering Til alle bugs, problemer og fejl havde DanID oprettet et forum, som alle virksomheder der var med i testforløbet, kunne rapportere ind og få svar på. Herefter har der været nogle problemer med nedetid og CRL(spærreliste som ikke var sat korrekt op, ellers forløb implementeringen som den skulle) Test Testfasen forløb mere eller mindre uden problemer, implementeringen af NemID signering nåede at blive klar, dog med et par enkelte velkendte fejl som ikke ville påvirke testen. Som det ses nedenfor fra at det opdaterede Testmiljø blev tilgængeligt, blev der brugt omkring en uge på at klargøre til test og selve testen havde jeg omkring 2 uger til, hvorefter den sidste uge gik med udarbejdelse af en testrapport, som skulle afleveres til IT-Styrelsen. IT- 4 TU - Tjenesteudbyder 5 Offentlige Certifikater til Elektronisk Service

18 Page 12 of 79 Styrelsen havde så godt en uge til at godkende Testrapporten, såfremt den var iorden. Testdelen blev udarbejdet i samarbejde med en tester(i denne rapport drejer det sig kun om afsnittet: 6.1 Blackbox test, dog ingen af under punkterne), da det ikke ville være logisk at lade mig udfører hele testdelen alene, eftersom jeg selv har implementeret opgaven også. Det endte så også med at testrapporten blev godkendt. Jeg fik tildelt opgaven at implementere NemID Login sent i forløbet også, hvilket ikke bliver beskrevet i denne rapport, da det som sagt var sent henne i forløbet. Selve Testfasen ser således ud: Figur 2:Testfasen Hele projektet blev udviklet gennem 4 faser: Analyse, Design, implementering og Test. For de sidste 2 faser, har der været tidspres for at få testet ordentligt igennem for fejl og mangler i Testfasen - samtidig med at få udarbejdet Testdokumentationen i form af en rapport til IT-Styrelsen. NemID signering er mere eller mindre klar til produktion og afventer så Login delen før hele den ny digitale signatur er klar, hvilket sker i juli.

19 Page 13 of 79 Figur 3:mødeplan Foroven ses alle de afholdte møder. De Ugentlige møde har været med projektleder og en gang imellem med selskab af en Arkitekt. Til slut kan det siges at jeg blev tilbudt job som IT- Arkitekt og samtidig formentlig også bliver sat på projektet Nem-Login som kommer til at omhandle single sign-on således at når man er tilgået en offentlig service, kan man tilgå alle de andre uden at behøve gå igennem logindelen en gang til Arbejdsindsats: Der er her en lille liste over den arbejsdsindsats som er sket fra min side og ansvar: Analyse af hele Nemkontos forhenværende login og signerings proces. Analyse af hele DanID s Løsningsforslag

20 Page 14 of 79 Træfning af valg mht. NemID Stået for kontakt med DanID og Signaturgruppen Ugentlig møder med projektleder og eventuelt Arkitekt Opsætning af OcesUtility komponenten fra Signaturgruppen Ændring af signeringsflow for den gamle digital signatur og den nye signatur(nemid) Håndtering af hvordan konto nummer nu skal gemmes ved signering Opsætning af parametre Opsætning af appletten Få valideret Signering korrekt ved brug af OcesUtility komponenten Test af NemID

21 Page 15 of Risikoanalyse Ved udførelse af store projekter og projekter af denne størrelse, som fordeler sig over en længere tidsperiode, er det altid godt med en risikoanalyse. Der vil i en risikoanalyse blive listet diverse scenarier som kan gå galt eller ændre ved projektets planmæssige forløb. Derudover vil en analyse af risici ved projektet være med til at skabe et fornuftigt overblik over de hændelser som vil kunne ske, og dem vil man så være i stand til at tage med i sine overvejelser når projektet forløber. Der vil forneden være flere punkter som vil kunne have en indflydelse på projektet: Virksomheds involverede Dette projekt er afhængigt af DanID, som kommer med løsningen på den ny Digitale Signatur, det vil sige hvis deres dokumentation eller eksempelvis Testmiljø er forsinket eller har noget nedetid vil det have en indflydelse på projektets forløb. De to beskrevne problemer skete i mindre grad. Et andet scenarie kunne være at en eller flere involvere medarbejdere forlod KMD eller projektet. Dette vil kunne påvirke projektets fremgang Dette skete også, min chef og projektleder forlod begge KMD under projektets forløb. Dette havde af mindre grad indflydelse på projektet Teknologiske udfordringer Det er en fordel, at tage højde for forskellige afvigelser allerede i opstartsfasen. Det kan ske, at man løber ind i problemer, som kræver længere tid at løse end den estimerede tid. Dette kan være tekniske problemer som opsætning af miljø, som til den funktionelle opsætning af elementer. De fleste af disse udfordringer løses ved at arbejde mere intens eller ved overarbejde Fejl-implementeringer Der kan opstå fejl i implementeringen i alle softwareprojekter. Fejlrettelser tager tid, men skal rettes til således, at den endelige løsning bliver så god som muligt. Samtidig vil de fleste fejl blive fundet i testfasen, hvilket er et godt stykke henne i forløbet og der må her blive prioriteret hvad som skal løses først. Disse fejl rettes ved at forhøje arbejdsindsatsen med eventuelt overarbejde

22 Page 16 of Projekt ændringer Der opstår ofte ændringer i et projekt undervejs. Dette skyldes hovedsagligt, at der ikke har været enighed om projektets funktionalitet fra starten af. Denne nye funktionalitet kan forekomme ved ugentlige status møder. Det er derfor vigtigt at afholde alle planlagte møder i starten af forløbet da det er her størstedelen af ændringer vil blive afviklet. Jo før jo bedre, da en ændring sent i forløbet kan koste dyrt, hvis den ikke passer ind i den tænkte arkitektur. Ændringer i projektets forløb skal estimeres så de skaber et større overblik over det samlede projekt, og der vil kunne laves prioriteringer og eventuelt bemande projektet med flere medarbejdere hvis dette kræves Projektafgræsning Da dette projekt bliver udviklet i en virksomhed er det vigtigt at projektet bliver færdigt til den aftalte deadline. Projektet kan tage drejninger hvor det viser sig at nogle ting er langt mere tidskrævende end først antaget, her vil det være nødsaget at igangsætte et møde og klarlægge hvilke dele som skal gennemføres først, og hvad der eventuelt kan vente til anden release. I meget pressede situationer kan det blive nødvendigt at allokere flere folk til projektet. På dette projekt er der dog flere krav som der ikke kan gås på kompromis med Sygdom Sygdom kan altid komme i vejen for projektets tidsplan. Ved kort sygdom vil den tabte indsats altid være mulig at indhente, men ved længerevarende sygdom vil have afgørende effekt på projektet og der vil blive nødvendigt at allokere nye personer til projekt, hvis de fornødne kompetencer er til rådighed Data tab Tab af data er en risiko som altid vil være der. årsagerne til dette vil være systemfejl, overskrivning af filer, nedbrud m.m. Det bedste man kan gøre er at tage backup af sine data så det ikke vil give nogen større påvirkning. På Nemkonto projektet bliver Versionsstyringssystemet Visual Sourcesafe brugt, der bliver derudover udviklet på en Virtual Machine(VMware). Så det vil altid være muligt at hente tabte data igen. Data tab vil hermed ikke være problem på dette projekt, der er sikret så godt som der kan imod dette. 2.3 Delkonklusion Det kan her konkluderes at der er truffet et valg af udviklingsmetode, primært vandfaldsmodellen bliver brugt og XP. Der er blevet lavet en plan som viser projektets forløb og en risikoanalyse, så projektet løber så smertefrit som muligt.

23 Page 17 of 79

24 Page 18 of 79 3 Analyse Der vil her være en kravspecifikation med funktionelle, non funktionelle og succeskriterier. Der vil være en beskrivelse af de valg der er blevet truffet for den løsning der vil blive implementeret. Til start vil kravspecifikationen være beskrevet. 3.1 Kravspecifikation Dette er kravspecifikation til NemID på NemKonto. Nedenfor er listet en række krav i punktform til det endelige produkt, disse er krav fra DanID, IT-Styrelsen og NemKonto: Funktionelle krav Det appletmæssige Signeringsflow skal være ens for den gamle og ny digital signatur Der skal anvendes et specielt interaktions design udviklet af DanID og IT styrelsen,da den gamle digital signatur vil fungere 2 år frem fra 1.juli 2010 Tjenesteudbyder skal præsentere slutbrugeren for to forskellige signerings muligheder (applets) på deres hjemmeside. Det skyldes, at der er to forskellige måder, brugerens private nøgle kan opbevares på: Lokalt eller centralt. De to applets kaldes hhv. Applet uden OTP og Applet med OTP. Signeringsteksten må ikke indeholde ulovlige tegn f. eks HTML tags. En borger med spærret eller låst certifikat skal valideres som ugyldig Borgers valg af login(oces 6 I eller Oces II 7 ) skal være samme ved signering. Det er altså ikke tilladt at logge ind med Oces I og signere med Oces II. Efter integration skal NemID testes og der skal udarbejdes en testrapport til godkendelse hos IT-Styrelsen Der er bestemte parametre som skal sættes Parametre skal signeres NemKonto skal være klar til at gå i produktion med NemID d.1juli 2010 Tjenesteudbyderens system skal kunne modtage det XMLDSig der bliver sendt til webserveren. Efterfølgende skal XMLDSig-svaret valideres for, om det er korrekt signeret. NemKonto skal kunne trække PID ud af borgers certifikat. 6 Den første udgave af OCES også kendt som Digital Signatur 7 Den anden udgave af OCES og indgår som en del af NemID

25 Page 19 of 79 LDAP skal virke, altså skal opslag af fulde og partionerede CRLer vha af LDAP protokol kunne foretages følgende URL anvendes: ldap://crldir.et.certifikat.dk algoritmerne SHA-256 eller SHA-512 skal benyttes ved signering NON-Funktionelle Krav: For at siderne skal kunne vises skal der være en IIS webserver Siderne skal implementeres i ASP classic Enkelte interne tests over for Kunden, hvoraf det skal fremgå, hvilke dele af Systemet der er testet samt hvilke testcases, der er gennemført. Når den interne funktionstest er gennemført, skal Nemkonto udarbejde en testrapport, der resumerer prøvens resultat. Der skal udfyldes en formular til oprettelse af testbrugere ved DanID Der skal laves en aftale med DanID for at få adgang til testsystemerne. Hvis ikke der allerede er et test-voces certifikat til brug for kommunikation med DanIDs testsystemer skal der udstedes et gratis Succeskriterier Den nye Applet fungerer efter hensigten Valideringen af signaturen bliver korrekt valideret NemKonto går i luften d.1.juli 2010, dog vil der være en masse fordele såfremt NemID senest er klar d.1.oktober 2010, kan ses i bilag: Lanceringstilbud. Den gamle signatur fungerer korrekt i samspil med den nye. 3.2 Servermiljø For at give et overblik over NemKonto vil jeg her skrive lidt om hvordan miljøet er sat op. Webdelen af NemKonto kører på to serverfarme. Den ene farm er for og er tilgængelig via internettet. Den anden farm er for og er kun tilgængelig via CAP/IP nettet. Hver farm består af to noder der kører Internet Information Server. Der er benyttet ASP til udvikling af serverscript, og såvel server- som clientkode er udviklet i JavaScript. Til web-serverne er knyttet en fælles MS SQL database der, udover som session manager, også benyttes til lagring af svartidsmålinger, web-server fejl og driftsinformation. Miljøet består desuden består af en.net service farm. Denne håndterer webservice forespørgsler fra Nemkonto web-serverne, til validering af den gamle signatur og test af LRA status for medarbejdercertifikater. Der er i produktions setup et for NemKonto installeret en såkaldt BIG/IP, der bl.a. tager sig af load balancing og

26 Page 20 of 79 SSL kommunikation. Servercertifikater er ligeledes installeret på BIG/IP WebOffice benyttes som content management system for de åbne sider, men webserverne har ikke direkte adgang til WebOffice. I stedet genererer WebOffice serveren et udtræk af flade filer, der herefter ftp es til webserverne. Jeg vil ikke komme nærmere ind BIG/IP eller CAP/IP, da det ikke har relevans for projektet. 3.3 Programmeringssprog Her præsenteres de programmeringssprog som bruges, samt andet relevant for programmeringen ASP Classic ASP står for Active Server Pages. ASP gør det muligt at lave dynamiske hjemmesider, webapplikationer og web services, hvor brugeren (klienten), har mulighed for at kommunikere med serveren. ASP kaldes normalt for scripting. ASP er en serverside-teknologi. Serveren læser scriptsne som opgaver der skal udføres JavaScript Java Script er et scriptsprog på internettet, der virker i de fleste browsere, så længe Java Script er slået til. Java Script kan indsætte dynamisk tekst på en HTML-side, kan reagere på begivenheder, kan læse og skrive HTML-elementer. Ved JavaScript arbejder man med variabler, kald til funktioner, håndtering af hændelser, anvendelse af objekter, programkontrol med betingelser, styring af websider, indsamling af data med formularer m.m. Java Script kan også bruges til at validere data på klient siden, og kan bruges til at registrere den besøgendes browser som kan bruges til at oprette cookies Sessions Sessions er en superglobal variabel som benyttes til at gemme oplysninger om brugeren. Sessions er derudover den periode en bruger benytter på en webside indenfor den samme browser. Ved at benytte sessions får man mulighed for at overføre informationer imellem undersider. Dette kan være praktisk hvis valg på en side eller i dropdown skal huskes, og siden nu bliver opdateret. Så slipper man for at skulle vælge det samme punkt igen. Denne samling af oplysninger erkun midlertidige og bliver normalt slettet efter at brugeren har lukket browseren. Sessions fungerer ved at der skabes et unikt id (UID) for hvert besøgende og lagring af variabler baseret på unikke IDs. Dette forhindrer to brugeres data fra at blive forvekslet med hinanden, når de besøger den samme hjemmeside. Dog i meget særlige tilfælde kan det opstå i en milliontedel sekund at en bruger med samme browser kan ramme hinanden, det er meget usandsynligt. For Nemkonto bruges sessions ikke helt almindeligt, det vil sige på nemkonto gemmes sessions i databasen, så det almindelige indbyggede ASP Session objekt kan ikke benyttes i NemKonto applikationen, da der er flere webservere til rådighed i farmen. Ved brug af Session objektet, vil oplysninger kun være tilgængelige lokalt for den enkelte webserver, og

27 Page 21 of 79 det kan ikke garanteres at en bruger rammer den samme web-server hver gang inden for en sesssion. I stedet bruges den af KMD udviklede Session Manager. Session Manager består af en MSSQL database, en MTS komponent og et ASP interface. Brugen af Session Manager gør det muligt for flere web-servere at tilgå de samme sessions data (se figur). Dette gør det lidt mere kompliceret ved validering af signaturen med NemID. Webfarm Server 1 Server 2 Server x Session Manager 3.4 Signering Alle hændelser via - som kræver digital signatur bliver signeret, når brugeren foretager en ændring og trykker på Gem. Det signerede gemmes sammen med ændringen af hensyn til sporbarhed ved eventuel tvist i forbindelse med opdatering af en NemKonto. Et signeringsforløb eksempel kunne være som nedenstående:

28 Page 22 of 79 Krypter med privat nøgle Oprettelse af et digitalt signeret dokument DATA HASH Hej Med Dig 4356 #F4G Oprettelse af et digitalt signeret dokument Tilføj 4356 #F4G Hej Med Dig Dokument DATA Hej Med Dig HASH Digital Signatur #F4G Verificering af det digital signerede dokument Offentlig nøgle HASH Selve oprettelsen af et signeret dokument og verificering af dette sker som vist på figuren ovenfor. Første skridt er at den signerede tekst bliver udregnet som en hash-værdi. Andet skridt er så at denne hash værdi bliver krypteret med den personlige nøgle, den digaitale signatur bliver så medsendt det signerede dokument. Til kryptering er det ofte en RSA algoritme som bliver brugt, og eksempelvis med NemID er det SHA 256. Hvis dette signerede dokument så skulle verificeres af en given modtager vil modtageren gøre brug af den offentlige nøgle som henviser til den private nøgle. Første skridt til at verificerer at dette dokument er signeret af denne person, uden at signeringsteksten er blevet rettet undervejs, gøres ved at udregne Hash værdien af denne tekst med samme algoritme. Andet skridt er nu at dekryptere digital signaturen som sker ved brug af den offentlige nøgle, og derefter fås hash værdien. Hash værdien fra første skridt bliver nu sammenlignet med den fra andet skridt og hvis disse to værdier er ens, er signeringen sket med den private nøgle som refererer til den

29 Page 23 of 79 offentlige nøgle succesfuldt. Hvis værdien ikke er ens kan det være pillet ved signeringsteksten efter signering eller muglivis svarer den offentlige nøgle ikke overens med den private Certifikater NemKonto-systemet anvender TDC OCES certifikater (den gamle digital signatur) og stærk SSL kryptering. Den digitale signatur giver modtageren af en meddelelse sikkerhed for, at en meddelelse kommer fra den, der angiver at have sendt den. Den giver sikkerhed for, at der ikke er ændret i meddelelsen undervejs og hvis den samtidig er krypteret, at ingen uvedkommende har kunnet læse den. OCES-certifikatet er juridisk lige så bindende, som en fysisk underskrift på papir. Muligheder ved brug af signatur på NemKonto for en borger: opret ret slet vis vis historik Når en borger vil anvende NemKonto-løsningen, kontakter borgeren NemKonto-applikationen modtager borgerens logon med borgerens personcertifikat gennem anvendelse af KMD s logonserver. Logonserveren validerer borger-certifikat gennem et web-servicekald til certifikatudstederen (TDC). Herudover hentes borgerens CPR-nummer via opslag i relevante tabeller hos TDC, således at applikationen kender borgerens CPR-nummer, og borgeren kan nu få adgang til egne oplysninger i NemKontosystemet. Oplysningerne gemmes i en database, således at man efterfølgende kan dokumentere sammenhænge mellem de udførte ændringer og den tilhørende digitale signatur, og borgeren på modtager en kvittering. Med den nye digitale signatur bliver det nu DanID som står for det hele og ikke TDC som tidligere.

30 Page 24 of Personlige certifikater(gammel digital signatur) Et personligt certifikat (signatur) installeres på den personlige computer, og består af en personlig adgangskode, en privat nøgle og en offentlig signatur. En personlig signatur indeholder personens navn og CPR-nummer. Signaturen garanterer, at indehaveren har den identitet, der fremgår af certifikatet. Signaturen beskytter ved hjælp af kodning og afkodning de informationer, som modtages og sendes fra computeren. DanID tilbyder 2 typer signaturer afhængig af computerens styresystem og browser: Signatur giver personen én signatur både til digitale signaturer og kryptering Standard Signatur giver personen to signaturer. Den ene signatur benyttes til at identificere sig med, den anden til at kryptere data med. Kryptering og nøglepar: - En offentlig nøgle, som kan være frit tilgængelig for alle. - En privat nøgle, som holdes hemmelig. De to nøgler i et sådant nøglepar kan kun fungere i sammenhæng. En meddelelse, som krypteres med den ene nøgle, kan således kun dekrypteres med den anden nøgle og omvendt. Samtidig er det i praksis umuligt ud fra kendskab til den offentlige nøgle at gætte eller beregne sig til den private nøgle NemID personlige certifikater Et personligt certifikat (signatur) som indeholder den private nøgle installeres ikke længere på den personlige computer. NemID som er den ny digitale signatur, vil blive skudt i luften d.1juli Den kommer til at fungere end del anderledes end den gamle. Ligesom den gamle garantere signaturen, at indehaveren har den identitet, der fremgår af certifikatet. Signaturen beskytter ved hjælp af kodning og afkodning de informationer, som modtages og sendes fra computeren. Noget af det mest centrale ved den nye signatur er at borgernes certifikater(signaturer) nu kommer til at ligge centralt på en server ved DanID, og ikke længere er at finde lokalt på borgerens egen PC. Borgeren skal nu i stedet starte med at indtaste et brugernavn og en adgangskode. Første gang borgeren bruger sin NemID vil brugernavnet være et givent medsendt NemID, herefter får borgeren så mulighed for at rette dette til sit brugernavn(som mindst skal være på 6 bogstaver) eller CPR. Nr. og en adgangskode på mindst 6 tal/bogstaver(skal indeholde bogstaver, samt mindst et tal). Borgeren vil nu så blive bedt om at indtaste en nøgle som han/hun har stående på sit nøglekort, som er noget borgeren har fysisk på sig og vil ligne det på billedet nedenfor. Altså er der nu to faktorer en borger skal tage I betragtning:

31 Page 25 of 79 Noget borgeren skal huske(brugernavn, Password) Noget borgeren har fysisk på sig(nøglekort) Figur 4: NemID nøglekort

32 Page 26 of DanID s validerings løsning DanID s sikkerhedsløsning er den som står for at validere den digitale signatur ved logon eller signering. Sikkerhedspakken fra DanID, er baseret på Java, som indeholder eksempler på hvordan der skal valideres og gøres brug af NemID. Man behøver ikke bekymre sig om hvorvidt det er et Digital Signatur- (OCES I) eller NemID- (OCES II) certifikat og dermed holde styr på, hvilke spærrelister der skal anvendes. Det er derudover muligt at konstruere valideringen selv, her tilbyder DanID OpenOCES API (OOAPI). Her skal tjenesteudbyderen selv foretage de enkelte skridt i valideringen ved at anvende forskellige metodekald til at konstruere valideringen. DanID har stillet java-docs og tilhørende. Net-dokumentation til OOAPI tilrådighed samt komplet reference kode i Java Konklusion Da deres ene sikkerhedsløsning er baseret på Java vælges denne fra eftersom NemKonto er baseret på ASP Classic, det vælges efter et møde at konstruere valideringen selv og baserer det på DanID s OpenOces API. Det vælges samtidig at finde nogen som allerede har sat denne valideringskomponent sammen, da det tidsmæssigt ikke vil kunne lade sig gøre at blive klar til d.1juli ved selv at implementere valideringskomponenten, da jeg som den eneste er sat på projektet. Det undersøges og der findes frem til at Firmaet Signaturgruppen A/S vil være i stand til at levere valideringskomponenten. Firmaet Signaturgruppen består bl.a. af en masse fra TDC som var med til at udvikle den gamle digitale signatur Signaturgruppens Valideringskomponent OcesUtility Da Nemkonto baserer sig på ASP Classic og Valideringskomponenten OcesUtility er en.net applikation er komponenten blevet Com Wrappet således at den fungere som en Com komponent, altså en ASP Classic applikation. Dette er blevet gjort specielt for NemKonto da dette var et krav og Nemkonto ikke havde nogen planer om at lægge om til.net. Det håndterer OcesUtility komponenten: Validering af digital signatur(login og signering). Kontrol af spærrelister. Opslag af digital signatur brugerens CPR nummer. Udtrækning af navn, -adresse osv. fra signaturen, så disse informationer er let tilgængelige. Signering af parametre For at se en API beskrivelse over metoder m.m. som OcesUtility kan bruges til kan det findes i appendiks under afsnit 9.4 OcesUtility API Beskrivelse.

33 Page 27 of NemID Applet med OTP Den nye signering med NemID fungerer en del anderledes end den gamle signering, som appletten siger det kommer det til at foregå med OTP, altså one time passwords, hvilket er de nøglekort man vil blive tilsendt, som så er noget fysisk man har. Derudover er der noget man skal huske: Brugernavn og password de 2 scenarier vil se således ud: Et problem der blev stødt på var bl.a. at DanID s løsning bruger 2-step mode og ikke 3-step mode, dette var et problem da signering med den gamle signatur var baseret på 3-step mode. Efter en et møde med henholdsvis projektleder og arkitekt blev det besluttet at signeringsflow for hhv. NemID og den gamle digitale signatur bør ligne hinanden så meget som muligt og det gamle signeringsflow vil blive ændret til 2-Step mode step mode I 2-step mode bliver det signerede dokumentet sendt til serveren og videredirigering af bruger sker på samme tid. Brugeren bliver videredirigeret til en URL som også har modtaget det signerede dokumenteret hvis sådanne eksisterer step mode Dette er forskelligt fra 3-step mode hvor det signerede dokument, bliver sendt til serveren og kontrollen bliver herefter returneret til appletten. I tredje og sidste step bliver brugeren videredirigeret til en URL, men denne URL får ikke medsendt det signerede dokument.

34 Page 28 of Signeringstekst Signeringsteksten er den tekst som en borger underskriver ved signering, også kaldt aftale tekst eller signtext. Denne tekst kan være i HTML, XML eller helt almindelig tekst, på Nemkonto er der valgt kun at understøtte den normale Plain tekst, da der ikke er brug for andet. Signeringsteksten skal altid være Base64 kodet når den gives som parameter til signeringsappletten Gammel digital signatur 3-step mode signeringsflow Dette er signeringsflowet som det så ud før NemKonto blev migreret med NemID: - Indateringsskærmbilledet initialiseres med data fra NKS (1) - Brugeren indtaster sine ændringer, og trykker gem. Formdata postes til sign1.asp, der vises i popup vindue (2) - Sign1.asp opbygger en opdateringsstruktur, baseret på input fra opdateringssiden, og gemmer strukturen i session manageren (3). - Signeringsapplet en er indlejret i sign1.asp, og når brugeren underskriver sender applet en signaturen til sign2.asp (4) - Sign2.asp henter strukturen i session manageren (5). Signaturen sendes til webservice for validering (6). Hvis validering af signatur er OK gemmes signaturen på signaturkøen (7). Strukturen opdateres med message ID fra signaturkøen, og sendes til NKS for behandling (8). Når svaret modtages fra NKS genereres kvitteringstekst, og denne gemmes i sessionmanager (9). Sign2.asp afslutter, og melder status tilbage til signeringsapplet (10). - Signeringsapplet en get er receiver.asp, med parameter der angiver status fra sign2.asp (fejl eller OK) (11). - Receiver.asp beslutter på baggrund af statusværdi fra signeringsapplet, hvad der videre skal ske. Hvis status er fejl, overføres fejlmeddelelse til inddateringsskærmbilledet, popup vinduet lukkes. Signeringsflowet er hermed afsluttet. Hvis status er OK, redirectes inddaterinsskærmbilledet til kvitterings.asp, og popup vinduet lukkes (12) -Kvittering.asp læser kvitteringstekst fra sessionmanager, og præsenterer dette for brugeren (13). Signeringsflowet er hermed afsluttet.

35 Page 29 of 79 S T A R T 1 NKS Inddaterings side 8 11 receiver.asp 2 12 sign1.asp opensign java applet 4 10 sign2.asp kvittering.asp S L U T 3 Session Manager Signatursilo webservice

36 Page 30 of Delkonklusion Det kan konkluderes at der her er blevet truffet nogle valg, som har indflydelse på designet og implementeringen. Der er blevet lavet en kravspecifikation bestående af funktionelle og non funktionelle krav, samt succeskriterier. Det er blevet beskrevet og vist hvordan signeringen fungerer i dag og hvordan den vil komme til at fungere. Programmeringssprog, samt sessions er beskrevet og der er gået lidt i dybden med den nye NemID applet og opsætningen af denne. Et væsentligt valg, som er truffet er at lave signeringsapplet med Oces I og Oces II om til brug af 2-step mode for begge i stedet for 3-step mode, da DanID s løsning kræver det for NemID. En anden beslutning var at gøre brug af signaturgruppens valideringskomponent, denne var dog beregnet til.net løsninger, men er blevet COM wrappet således at den kan bruges som en COM Applikation. En anden overvejelse var at lægge om til ASP.net hvilket hurtigt blev afvist da dette er en alt for stor tidskrævende opgave.

37 Page 31 of 79

38 Page 32 of 79 4 Design 4.1 Sikkerhed Sikkerhedsmæssigt er længden på password og brugernavn ikke det mest sikre, man kunne have krævet at borgeren skulle bruge et password som bestod af: Min. Et tal Min Et stort bogstav Min. Et specialtegn Min 8 karakterer Dog hvis man kommer i besiddelse af brugernavn og password, vil dette ikke være brugbart, da man ikke har det fysiske nøglekort. Omvendt hvis man er i besiddelse af nøglekort, mangler man stadig brugernavn og password, så sikkerhedsmæssigt vil det ikke være så stor en trussel hvis en person kommer i besiddelse af en af delene, da hele sikkerheden er baseret på de to faktorer. En person med mistet nøglekort ville højst sandsynlig også bestille et nyt hurtigt og det gamle vil dermed være ubrugbart. Den eneste måde jeg umiddelbart kan forestille mig at det kan gå galt, er ved at borgeren blive truet til at udlevere alle informationer og IT-sikkerhedsmæssigt vil dette være umuligt at sikre sig mod. Derudover under signering bruges en parameter Challenge som bliver sat for at undgå Replay attacks. Der bliver ikke brugt de almindelige Sessions men derimod en SessionsManager som gemmer sessioner i databaser, dette øger bl.a. sikkerheden så der ikke bliver manipuleret med sessioner. Mange fremtidige brugere vil højst sandsynlig overveje, at lægge nøglekortet ind på computeren af forskellige grunde: måske gider personerne ikke have kortet på sig eller bare for en sikkerhedsskyld, eller også programmere de selv en løsning hvor at det nøglenummer som skal findes, automatisk bliver kopieret ind i indtastningsfeltet. Dette frarådes dog, da det som sagt vil gøre det nemmere for en hacker at få fat i nøglekortet, så dette er på brugerens eget ansvar.

39 Page 33 of 79 Derudover bliver der overvejet fremtidige løsninger fra DanID s side, som en token løsning eller sms løsning til brugere der vil dette. Derudover vil der højst sandsynlig snart komme en løsning hvor brugeren kan have sin nøgle liggende på et smartcard NemID Et problem der vil og bliver diskuteret meget er hvor sikkert det kan være at samle alle folks private nøgler et sted. Kan man være helt sikker på at en dygtig hacker, en korrupt medarbejder hos DanID eller måske en efterretningstjeneste ikke vil have for nem adgang til millioner af danskeres netbank-konti, skatteoplysninger og andre private oplysninger, nu skal der jo ikke hackes en million computere for at få fat i en million nøglefiler, men bare en Replay attacks: For at sikre mod replay angreb bliver der gjort brug af parameteren challenge, denne challenge kan bestå af et timestamp eller bare et tilfældigt nummer eller streng. Challenge bliver sat som en parameter og er et tilfældigt nummer eller streng som ændres for hver gang der sker en signering. Resultatet som appletten så giver os bliver checket med denne for således at undgå replay angreb Man in the middle Hvordan sikre man sig mod at nogen sætter en sider op og dermed laver Man In The Middle attack, således at hacker får fat i brugernavn og password, og dermed og kan få fat på nøglenummer, dette vil være en stor sikkerhedsrisiko som vil være vigtig at sikre mod. Dette er der nu taget højde for ved at der under validering af både signeringen nu har mulighed for at kontrollere det modtagne svar bliver genereret på Nemkontos hjemmeside og ikke af en tredjepart, som ville gøre der til et Man In the Middle angreb. Der er to parameter logonto (Oces I) og requestissuer (OCES II) som bliver sat ved signerign disse værdier bliver nu checket om de er korrekte. 4.2 Kommunikation Kommunikation mellem signerings Appletten, DanID og NemKonto er anderledes end ved den gamle digital signatur, Appletten er ikke længere placeret hos Tjenesteudbyderen i dette tilfælde NemKonto, men hos DanID. Nedenfor vil der være en beskrivelse af hvordan kommunikation nu foregår:

40 Page 34 of 79 NemKonto DanID Applet Browser - Nemkonto Bruger 1. En borger trykker på en hændelse som medfører at der skal signeres, eventuelt vil borgeren rette sit kontonummer på NemKonto. NemKonto genererer nu en webside og overfører den til brugeren. Denne side refererer til en applet, som er placeret hos DanID. 2. DanID overfører appletten til brugeren. Appletten læser nu de parametre som NemKonto har sat, samt den signerede hash-værdi af parametrene, og afgør ud fra dem, hvilken funktion der skal udføres, logon eller signering. 3. Appletten kommunikerer over en sikker forbindelse med DanID for at fastslå brugerens identitet. 4. Resultatet af signeringen sendes fra appletten tilbage til NemKonto.

41 Page 35 of Opsætning af Parametre Når appletten overføres fra DanID til brugeren læser den de parametre som Tjenesteudbyderen(Nemkonto) har sat, hvis disse parametre ikke er sat fuldstændig korrekt op vil appletten fejle. Der er en del parametre som er valgbare og en del som er et krav bliver sat, de parametre som det drejer sig om og er et krav at blive sat, vil kort blive forklaret her.: Zip_File_Alias: Denne parameter bestemmer operationen som skal udføres(logon eller signering) ServerUrlPrefix: Angiver adressen på DanID server, som appletten skal kommunikere med. MayScript: Denne parameter skal medtages for at sikre, at appletten kan kommunikere med browseren og vende tilbage med svar til tjenesteudbyderen. ParamCert: Nemkontos virksomhedscertifikat skal medsendes i denne parameter. (Certifikatet skal bruges til at validere signaturen på applettens parametre, og til at inkludere tjenesteudbyderens navn i appletten.) Paramsdigest: Hash-værdien af de normaliserede parametre SignedDigest:Underskriften på parametre til appletten. (Signeres så de ikke kan blive manipuleret med). Signaturen som skal medsendes i en parameter. Hvis hash værdien af de normaliserede parametre ikke bliver udregnet fuldstændig korrekt vil appletten fejle i sin opstart, da appletten også selv udregner denne værdi af parametrene og derefter sammenligner dem. Første skridt er at Nemkonto samler listen over de parametre, der skal sendes til appletten. Listen normaliseres til en samlet tekststreng. Hash-værdien af denne streng beregnes så, hvorefter værdien signeres med Nemkonto virksomhedscertifikat. Næste skridt er så Websiden, som indeholder appletten og dens parametre, genereres. Hash-værdien og signaturen fra det første trin inkluderes som applet-parametre. Appletten læser nu parametrene og normaliserer dem på helt samme måde som Nemkonto har gjort det, bortset fra Hash-værdien og signaturen som holdes ude fra normaliseringen. Appletten vil nu verificerer, at den beregnede hash-værdi er ens med den værdi som Nemkonto medsendte parametre havde. Tilsidst vil appletten så sende parametrenes hashværdi og signaturen over til DanID, DanID verificerer så signaturen med Nemkontos virksomhedscertifikat.

42 Page 36 of Brugergrænseflade Der er lavet et specielt brugergrænseflade fra IT-Styrelsen og DanID, vist via mock ups, disse skal implementeres så de ligger så tæt op af de originale som muligt. De ser således ud: 4.5 Signering OpenSign Java applet NemKonto benytter OpenSign til at håndtere signering med som er den gamle OpenOces Digital Signatur fra TDC. Beskrivelse af signeringsflow Gammel digital signatur vs. Ny digital signatur(nemid) Der vil her blive beskrevet det gamle signeringsflow for den gamle digital signatur og for den ny digitale signatur. Det vil være muligt at se forskellene på de 2 digitale signeringsflow. Der bliver bl.a. valideret på en anderledes måde med NemID

43 Page 37 of Gammel digital signatur - Indateringsskærmbilledet initialiseres med data fra NKS (1) - Brugeren indtaster sine ændringer, og trykker gem. Formdata postes til sign1.asp, der vises i popup vindue (2) - Sign1.asp opbygger en opdateringsstruktur, baseret på input fra opdateringssiden, og gemmer strukturen i session manageren (3). - Signeringsapplet en er indlejret i sign1.asp, og når brugeren underskriver sender applet en signaturen til checkocesisign.asp (4) -checknemidsignering.asp henter strukturen i session manageren (5). -Signaturen Valideres her vha. OcesUtility komponenten, og der tjekkes samtidig om det er samme bruger der signerede som der loggede på. Der tjekkes op på spærreliste via kald mod spærrelister, for at se om certifikatet er låst eller spærret. Der laves PID-CPR opslag op mod TDC (6). -Hvis validering af signatur er OK gemmes signaturen på signaturkøen (7). -Strukturen opdateres med message ID fra signaturkøen, og sendes til NKS for behandling (8). -Når svaret modtages fra NKS genereres kvitteringstekst, og denne gemmes i sessionmanager (9). -checknemidsignering.asp afslutter, og bruger dirigeres herefter videre alt efter (fejl eller OK), Hvis status er OK, redirectes inddaterinsskærmbilledet til kvittering.asp, og popup vinduet lukkes (10). (7,8,9 er primært for at få gemt kontonummer og andet som skal gemmes af sikkerhedsmæssige årsager) -Kvittering.asp læser kvitteringstekst fra sessionmanager, og præsenterer dette for brugeren (12). Signeringsflowet er hermed afsluttet. Hvis status er fejl, overføres bruger til fejlmeddelelses side, hvor der vil være specificeret fejlen alt efter hvilken værdi valideringskomponenten kommer med, errorpage.asp.(11)

44 Page 38 of 79 S T A R T 1 NKS Inddaterings side 8 errorpage.asp 2 11 sign1.asp opensign 10 kvittering.asp java applet 4 checkocesiopen Sign.asp S L U T 3 Validering af signatur(webservice) Session Manager Signatursilo

45 Page 39 of Den Ny Digitale signatur Dette er den gamle digitale signatur på Nemkonto før NemID skulle implementeres. - Indateringsskærmbilledet initialiseres med data fra NKS 8 (1) - Brugeren indtaster sine ændringer, og trykker gem. Formdata postes til NemIDsign.asp, der vises i popup vindue (2) - NemIDsign.asp opbygger en opdateringsstruktur, baseret på input fra opdateringssiden, og gemmer strukturen i session manageren (3). - DanID overfører appletten til brugeren. Appletten læser de parametre, Nemkonto har sat, og afgør ud fra dem, hvilken funktion der skal udføres, i dette tilfælde signering (4). -Brugeren autentificerer sig og signaturen sendes tilbage pakket ind i XMLDSig(5) -Bruger videredirigeres til checknemidsignering.asp(6) -checknemidsignering.asp henter strukturen i session manageren (7). -Signaturen Valideres her vha. OcesUtility komponenten, og der tjekkes samtidig om det er samme bruger der signerede som der loggede på. Der tjekkes op på spærreliste via kald mod spærrelister, for at se om certifikatet er låst eller spærret. Der laves PID-CPR opslag op mod DanID (8). -Hvis validering af signatur er OK gemmes signaturen på signaturkøen (9). -Strukturen opdateres med message ID fra signaturkøen, og sendes til NKS for behandling (10). -Når svaret modtages fra NKS genereres kvitteringstekst, og denne gemmes i sessionmanager (11). -checknemidsignering.asp afslutter, og bruger dirigeres herefter videre alt efter (fejl eller OK), Hvis status er OK, redirectes inddaterinsskærmbilledet til kvittering.asp, og popup vinduet lukkes (12). -Kvittering.asp læser kvitteringstekst fra sessionmanager, og præsenterer dette for brugeren (13). Signeringsflowet er hermed afsluttet. Hvis status er fejl, overføres bruger til fejlmeddelelses side, hvor der vil være specificeret fejlen alt efter hvilken værdi valideringskomponenten kommer med. 8 NemKonto System

46 Page 40 of 79 Figur 5:NemID signerings Diagram

47 Page 41 of Validering af Certifikat (NemID) Når der skal signeres af borger skal certifikatet efterfølgende Valideres. Det sker ved kald til to af følgende metoder: ocesasp.validatenemidsignature ocesasp.validateocesiopensign Et forløb i hvad der checkes her er: 1. Trække certifikatet ud af XMLDSig en: XMLDSig (XML Signature Syntax and Processing) er en W3C-standard, som benyttes til at transmittere information om digitale underskrifter.her er der nu muligheden for at benytte algoritmerne SHA-256 og SHA-512 ved signering. SHA 256 benyttes ved NemID. 2. Validerer certifikatet og identificere CA som OCES I eller OCES II gennem hele certifikat-kæden til rodcertifikatet. 3. Tjekke at certifikatet ikke er udløbet, Tjekke at certifikatet ikke er spæret: Der slås her op i den fulde CRL spærreliste vha. LDAP protokollen(o=danid,c=dk). Nemkonto finder så nu ud af hvem der har udstedt certifikatet og slår herefter op i den relevante spærreliste. Der vil være en separat spærreliste for OCES I Digital Signatur certifikater og række spærrelister OCES II. Grunden til dette er, at man med OCES II maksimalt udsteder en million certifikater under et hovedcertifikat. Disse hovedcertifikater vil alle være udstedt af DanIDs rodcertifikat. 4. SigneringsTekst: Systemet returner den signerede svartekst til Nemkonto. Nemkonto sammenligner nu om den signeringstekst fra DanID er den samme som den fra Nemkonto. Altså at den signerede tekst i svaret fra appletten er identisk med den tekst der blev sendt til signering. Såfremt valideringen af signaturen godkendes, vil Nemkonto nu tjekke på om denne borger som signerede også var den som loggede på. Dette gøres ved opslag af PID og derefter sammenligne CPR nummer, hvis disse er ens, er det samme borger som

48 Page 42 of 79 signerer som også loggede på og borgeren bliver videredirigeret til en kvitteringsside. Der vil også blive tjekket op på parameteren challenge for at sikre mod replay attacks. 4.7 Delkonklusion Det kan her konkluderes at vha. beskrivelse af diagrammer over de nye signeringsflow er funktionalitet blevet beskrevet mere detaljeret, hvorved en implementering af dette vil være mulig. Der er derudover beskrevet selve kommunikationen mellem Nemkonto, DanID og bruger, så et overblik over dette er tydeligt. En forståelse for hvordan Validering af et certifikat sker, er også vigtig og er beskrevet i dette afsnit. Det er givet et bud på hvordan brugergrænsefladen skal se ud via mock ups, dette skal som sagt følges så interaktions designet ligger så tæt op af som muligt.

49 Page 43 of 79

50 Page 44 of 79 5 Implementering Der vil i dette implementeringsafsnit blive beskrevet hele implementeringsforløbet, fra start af signering og til slut. Det vil altså blive beskrevet på sådan en måde at man langsomt går igennem de vigtige implementeringspunkter jo længere man kommer kronologisk i forløbet. Der er som tidligere blevet beskrevet gjort brug af den Com Wrappede OcesUtility Komponent som står for det meste validering af signaturen når der blvier signeret. Den sættes op i web.config og i Global.asa bliver den defineret som en instans af klassen OcesUtility. 5.1 Struktur De vigtigste biblioteker bliver beskrevet her. Applikations struktur OcesUtility o Bin: Indeholder valideringskomponenten. Applikationen hedder OcesUtility. o Global.asa, der definerer en global variabel kaldet oces, som indeholder en instans af OcesUtility klassen. o Web.config der konfigurer OcesUtility Logon: indeholder de sider der ikke skal beskyttes af logon filteret Sign: indeholder de sider der skal beskyttes, primært login siden.

51 Page 45 of 79 o signinclude er kode mht. Nemkonto ændringer, ikke specielt relevant for den nye signering, før var alt koden dog i selve siden hvor appletten også blev sat op, dette er nu fjernet da det skal være i begge signeringsider og bliver bare included. Siderne receiver, samt sbxxx. Og sign2 skal der ses bort fra da disse drejer sig om sagsbehandler og den gamle signering Logon biblioteket I Logon biblioteket ligger de sider der ikke skal beskyttes af login filteret. Dette drejer sig kun om Logonsiderne og andre offentlige sider Sign biblioteket I Sign biblioteket ligger de filer der beskyttes af logon filteret. I eksemplet drejer det sig om de filer der har med signering af data at gøre, samt mange andre. For at finde ud af om en borger er logget på eller ej ved tilgåelse af en beskyttet side. Er der et IIS filter der checker om en given brugersession er autentificeret eller ej, og i givet fald redirigerer brugeren til en logon side. 5.2 Opsætningsfiler Web.Config: Web.config bruges til at konfigurere ens.net applikation, som er sat op som en xml fil. Web.config filen bruges ofte til en af 4 følgende ting: Database forbindelse Sikkerhed Sessions fejlhåndtering En web.config fil skal se således ud: <?xml version="1.0" encoding="utf-8"?> <configuration> <system.web> </system.web> </configuration> Web.config filer er forholdsvis nemme at lave, der kan bare bruges notepad eller andet. Den skal hedde web.config og ligge i roden af applicationen. Web.config en er et XML dokument

52 Page 46 of 79 og har samme struktur som Machine.config file. Web.config filen skal som minimum se ud som foroven. De første linjer siger bare at det er et XML document og skal være den same for alle XML documenter. <configuration> og <system.web> gør at man er I stand til at konfigurerer ens opsætning I <OcesUtility> konfigureres web applikationen. <configuration> <configsections> <section name="ocesutility" type="dk.signaturgruppen.ocesconfigurationhandler,ocesutility" /> </configsections> <appsettings/> <OcesUtility> <Environment>PROD</Environment> <RevocationChecker>FULL_CRL</RevocationChecker> <FullCRLDownloadInterval>600</FullCRLDownloadInterval> *<PIDCertificateFileName>XXXX</PIDCertificateFileName> <PIDCertificatePassword>Test1234</PIDCertificatePassword> *<PIDServiceID>XXXX</PIDServiceID> <EventlogWarning>TRUE</EventlogWarning> <EventlogDebug>TRUE</EventlogDebug> <SecurePrefix>/secure</SecurePrefix> <LogonPage>/Logon/NemIdLogon.asp</LogonPage> <Oces2ServerUrlPrefix> <Oces2ZipBaseUrl> <Oces2AppletLogLevel>debug</Oces2AppletLogLevel> <SuppressLogging>yes</SuppressLogging> </OcesUtility> *PIDServiceID og CertificateFIleName værdier vises ikke da disse er fortrolige. RevocationChecker sættes til FULL_CRL eller PARTIAL_CRL evt NONE_CRL I tilfælde af FULL_CRL sættes FullCRLDownloadInterval til det antal sekunder mellem komponenten checker om der er udgivet en ny spærreliste. NONEhar været effektiv under Test da der var problemer med DanID s spærrelister. Der vælges at bruge den fulde spærreliste, dette er forklaret hvorfor i Design. PIDServiceID er det serviceid der er opgivet af DanID i forbindelse med DanID's registrering af løsningen til PID-CPR opslag. For at lave dette opslag kræver det en aftale med DanID. PIDCertificateFileName er det Test Virksomhedscertifikat som Nemkonto bl.a. bruger til at signere parametrene til opstart af NemID signerings appletten. Derudeover kan kan der sættes følgende parametre, der forårsager logning til MS eventlog <EventlogWarning>

53 Page 47 of 79 <EventlogDebug> Hvis man ikke ønsker nogen logning i MS Eventloggen sættes SuppressLogging til TRUE og den vil fjerne logning til MS dette gør NemKonto brug af da alle hændelser bliver gemt i en Database. Oces2ServerUrlPrefix og Oces2ZipBaseUrl angiver hhv. det url prefix og den zip base url der anvendes ved opsætning af OTP appletten til brug ved NemID. SecurePrefix sørger for beskyttelse af sider som ikke skal kunne tilgås medmindre man er logget ind. For at checke om en bruger, der forsøger at hente en beskyttet ressource, er autentificeret kan der konfigureres et Logonfilter op i IIS der på alle kald til beskyttede dele af en applikation checker om brugeren er autenficeret og i givet fald redirigerer til en logonside. Det sørger secureprefix for Global.asa Global.asa er en fil, der benyttes til at deklarere globale variable, objekter og metoder på applikations og sessions niveau. Scripts som kan bruges (JavaScript, VBScript, JScript, PerlScript, osv.). Den benyttes som en almindelig asp fil og er event baseret, der kan kun være en global.asa fil pr subdomæne og den gemmes i roden af applikationen. I Global.asa filen er der mulighed for at fortælle applikationen hvad den skal når den starter og når den slutter. Dette gælder også for Sessions. Der bliver i vores tilfælde gjort brug af Application_OnStart Application_OnStart: Her sker der noget så snart borgeren kalder en side i ASP applikationen, herefter vil Session_Onstart blive kaldt, såfremt der er specifiseret noget her. I Global.asa defineres OcesUtility objektet, som indeholder en instans af OcesUtility klassen. Som det kan ses initialiseres der et object med navnet ocesasp og et med ocesasplogon, dette skyldes at det ene bruges ved logon og det andet ved signering. Ved at gøre det på denne måde vil der senere være mulighed for at checke om det er samme borger der signerede som også loggede på. Et for logon og et for signering, dette skyldes bl.a. at man så har muligheden for at tjekke om det er samme PID(Person ID) der bliver brugt ved signering som ved logon. <object runat="server" scope="session" id="ocesasp" progid="dk.signaturgruppen.ocesutility"> </object> <object runat="server" scope="session" id="ocesasplogon" progid="dk.signaturgruppen.ocesutility"> </object> <script language="vbscript" runat="server">

54 Page 48 of 79 Objektet initialiseres her i forbindelse med login/application_onstart, og det fortælles hvor web.config filen for applikationen befinder sig. sub Application_OnStart Dim OcesUtility set OcesUtility= CreateObject("Dk.Signaturgruppen.OcesUtility") OcesUtility.setCOMConfiguration("D:\Data\Inetpub\wwwroot\OcesUtility\web.config") end sub

55 Page 49 of Signering Selve implementeringen af signering vil blive gennemgået her Certifikat Data Denne side demonstrere hvilke ting der kan hives ud af certifikatet Det drejer sig bl.a. om Certifikat typen, er det Oces I eller Oces II, Navn, PID som kan laves om til CPR ved opslag mod DanID, og mm. <br/> TYPE= <%=oces.getcertificatetype() %> <br/> CERTIFICATE_DN= <%=oces.getdn()%> <br/> ISSUER_DN= <%=oces.getissuerdn()%> <br/> NAVN= <%=oces.getcommonname()%> <br/> = <%=oces.get ()%> <br/> CVR= <%=oces.getcvr()%> <br/> CPR= <%=oces.getcpr()%> <br/> MATCHES = <%=oces.validatecpr(" ")%> <br/> FIRMA= <%=oces.getcompany()%> <br/> SUBJECTSERIALNUMBER= <%=oces.getsubjectserialnumber()%> <br/> LOGONMETHOD= <%= oces.getlogonmethod() %> <br/> I Test vil alle de udtrukne data blive vist, for at se disse henvises så til testafsnittet Signering af data med NemID Signering af data sker når en borger vælger at foretage en af følgende hændelser for sin Nemkonto: opret ret slet vis historik Opsætning af NemID applet NemIDSign.asp viser hvordan data signeres. appletten skal hentes fra DanID, og dens parametre skal være signerede, hvilket også er tilfældet ved Logon. Det er vigtigt at gemme de angivne værdier for signchallenge og signtext, da de skal bruges senere. SignText: signeringsteksten som skal underskrives. SignChallenge: angiver en base64-indkodet udgave af teksten mychallenge )=bxljagfsbgvuz2u

56 Page 50 of 79 Hvis denne challenge ændres ved hvert login eller signering, kan resultatet fra appletten tjekkes mod denne for at undgå såkaldte replay attacks. Der kræves derudover at dens parametre er signerede. Modulet indeholder klassen Oces2AppletGenerator, som kan beregne de nødvendige params tags.: <% var appletsigner = Server.CreateObject("Dk.Signaturgruppen.Oces2AppletGenerator"); var tosign = GetSessValue("signText"); PutSessValue("SIGNTEXT", tosign); appletsigner.addsignedparameter("always_embedded", "true"); PutSessValue("SIGNCHALLENGE", appletsigner.challenge ); %> Selve appletten oprettes så på følgende måde: archive er selve placeringen af appletten og code er selve appletten. Der udover hentes de parametre som skal signeres og den signerede tekst er PLAIN, det vil sige det er ren tekst. Der bliver også sat højde og bredde på denne applet. <script type="text/javascript"> <applet name="danid_digital_signatur" archive=" code="dk.pbs.applet.bootstrap.bootapplet" width="400" height="450" mayscript="true" > <%= appletsigner.getsignparameters(tosign, "PLAIN") %> </applet> </script> NemID applet kommunikation Resultatet af signeringen postes igen tilbage til serveren vha. kald til javascript: <form name="signedform" method="post" action="/sign/checknemidsignering.asp" > <input type="hidden" name="signmessage"/> </form>

57 Page 51 of 79 <form name="errorform" method="post" action="/ocesutility/unsecure/errorpage.aspx" > <input type="hidden" name="nemiderrorcode" /> <input type="hidden" name="errorcode"/> </form> Appletten kalder en af tre definerede JavaScript funktioner, afhængigt af resultatet af forsøget på at signere data, derefter indsættes returværdierne i ovenstående form. <form>-element bruges for at appletten kan indsende NemIDs svar til TU(NemKonto). Appletten poster altså disse informationer tilbage til serveren <script type="text/javascript" language="javascript"> function onsignok(signature) { document.signedform.signmessage.value=signature; document.signedform.submit(); } function onsigncancel() { document.errorform.errorcode.value='cancel'; document.errorform.submit(); } function onsignerror(msg) { document.errorform.nemiderrorcode.value=msg; document.errorform.submit(); } </script> Validering NemID signaturen skal valideres. Den modtagne aftalesignatur valideres med kald til ocesasp.validatenemidsignature, der checkes selve signaturen signmessage derefter checkes Challenge som er sat for at sikre sig mod replay attacks, og til sidst sammenlignes det om det er den samme tekst som tidligere blev signeret. Hvis tilfældet er at signaturen ikke accepteres, så sendes borger over til en fejlside og alt efter hvilket nummer valideringsmetoden giver vil den givne fejlkode kommer frem på brugerens skærm. Hvis borgeren signatur accepteres bliver der nu efterfølgende checket om det er samme borger som loggede ind som også signerer, tjekkes vha. getsubjectserialnumber som er et Personligt ID Nummer (PID-nummer). Nummeret er en slags kundenummer som refererer til en bestemt bruger og dennes CPR-nummer. PID-nummeret er indsat for ikke at skrive borgerens CPR-nummer direkte i signaturen. <% if (ocesasp.validatenemidsignature(request.form("signmessage"), GetSessValue("SIGNCHALLENGE"), GetSessValue("SIGNTEXT"))!=0)

58 Page 52 of 79 { Response.Redirect("/OcesUtility/unsecure/errorpage.asp?errorCode=6"); } /* VALIDERE OM DET ER SAMME BRUGER SOM ER LOGGET PÅ SOM DER SIGNERER*/ else if (ocesasplogon.getsubjectserialnumber!= ocesasp.getsubjectserialnumber) { Response.Write("Signering af dokument fejlet - SubjectSerialNumber er ikke ens"); } else { //konto nummer gemmes her kan ses i bilag under kode Response.Redirect("/nemkonto/kvittering.asp"); } SignedAgreement.asp Dette er en Testside for at få valideringen til at virke korrekt. SignedAgreement.asp viser blot den signerede tekst, og oplysninger om det certifkat der er brugt til at signere teksten med. Det vil så kunne ses om data mangler eller er forkerte. 5.4 Signering med anvendelse af digital signatur Signering med digital signatur foregår på næsten samme måde som med den nye, der sættes dog andre parametre da appletten er placeret ved tjenesteudbyderen og ikke DanID. <% var appletsigner = Server.CreateObject("Dk.Signaturgruppen.Oces2AppletGenerator"); var site = "OcesUtility"; var DNFilter = "PID:"; var issuerfilter = "OCES"; var challenge =appletsigner.challenge; PutSessValue("SIGNCHALLENGE", appletsigner.challenge ); DNFilter = appletsigner.base64encode(dnfilter); var signtxt = getsigntekst(); PutSessValue("SIGNTEXT", signtxt); signtxt = appletsigner.base64encode(signtxt); appletten // Sæt filter på hvilke udestederes certifikater der skal vises i openlogon issuerfilter = appletsigner.base64encode(issuerfilter);

59 Page 53 of 79 %> Hele implementeringsafsnittet omkring signering med Digital Signaturen Oces I vil kunne læses i appendiks Under: 9.2 Signering med Digital Signatur Oces I. 5.5 Spærreliste check: Der er to muligheder for hvordan der skal tjekkes op på spærrelisterne, de er herunder beskrevet med fordele og ulemper Fordele Fuld CRL spærreliste - Ikke afhængig af online tjeneste, og dermed bedst oppetid Ulemper - Kræver komponent til håndtering af spærreliste (egenudvikling) - Bedst svartid Partial spærreliste - Hurtig og stateless - Kræver ASN1 parsning af certifikat - Kræver online adgang til TDC OCES directory port 389 Da OcesUtility komponenten giver mulighed for at vælge begge dele er det klart at foretrække den fulde spærreliste. 5.6 Fejlhåndtering Ved Signering er det muligt at certifikatet vil blive valideret ugyldigt hvilket der kan være mange grunde til. Ved ugyldigt certifikat vil borgeren blive sendt videre til en fejlside, et eksempel på fejlhåndteringen ses nedenfor: protected String getvalidationerrortext(int validationstatus) { String validationstatustext="ukendt status"; validationstatus = oces.getvalidationstatus switch (validationstatus) { validationstatustext = "Certifikat ikke præsenteret"; validationstatustext = "Dit certifikat er udløbet"; validationstatustext = "Dir certifikat er ikke udstedt af TDC OCES";

60 Page 54 of 79 } validationstatustext = "Dit certifikat er spærret"; validationstatustext = "Fejl i signerings request"; validationstatustext = "Fejl under certifikat validering"; validationstatustext = "Certifikat OK - du burde ikke havne her!"; } return validationstatustext; Så alt efter hvilket fejlnummer Validation Status giver, så vil den givne fejlkode blive vist for bruger. Dette er kun et forklaringseksempel for at gå helt i detaljer og se den aktuelle kildekode, henvises der til kildekoden som er ved lagt i appendiks. 5.7 Delkonklusion Det kan her konkluderes at alle de væsentlige filer der er implementeret og metoder er blevet beskrevet.

61 Page 55 of 79

62 Page 56 of 79 6 Test I Test vil der primært blive testet med blackbox, men også Test af Valideringskomponenten, eksempelvis om alle oplysninger kan blive trykket ud af et certifikat. 6.1 Blackbox test Funktionel test Tes t id Hvad testes Forventet hændelse Aktuel hændelse Result at Afsluttet dato 1 Opsætning af applet Appletten vises korrekt på siden Apletten vises korrekt OK Generering og signering af applet parametre Appletten vises korrekt, da parametre er signerede korrekt Paremetre genereres og signeres korrekt og applet vises OK Modtage og validerer XMLDSig svar fra applet XMLDsig en svar modtages fra appletten så certifikatet kan trækkes ud og valideres korrekt Modtages og Valideres korrekt OK Validerer et gyldigt certifikatet Certifikat bliver valideret godkendt og bruger sendes videre til den ønskede side. Validering af certifikat accepters og bruger OK Validerer at certifikat er spærret Ved validering af certifikat fejler denne med en meddelelse om at certifikat er ugyldigt. 6 PID PID nummer vises PID hentes fint ud af ceritfikatet OK Testcases Signer

63 Tes t id Page 57 of 79 Hvad testes Forventet hændelse Aktuel hændelse Result at Afsluttet dato 7 Bruger med NemID signerer første gang Bruger bliver bedt om brugernavn og password, derefter nøglekortnummer Bliver korrekt bedt om brugernavn, password og nøglekortnummer OK Bruger med NemID signerer anden gang Bruger bliver bedt om brugernavn og password, derefter nøglekortnummer Bliver korrekt bedt om brugernavn, password og nøglekortnummer OK Bruger med Digital Signatur signerer Bruger bliver bedt om at vælge certifikat efterfulgt af kode Bruger bliver bedt om at vælge certifikat efterfulgt af kode OK Bruger med NemID kun til bank signerer Da NemID et kun er til banker afvises denne ved brug af det offentlige, her nemkonto. Da NemID et kun er til banker afvises denne ved brug af det offentlige, her nemkonto. OK Bruger med spærret (tidslåst) NemID signerer Valideres til at være Ugyldig Valideres til at være Ugyldig OK Bruger med låst (permanent) NemID signerer Valideres til at være Ugyldig Valideres til at være Ugyldig OK Bruger logger ind med NemID og signerer med Digital Signatur Oces I Fejlkode SubjectSerialNumber er ikke ens Fejlkode SubjectSerialNumber er ikke ens OK Skift mellem faneblade(nemid og Oces digital signatur) Der skiftes fint mellem faner Fane skifte fint fra oces I til Nemid, men fejler med tilbage skift FEJL Fejlkoder Tes t id Fejlk ode Hvad testes Forventet hændelse Aktuel hændelse Result at Afsluttet dato 15 CAN 002 Brugeren trykkede på afbryd - knappen i appletten, alle andre steder end hvor brugeren er i gang med at logge på med midlertidig Fejlkoden vises korrekt Korrekt fejlkode og fejltekst vises OK

64 16 LOC K001 Page 58 of 79 adgangskode. Brugeren har indtastet forkert adgangskode for mange gange. Denne fejlbesked fås i den session, hvor brugeren bliver tidslåst. Fejlkoden vises korrekt Korrekt fejlkode og fejltekst vises OK LOC K003 Brugeren har indtastet forkert nøgle for mange gange. Fejlkoden vises korrekt Korrekt fejlkode og fejltekst vises OK AUT H OCES SRV AUT H00 6 Brugeren har forsøgt at logge ind, men hans NemID er spærret (permanent). Brugeren har ikke OCES (ikke egnet), men forsøger at logge ind på en OCES tjenesteudbyd er. Brugerens session med serveren er blevet tabt. Dette vil oftest skyldes at brugeren har været for længe om at logge ind, men kan også skyldes hacking eller server problemer. "Ikke flere nøgler" - hvis brugeren har opbrugt sine nøglekort, uden at der er tilknyttet et nyt. Fejlkoden vises korrekt Fejlkoden vises korrekt Fejlkoden vises korrekt Fejlkoden vises korrekt Korrekt fejlkode og fejltekst vises Korrekt fejlkode og fejltekst vises Korrekt fejlkode og fejltekst vises Korrekt fejlkode og fejltekst vises OK OK OK OK

65 Page 59 of Borger signerer Tekst med NemID Dette er en positiv test, der er succesfuldt gennemført, på signeringsflowet med NemID, og validering af signeringsteksten. Hændelse Resultat 1. Brugeren går ind NemKonto og vælger en hændelse der kræver signering. OK 2. NemKonton sender den ønskede tekst til appletten som parameter OK 3. Websiden skifter og signerings-billedet til signering med NemID vises OK 4. Brugeren validerer, at teksten er præsenteret korrekt. OK 5. Brugeren indtaster sit bruger-id OK 7. Brugeren indtaster sin adgangskode OK 8. Appletten anmoder brugeren om det fire cifret nøglenummer (#) på brugerens nøglekort. OK 9. Appletten returner den signerede svartekst til NemKonto OK 10. Nemkonto validerer om den signerede signeringstekst er identisk med den som blev givet til appletten i punkt 2. OK Borger signerer tekst med Digital signatur Situation Aktion Brugeren angiver forkert password til sit certifikat i popup vindue Indtast adgangskode. Brugeren angiver forkert password for X te gang i træk i popup vindue Indtast adgangskode. OCES applet meddeler i info box, at password ikke er gyldigt. Brugeren kan herefter prøve igen. OCES applet meddeler efter hvert fejlslagent forsøg: Forkert password. Der er således ingen øvre grænse for hvor mange gange, brugeren her må angive forkert password Brugeren angiver korrekt password til sit certifikat i popup vindue Indtast adgangskode, men certifikat er Signerings Sitet giver brugeren en passende fejlmeddelelse, men lader brugeren forblive i signeringsbilledet, hvor brugeren så har

66 Page 60 of 79 udløbet/spærret. mulighed for at vælge at logge på med et andet certifikat Test af OcesUtility komponent API et: Ved signering af NemID bliver data sendt videre til en valideringsside checknemidsignering.asp ved godkendt validering redirectes der nu hen til en test side signedagreement.asp, hvor der prøves at hive alle informationer ud af certifikatet. Alle metoder ses i nedenstående testside. Der er her testet for om alle metoder i OcesUtility API et bliver vist korrekt. Denne Test vil være at finde i Appendiks under 9.2 Test af OcesUtility API </head> <body> The signtext <br/> <br/> "<%=GetSessValue("SIGNTEXT")%>" <br/> <br/> was sucessfully signed by <br/> <br/> TYPE= <%= ocesasp.getcertificatetype() %> <br/> CERTIFICATE_DN= <%=ocesasp.getdn() %> <br/> ISSUER_DN= <%=ocesasp.getissuerdn() %> <br/> CPR= <%=ocesasp.getcpr()%> <br/> MATCHES=<%= ocesasp.validatecpr(ocesasp.getcpr()) %> <br/> NAVN= <%=ocesasp.getcommonname()%> <br/> = <%=ocesasp.get ()%> <br/> CVR= <%=ocesasp.getcvr()%> <br/> FIRMA= <%=ocesasp.getcompany()%> <br/> SUBJECTSERIALNUMBER= <%=ocesasp.getsubjectserialnumber() %> <br/> SIGNEDXML= <%=ocesasp.getsignedxml() %> </body> </html>

67 Page 61 of Delkonklusion Der er her blevet testet for signering med NemID og den tilpassede Oces I Digital Signatur. Der er valgt at bruge Blackbox test, da jeg har brugt dette igennem det meste af studietiden, og det er nemt at gå til. Der er derudover testet valideringskomponenten OcesUtility s metoder. Alle de vigtigste ting virker efter hensigten, der er dog enkelte fejl fundet, som visning af link og skift mellem faneblade, dette er pga. af signeringsteksten og bliver rettet før den 1.juli 2010.

68 Page 62 of 79

69 Page 63 of 79 7 Konklusion Det har været et stort projekt som har krævet meget tid, også udover det normale. Jeg er tilfreds med hvad der er blevet præsteret, og jeg har levet op til mine egne forventninger. Ved brug af ugentlige møder har vi sikret at der ikke skete nogen misforståelser i løbet af projektet. Jeg har fået stor forståelse for Nemkonto systemet Frontend og DanID s løsning, jeg er kommet frem til nogle væsentlige beslutninger som skulle træffes i analysen, som har haft indflydelse på designet og implementeringen. NemID er blevet integreret og der er truffet nogle valg, et valg om at bruge 2-step mode for begge appletter, et valg om at bruge signaturgruppens validerings komponent OcesUtility. Appletten blev implementeret og derefter valideringen. Hele NemID s funktionalitet er klar til produktion, der er kun et par enkelte sikkerhedsmæssige aspekter som mangler at blive set igennem, som primært ikke har med NemID s funktionalitet at gøre. Jeg er i slutningen af dette projekt blevet tilbudt job som IT Arkitekt i afdelingen: Produktog Konsulentforretningen i KMD A/S, med start 1. september 2010, hvilket jeg har takket ja til. Jeg vil derfor have mulighed for at følge dette projekt helt til ende og få rettet de sidste fejl, og muligvis være med på projektet Nem-Login, der omhandler single sign-on. Projektet NemID signering har været et utroligt spændende projekt, med masser af udfordringer, og tilfredsstillende at nå så langt at man kan se enden på projektet. Jeg har derudover forbedret mig utroligt meget i forbindelse med ASP classic og JavaScript, samt blevet en erfaring langt større omkring hvordan et projekt forløber sig for start til slut i en virksomhed som KMD A/S. 7.1 Forbedrelser: Der vil på senere tidspunkt lavet Nem-Login som baserer sig på single sign-on, sandsynligvis i slutningen af Finde en måde at folk som ikke under støtter JavaScript, kan bruge NemID, dette vil sandsynligvis ikke ske.

70 Page 64 of 79 At gemme et kontonummer skal kodemæssigt forbedres da det lige nu bare er rettet til og genbrugt en del fra den gamle kode, dette påvirker dog ikke NemID, men har stadig været en del af projektet i forbindelse med dette. USB med den private nøgle, kommer i løbet af Brug af mobil, til at signere data, kommer ikke foreløbig Lidt krypteringsproblemer ved visning af signeringsteksten når man skifter fra fane til fane, da denne gemmes i databasen, dette vil være udbedret før d.1.juli 2010 Mangler lidt tilrettelser i fejlmeddelserne, vil være gjort før 1.juli 2010.

71 Page 65 of 79 8 Litteraturliste - TU-Pakke 5 update 1 fra DanID som er en løsningsbeskrivelse af den nye Digitale Signatur kan findes på: mation_om_nemid/materiale_til_tjenesteudbydere - Samt alt andet materiale på denne side - TU5 update 1 - Dokumentation til Tjenesteudbyderpakken.zip alt om den gamle digitale signatur - Brug af DanID s udvikler fora

72 Page 66 of 79 9 Bilag 9.1 Vedlagt CD Den vedlagte cd indehloder følgende: Rapporten Rapporten er vedlagt i PDF format. Kildekode Alt kildekode vedrørende projekt NemID Signering 9.2 Signering med Digital Signatur Oces I Her sættes appletten og dens paramtre op, appletten er placeret ved nemkonto og ikke ved DanID. Alle disse parametre vil blive beskrevet. <applet id="openlogon" name="signing_applet" code="org.openoces.opensign.client.applet.bootstrap.bootapplet" width="540" height="400" codebase="/ocesutility/unsecure/applet" archive="opensign-bootstrapped.jar" mayscript="true" VIEWASTEXT> <param name="zip_file_alias" value="opensign"/> <param name="extra_zip_file_names" value="cdcard,pkcs12,capi"/> <param name="zip_base_url" value="/ocesutility/unsecure/applet/zip"/> <param name="log_level" value="info"/> <param name="ms_support" value="bcjce"/> <param name="sun_support" value="jsse"/> <param name="gui" value="modern"/> <param name="cdkortservice" value="tdc LRA"/> <param name="signtext" value="<%=signtxt%>"/> <param name="challenge" value="<%=challenge%>"/> <param name="certlistwidth" value="40"/> <param name="sortcertificates" value=""/> <param name="locale" value="da, DK"/> <param name="cabbase" value="applet/opensign-bootstrapped.cab"/>

73 Page 67 of 79 <param name="key.store.directory" value="null"/> <param name="background" value="255,255,255"/> <param name="opensign.doappletrequest" value="false"/> <param name="opensign.doappletrequestonmac" value="false"/> <param name="opensign.alerturi" value="/ocesutility/unsecure/errorpage.aspx?errorcode=3"> <param name="opensign.canceluri" value="/ocesutility/unsecure/errorpage.aspx?errorcode=1"> <param name="opensign.erroruri" value="/ocesutility/unsecure/errorpage.aspx?errorcode=2"> <param name="opensign.verifiederroruri" value="sign/receiver.asp?result=verified_error"> <param name="opensign.verifiedokuri" value="sign/receiver.asp?result=verified_ok"> <param name="opensign.verifieruri" value="sign/checkocesisignering.asp"> <% //Filtering presented certificates in openlogon applet %> <param name="subjectdnfilter" value=""/> <param name="issuerdnfilter" value=""/> </applet> Der bliver her beskrevet alle parameter som bliver sat i forbindelse med en signering med den gamle digitale signatur. Eksempelvis ved brug af subjectdnfilter og issuerdn vil appletten ikke give dig valg mulighed for at vælge en masse forskellige certifikater at signere med, men blot det som blev logget ind med: Navn Værdi type Default Description value Zip_file_alias OpenSign OpenLog on,opens Det bliver her sat om appletten skal starte som logon applet eller signeringsapplet ign Zip_base_url URL n/a Der bliver her givet en URL på placeringen af applettens zip mappe cabbase URL n/a Sti til placering cab filen locale {"en,us","d "da,dk" Lokation a,dk","ca,e S"} Width int ingen Bredde af applet I pixels Height Int ingen Højde af applet I pixels Code navn ingen Navn på appletten

74 Page 68 of 79 Codebase url ingen indeholde stien til appletten relativt til den side, hvori elementet inkluderes Archive url ingen Navn på jar som indeholder appletten EXTRA_ZIP_FILE_NA MES cdcard, pkcs12, capi ingen Liste over hvad platformen understøtter MS_SUPPORT ingen Navn på zip filen som skal downloades hvis applet kører i MS JVM SUN_SUPPORT ingen Navn på zip som skal downloades hvis applet kører I SUN JVM LOG_LEVEL loglevel DEBUG INF O ERROR debug, info, warn, error, fatal ingen ingen Log level for boot-applet. Caching, download og verification of code. Logging til java console debug refreshcerts true false true Indikerer om cetifikatet skal læses igen når appletten startes opensign.doappletre quest opensign.doappletre questonmac {"true","fals e"} {"true","fals e"} "false" Konfigurerer om appletten skal gøre brug af 2- step mode eller 3-step mode. Hvis den sættes til true bruges 3-step mode "false" Konfigurerer om appletten skal gøre brug af 2- step mode eller 3-step mode på MacOS X. Hvis den sættes til true bruges 3-step mode når appletten køres på MacOS X. subjectdnfilter Ingen Base 64 encoded streng som indeholder subject dn sernofilter Ingen Base 64 encoded streng som indeholder serial number issuerdnfilter ingen Base 64 encoded streng som indeholder Issuer dn Signtext Base64 ingen Selve signeringsteksten som er base 64 encoded encoded tekst Gui Classic, classic Skal det moderne eller klassiske layout bruges modern opensign.alerturi url n/a URL en som bruger vil blive dirigeret til hvis en fejl eller uventet hændelse sker, denne parameter skal dog kun sættes I 3-step mode.

75 Page 69 of 79 opensign.canceluri An url n/a URL en som bruger vil blive dirigeret til hvis bruger nægtet at signere dokumentet, denne parameter skal dog kun sættes I 3-step mode. opensign.verifiederr oruri opensign.verifiedok uri An url n/a URL en som bruger vil blive dirigeret til hvis en fejl eller uventet hændelse sker, denne parameter skal dog kun sættes I 3-step mode. An url n/a Configures the url to which the user is directed upon succesful completion of step 2. This parameter is only relevant when the applet operates in 3-step mode. opensign.verifieruri An url n/a URL som det signerede document bliver postet til via http protokollen. Denne parameter bruges kun ved 3-step mode Validering af at signering er foretaget korrekt foretages i checkocesisignering.asp: if(ocesasp.validateocesiopensign(request.form("signmessage"), GetSessValue("SIGNCHALLENGE"), GetSessValue("SignText"))!=0) { //Response.StatusCode = 403; Response.Redirect("/OcesUtility/unsecure/errorpage.asp?errorCode=6"); } else if (ocesasplogon.getsubjectserialnumber!= ocesasp.getsubjectserialnumber) { Response.Write("Signering af dokument fejlet - SubjectSerialNumber er ikke ens"); } else { //------KONTONUMMER BLIVER OGSÅ GEMT HER DETTE KAN SES I BILAG. return "opener.location.href='../nemkonto/kvittering.asp';window.close();"; } Herefter kan den modtagne aftalesignatur valideres med kald til validateocesiopensign, Oces komponenten vil efter have valideret signeringsaftalen og gyldighed af det signerende certifikat.

76 Page 70 of Test af OcesUtility API Nedenstående Figur indeholder alle de informationer som er blevet hevet ud af certifikatet vha. ovenstående metoder. Den signerede tekst: " :41 Du skal nu underskrive ændringen med din digitale signatur. Du har foretaget følgende ændring for CPR-nummer : Ny NemKonto: " Blev succesfuldt signeret af: TYPE= POCES 9 CERTIFICATE_DN= =Anette Andersen =PID: , =Ingen organisatorisk tilknytning, =DK ISSUER_DN= C=DK,O=DanID,CN=DanID OCES External-Test CA I CPR= MATCHES=False NAVN= Anette Andersen = CVR= FIRMA= SUBJECTSERIALNUMBER= PID: SIGNEDXML= v3sn2/r5fdchzus4oobv+wwrbyhozny5n0zqsaqlfu4= CVtU9iT6l8s+lyx53EaoJi58zBRqx4fUJtd2+27m8ABt21WaH+7PS3v2vLsAwiTNsPhZ3GKhM Ome PbpAcWfj010/+baWrYmAtY6qaiVgk6qTnLD5r23dlNB2oDDD3aE0rV93oQ/AXRbDxTTXYb qq2czz 19ZSQ3x3ms3/STs4e9S+PnKKyEMsOWD8No2oHoFrZS0Qdf9w2WBiFeRjUEb5jJUzsk0r7u Piuv+Z vvqoddhwxnrmrcxwoxs70drv7ct2to/ktz5n736l769viovprujlqjpyuv34+tdav0nqkk flchlj VKPqF9R26vAKjlGutfTb0Tjf+7DlX3/S7mmOZw== MIIFPjCCAyagAwIBAgIES8xK+TANBgkqhkiG9w0BAQsFADBOMQswCQYDVQQGEwJESzES MBAGA1UE CgwJVFJVU1QyNDA4MSswKQYDVQQDDCJUUlVTVDI0MDggU3lzdGVtdGVzdCBJViBQcmltY XJ5IENB MB4XDTEwMDQxOTEyNDA0OVoXDTIwMDQxOTEzMTA0OVowRTELMAkGA1UEBhMCREs 9 Personcertifikat. Som regel angives ikke om certifikatet er baseret på OCES I eller OCES II.

77 Page 71 of 79 xdjambgnvbaot BURhbklEMSYwJAYDVQQDEx1EYW5JRCBPQ0VTIEV4dGVybmFsLVRlc3QgQ0EgSTCCASIw DQYJKoZI hvcnaqebbqadggepadccaqocggebakg4p41soawmzvv/cz5agc4qdhlx4mnth/ak+jw GQpvtnC2V BjF7xoV8J/3AcRHfAQRAye41JzEFtxP/eacFoSLhjkmNbI/EK87MgncDGwb9uNC4JiTOY7W mtyqv cjsg+/z8fwg0xteltsfbbleticjqlx5kih0um/57+usmkdevb/ilmpknrjtmh/gzwnlz2d hutr3+ +71rwLIq4ncMgraiwg+PVJ+tb7qyXBX/pu3lbF+Q2FGN3ZjUa4sJDCQhTtxaKihy2bZTV3radZ il r5jazddfwc/giphaj7qkhtkfaam9n3hu6xxvg+z+acdfuhhc5xiahq+erklwuxr7cxkcawe AAaOC ASswggEnMIGuBgNVHR8EgaYwgaMwOqA4oDaGNGh0dHA6Ly9jcmwuc3lzdGVtdGVzdDQu dhj1c3qy NDA4LmNvbS9zeXN0ZW10ZXN0NC5jcmwwZaBjoGGkXzBdMQswCQYDVQQGEwJESzESMB AGA1UECgwJ VFJVU1QyNDA4MSswKQYDVQQDDCJUUlVTVDI0MDggU3lzdGVtdGVzdCBJViBQcmltYXJ5IE NBMQ0w CwYDVQQDDARDUkwxMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRJwRH4QpBtVmOJ QyeaMytEgKIq vzadbgnvhq4efgqubuwvjst1/37atf6/2wpi+ajz5b4wdaydvr0tbauwaweb/zazbgkq hkig9n0h QQAEDDAKGwRWNy4xAwIAgTANBgkqhkiG9w0BAQsFAAOCAgEAdqMK6EZxqpjkO2RxjE KksTGkeMAU UsbtvfErpw/CeB2a8aC5Fq/1fV0vbGazy75OFMh/nQfd0uNSd6D0mGh7gilVTd1CIu/YZvfpf bs5 4/JUSq/CMOdNt789/v+Pr4LO2VQ3Hr2UBhZtXow9jBnT4vYOSc6eozQotmzDpO6BIXY0aie HihwO AGrBSUiewBwtIBhKPXOwNZHbOd+XUrJqueE2Cc6qsUUlXARBu+gZHB9Xm6tA/9+XOYMKx Eda6IWK jcbuavegiszkt3q7dbffrdgero4r6dmzdctsibvlo5imq5pgsmk9l+warr21+jaevuw+a7m QA0ry 423fDPMostTKSdszcNf/PeeCuT9MCukwtafrKQVEv3L1bgD8V5+flh+9moqBlCG2wQ5kPzg NxhEL Ni8dU12LROupjb5lXbo/59KtZdG0QmV757D9OU4mucmF/2cwlk//RqyYo5tWlIRrhXzMIjuI 190b 4Sr3PYNbW7JG4y4YNA9B70DrjUZpmt9HNhORwrgU8KyGNvgWM+VoaYJ3cHZnj/XbN5/w U08+Bjvc GSA/Edy+zQ2Q6cWMm/FdhS7qxtIx6fLaVz2BQoBw/t1Bh67pruYowm37yDoX19ATugM6F kezh8vl vrzlmfkl4r3pwflvx+9oki5qcbhdkxn9ic49jryyyp9df68= MIIFxzCCBK+gAwIBAgIES8xU2DANBgkqhkiG9w0BAQsFADBFMQswCQYDVQQGEwJESzEO

78 Page 72 of 79 MAwGA1UE CgwFRGFuSUQxJjAkBgNVBAMMHURhbklEIE9DRVMgRXh0ZXJuYWwtVGVzdCBDQSBJMB4 XDTEwMDQy MjExMDc0NFoXDTEzMDQyMjExMzc0NFowdzELMAkGA1UEBhMCREsxKTAnBgNVBAoMIE luz2vuig9y Z2FuaXNhdG9yaXNrIHRpbGtueXRuaW5nMT0wFgYDVQQDDA9BbmV0dGUgQW5kZXJzZW 4wIwYDVQQF ExxQSUQ6OTIwOC0yMDAyLTItNDQ4MTM2OTkwMzQxMIIBIjANBgkqhkiG9w0BAQEFAAO CAQ8AMIIB CgKCAQEA9JXud8KBRfsO+6LzNbt3nxdzKEHdVsbOhUru7KL5UvdhNOvp5BBRaABoA1aGC MpfIvVU Iee9HH2kgikXxzwXnzN4IKLNOTklhkxaOAO1DAYflGe7N8JdlDVU417Ob9lyTw6Q2qIyHGqv yfzg dp3xklbszzjaiipop/lcfu5ycu3matkco0pxb8oti1igstxj5xlvfdjuqgydqpbqvtdspc3tx6 9r LS1rxZBbRVoO9s6oW3WnG54sF3m/CQEBHkICOXc5BXriWDUtPdcFaqz3V0qCmWHfxTF5 Yts1PPZ8 gtaizq4aaj4zywct5sizbxl2hi4vsjvab9+kjyrthxpyvwidaqabo4icizccaocwdgydvr0pa QH/ BAQDAgP4MEoGCCsGAQUFBwEBBD4wPDA6BggrBgEFBQcwAYYuaHR0cDovL29jZXNjYW kub2nzcc5l dc5jzxj0awzpa2f0lmrrl3jlc3bvbmrlcjccatcga1udiascas4wggeqmiibjgykkofqgskb AQEB AjCCARYwLwYIKwYBBQUHAgEWI2h0dHA6Ly93d3cuY2VydGlmaWthdC5kay9yZXBvc2l0b 3J5MIHi BggrBgEFBQcCAjCB1TAKFgNUREMwAwIBARqBxkZvciBhbnZlbmRlbHNlIGFmIGNlcnRpZm lryxrl dcbn5mxkzxigt0nfuyb2awxr5xisienquybvzybpq0vtienqlcbkzxiga2fuighlbnrlcyb mcmeg d3d3lmnlcnrpzmlryxquzgsvcmvwb3npdg9yes4gqmvt5njrlcbhdcburemgzwz0zxigd mlsa+vy ZW5lIGhhciBldCBiZWdy5m5zZXQgYW5zdmFyIGlmdC4gcHJvZmVzc2lvbmVsbGUgcGFydGV yljcb ogydvr0fbigamigxmiguoigroigopfywvdelmakga1uebhmcresxdjambgnvbaombur hbklemsyw JAYDVQQDDB1EYW5JRCBPQ0VTIEV4dGVybmFsLVRlc3QgQ0EgSTENMAsGA1UEAwwEQ1J MMYY0aHR0 cdovl2nybgh0dhauzxquy2vydglmawthdc5kay9jcmwvb2nlcy1py2ewmwmxlmnybda fbgnvhsme GDAWgBQG7BWNK3X/ftpMXr/bA8j4CNnlvjAdBgNVHQ4EFgQUPrqXQCVhMC27l2x7adYT 3Mnxjisw CQYDVR0TBAIwADANBgkqhkiG9w0BAQsFAAOCAQEAk4gWSFqUovvPzJTE9SgoJy8Okxo1

79 Page 73 of 79 YATPn2lc litixe+i8of+iisbqd20qozpich//suufp+ygi7v6d/pvxilp9mlnw9m18x7ivhp6mtyfjnzydr B 5sP5I3r2oJrFclnsjXzk9mXSnA6vFD7MB1ly7c42JaohaD8/SKxfnf0iKMi8UMA/lY4whoF5Q6j i 9ht2MdZZ8ujMAbqKdf0eylmhr8/moZNvLZA0aAc6It6uoMZkKgeNkOpYXZ7FMeK49zmVIG VTvvL/ GxOfGKEktmTjGLj2gqm6SACKbDgxWWMAluLjA0M9bUK/Gc1caa/YyrrSJav70Jo/TzpRdbo CpKKI +A== MIIGRTCCBC2gAwIBAgIES8xKvDANBgkqhkiG9w0BAQsFADBOMQswCQYDVQQGEwJESzES MBAGA1UE ChMJVFJVU1QyNDA4MSswKQYDVQQDEyJUUlVTVDI0MDggU3lzdGVtdGVzdCBJViBQcmltY XJ5IENB MB4XDTEwMDQxOTExNTExOVoXDTM2MTIxOTEyMjExOVowTjELMAkGA1UEBhMCREsxE jaqbgnvbaot CVRSVVNUMjQwODErMCkGA1UEAxMiVFJVU1QyNDA4IFN5c3RlbXRlc3QgSVYgUHJpbWFy esbdqtcc AiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAL9C15kRgzFppYLz7YA6FPp67L5MAjF n0qd7 Xxc06b2Lho7X5u7Hx59n9qlL3iNUoBBaht9J7UmqYGf3MrdaxU3lUfnPGaboancNOF5aUDG WfFwd v29kbwjy1byyhibphcr12e5fyjunuou1090nyqmlaohvbqoam84vpsg/ulvk+mnwyw/a dvs/c0lb ZC2OYNHISbNoX34cwEXXozTaEBkwvcf/CmGRm1EeXmFzPXNgcwijypuczEodSMLSSQbTu knossfr bvcvktf3wqv5mtyllh9e20zcitwa7a4kjs/uylbjoy/tsrj1lbpufxqeiq89x2mnv8qgexk46 VHZ 7pKmeuNog6/wlvAmuxQnfQx1TJyWL7PIMvOxdN547rhM25/Q1xocSKG/a4rxpVH4edpUFf JQDxNA SccgdRjjDmsIL8oXEqHPS6g9C+mYg6HzmwkTLJFstcTqEwtwoxJfAstzfH9j3cuVHmng57gk8 FnS do+z4sndfywq9eobhdec3nvs5bkeqduui2f/t91qcwwo1d5el65qly4ew+7oa1kiq+jvqy xefoev LEqekfFKso8WJyUZb86U2DU75v08clBLHsD/Kvj+ijTzngxHKchenSTmARJclxeQu7GqJd3yRt SD h4+vr7oxt8baphww1ijnrq2hqap5q+kquwckjpdfagmbaagjggepmiibjtapbgnvhrmba f8ebtad AQH/MA4GA1UdDwEB/wQEAwIBBjARBgNVHSAECjAIMAYGBFUdIAAwga4GA1UdHwSBpj CBozA6oDig NoY0aHR0cDovL2NybC5zeXN0ZW10ZXN0NC50cnVzdDI0MDguY29tL3N5c3RlbXRlc3Q0L mnybdbl ogogyarfmf0xczajbgnvbaytakrlmriweaydvqqkewluulvtvdi0mdgxkzapbgnvbam

80 Page 74 of 79 TIlRSVVNU MjQwOCBTeXN0ZW10ZXN0IElWIFByaW1hcnkgQ0ExDTALBgNVBAMTBENSTDEwHwYDV R0jBBgwFoAU ScER+EKQbVZjiUMnmjMrRICiKr8wHQYDVR0OBBYEFEnBEfhCkG1WY4lDJ5ozK0SAoiq/M A0GCSqG SIb3DQEBCwUAA4ICAQBwoCBT8f52QyFNTTgxZsbWNq+iZKiQhIf4+9oOdvvIgrbosf1pgynx zozo TmtuKLvjA9GTgblXKUHuz6hh0HgVXLaYwF0yzi6tYdwlRhQ+zpQvtXIR//P+tQyuM3Xbwgp 3ybiX 9Q/3YJwwzwT+1EnVyEetCHz+n3jPUebMApuLP8CjDeaHph8CGC+NgjKMGjaSjQOVihdvK8 DRoMSU ep9rhmnymvdihbnuu3k6waoop8qdae3mgrofosuy0pyyct+s8/icj0uwdvficvneaen2y 0KYlSPe 0I1PNXDTcwV1zFQH59DGkYHKlcyD1nelj5r6sdse4oDJEy37yusCEe4t8nwlupFJNjrsSPF7kE /t pesjmt/cppldoarme1xyqhls+kf3hwbzjh7cdcehtrv+fqrz0na8engcclbclsj8kj0tqeto zx3t j6d2anphztgetnzvafe3k5fpoqj+e5evzeemr5yiavmfipdq2u3kppgkkc6xgn69bx0idk pqro32 03TYXNdKHMGFoYx6KCubWa+OxNu4hyyEzRkZLuj3fsyTkOb7XxlAG5MSjypznOtNBJ5PGPj eshqv UNcE8638WqPMwxp8Gfebv6bvfd3vRBfUWdRNbgybF7dVZy2rgx3337h7N+8cLOmbRXQp korycbid km7njyff2oaqaznvoq== signtextsmvnigvya2vuzgvyighlcm1lzcbhdcbza3lszgugzxqgw6zibgusigvuimolbcbvzy BlbiDDuGwuIERlbSB2aWwgamVnIGJldGFsZSB0aWxiYWdlIHRpbCBQw6Vza2U= RequestIssuerw5hrb25vbWlzdHlyZWxzZW4= actionsign challenge OcesUtility API beskrivelse public int validatecertificate(httprequest request, HttpSessionState session) Initialiserer OcesUtilityObjektet og returnerer status public const int CERTIFICATE_VALID = 0; public const int NO_CERTIFICATE_PRESENT = 1; public const int CERTIFICATE_ISSUER_NOT_TRUSTED = 2; public const int CERTIFICATE_EXPIRED = 3; public const int CERTIFICATE_REVOKED = 4; public const int INVALID_OPENLOGON_XML = 5; public const int VALIDATION_ERROR = 9; public const int VALIDATION_ERROR = 9; public const int NO_CERTIFICATE_VALIDATED=10; Den samlede validering

81 Page 75 of 79 public int getvalidationstatus() Returnerer status fra validatecertificate. public int getopensignedxml() Returnerer det signerede XML fra en valideret opensign signering public String getcpr() Henter det tilknyttede CPR nummer for et person OCES certifikat. Kun understøttet for offentligt tjeneste Returnerer blank hvis der kaldes i MOCES/VOCES kontekst public String getmocescpr() Henter det optionelt tilknyttede CPR nummer for et MOCES certifikat. Vær opmærksom på CPR nummeret ikke er valideret af TDC CA. Dette opslag kræver særskilt aftale med TDC public int getmocesusertype() Henter brugertype for MOCES certifikater via opslag på TDC webservice Dette opslag kræver særskilt aftale med TDC public const int USERTYPE_OTHER = 0; public const int USERTYPE_CDCARD = 1; public const int USERTYPE_LRA = 2; public const int USERTYPE_LRA_MASTER = 4; public Boolean validatecpr(string CPR) Validerer om der er sammenhæng mellem certifikat og CPR Returnerer false hvis der kaldes i MOCES/VOCES kontekst public String getcertificatetype() Returnerer POCES / MOCES / FOCES / VOCES public Boolean ispoces() public Boolean ismoces() public Boolean isvoces() public Boolean isfoces() public String getcommonname() Returnerer certifikatets CommonName Bemærk at dette kan være trunkeret max 60 tegn public String getdn() Returnerer kanonisk DN (DistinguishedName) for certifikatet public String getissuerdn() Returnerer DN for udsteder.. public String get ()

82 Page 76 of 79 Returnerer i certifikatet Returnerer blank hvis der ikke er medtaget i certifikat. public String getcvr() Returnerer CVR nummer Returnerer blank i POCES kontekst public String getcompany() Returnerer certifikatets firmanavn Returnerer blank i POCES kontekst Bemærk at dette kan være trunkeret max 44 tegn public String getsubjectserialnumber() Returnerer kanonisk SubjectSerialNumber public Dk.Signaturgruppen.dk.certifikat.attribute.AttributeQueryResponse getmocesattribute(int attributeid,) Foretager et opslag af en MOCES attribut ved kald til TDC s attribut tjeneste Anvender det konfigurerede PID opslags certifikat overfor TDC s webservice Der henvises til TDC s dokumentation for nærmere specifikationer public Dk.Signaturgruppen.dk.certifikat.attribute.AttributeVerifyResponse verifymocesattribute(int attributeid, String toverify ) Verificerer en MOCES attribut ved kald til TDC s attribut tjeneste Anvender det konfigurerede PID opslags certifikat overfor TDC s webservice Der henvises til TDC s dokumentation for nærmere specifikationer

83 Page 77 of Lanceringstilbud