Digital Forvaltning 8. kursusgang 22.10.03 Risici vedr. personoplysninger i digital forvaltning Digital forvaltning: alle systemer koblet sammen i et net Næsten alle systemer i den digitale forvaltning vil være koblet på det samme netværk: internettet. Jf. metaforen: digital forvaltning = forbinde 1000 øer. Det digitale certifikat Baggrund: Kryptering, enkelt- og offentlig+privat CPR EPJ Græsted- Gilleleje Told - Skat "Udfordringer" for det offentliges brug af digitale certifikater Sundhedsportal Virksomhedsportal forbindelse til det øvrige internet Risiko 1: registersamkøring Registersamkøring: teknisk vil en ekstremt omfattende registersamkøring være let alle borgere vil fx. være identificerbare ud fra personnummer bremses kun af letfjernelige beskyttelsesmekanismer forudsætter ændring af lovgrundlaget (registerloven) protester fra starten af 1990erne synes forsvundet Risiko 2: internt misbrug Sammenkoblingen af digitale forvaltningsøer bygger på softwarebaseret adgangskontrol meget kompleks pga. antallet af systemer regler/organisationspolitikker sundhedspersonale må kun se i er af faglige grunde.. politiansatte må kun se i kriminalregistret af faglige grunde.. regelbrydere kan være umulige at finde (Per Stig Møller-sagen) regler kan i øvrigt være uklare
Risiko 3: identitets-forfalskning ("maskerade") Uddybning af sikkerhedsmæssige krav til autentificering Jeg er Jens Hansen, og vil se min Beskyttelse mod maskerade = autentificering Krav (fundamentale og pragmatiske): sikker billig brugervenlig (let at bruge) ved sikkerhedssvigt: rimelige hæftelsesregler Brugbart (skal have anvendelser) Jeg er Jens Hansen, og vil se min Sundhedsportal Sundhedsportal Autentificering (god, sikker a.) betyder især: besked kommer fra påstået afsender besked er uændret Men også: besked er original (ikke gensendt) afsender er den han/hun giver sig ud for at være (kobling af elektronisk og personlig identitet) Løsninger baseres på varianter af: afsender har hemmelig Digital Forvaltning 8. kursusgang 22.10.03 Risici vedr. personoplysninger i digital forvaltning Det digitale certifikat Baggrund: Kryptering, enkelt- og offentlig+privat "Udfordringer" for det offentliges brug af digitale certifikater Indehavers navn m.m. Offentlig Signatur fra CA Jens Hansen: XYZab98n2cwlsjv Digitalt certifikat det centrale artefakt i PKI (public key infrastructure) tekst lagres i fil offentligt, kan indgå i "telefonbog" signatur fra CA (Certificate authority, certifikat-udsteder) bekræfter sammenhængen mellem navn og sendes ved autentificering hører sammen med hemmelig privat
Digital signatur Infrastruktur besked + krypteret hash (henvisning til digitalt certifikat) er en "signeret besked" altså ikke selve signaturen, (men helheden af signaturen og det den signerer) signering består bl.a. af kryptering med privat dekryptering sker med offentlig digitalt certifikat giver sammenhæng mellem offentlig og (påstået) afsender Jens Hansen: XYZab98n2cw lsjv Jens Hansen: XYZab98n2cw lsjv Certifikatudsteder (+center) Jens Hansen: XYZab98n2cw lsjv Uddybning man krypterer kun en hashværdi af beskeden hvis beskeden ønskes hemmeligholdt, krypteres den på anden vis privat besked + krypteret hash (henvisning til digitalt certifikat) Digital Forvaltning 8. kursusgang 22.10.03 Kryptering (enkelt ) krypterings de-krypterings = krypterings Risici vedr. personoplysninger i digital forvaltning Det digitale certifikat Baggrund: Kryptering, enkelt- og offentlig+privat "Udfordringer" for det offentliges brug af digitale certifikater Jens Hansens @jk3?!?4o8pdj krypteringsalgoritme Jens Hansens de-krypteringsalgoritme
Offentlig kryptering enkelt vs. offentlig+privat Modtagers offentlige enkelt (konventionel, symmetrisk): krypterings = de-krypterings hurtig upraktisk: hvordan distribuere krypterings? offentlig+privat (to-, asymmetrisk): krypterings <> de-krypterings langsom r kan bytte rolle Jens Hansens Modtagers private @jk3?!?4o8pdj Jens Hansens Kryptering+dekryptering Offentlig autencitering Afsenders private Jeg er Jens Hansen og vil se min Autentificering - flere detaljer Afsenders offentlig @jk3?!?4o8pdj Modtager har certifikatet, og stoler derfor på at den offentlige hører til Jens Hansen Jeg er Jens Hansen og vil se min "Jeg er Jens Hansen og vil se min " hash "Jeg er Jens Hansen og vil se min " RSA "MAC"/ signatur privat Certifikat Jens Hansen: XYZab98n2cwlsjv Besked sendt af indehaver af privat og er uændret. Privat indehaves af Jens Hansen (I stedet for certifikat kan medsendes oplysninger, som muliggør at modtager kan søge efter certifikat hos center)
RSA RSA: lille eksempel (n,e) (n,d) A = 1, B = 2, C = 3, D = 4, E = 5,... Offentlig = (33,3) M M e (mod n) = C C C d (mod n) = M M M = 5 C = 5 3 mod 33: 5 2 mod 33 = 5*5 = 25 5 3 mod 33 = 125 mod 33 = 26 C = 26 RSA: Forudsætning for sikkerhed Teknisk konklusion på digitale certifikater Offentlig = (33,3) Hvad er den privat (33,d)? 33 kan opløses i 3*11 Sikkerheden ved RSA beror på, at faktorisering af store tal er uoverkommelig (selv om man ved der er præcis to primtalsfaktorer) Trial-and-error metode har eksponentiel kompleksitet Visse moderne metoder har bedre kompleksitet: subeksponentiel k., der intuitivt er "næsten-eksponentiel". Bedste kendte hedder Tallegeme-sien (Number Field Sieve) fra ca. 1990 Digitale certifikater er teknisk set tilstrækkelig sikre til bl.a. autentificering: Algoritmer er kendte Svagheder diskuteres offentligt Konsensus blandt videnskabsmænd m.fl. om sikkerhed (forudsat tilstrækkelig længde) Der eksisterer ikke bevis for, at der ikke findes bedre algoritmer.
Digital Forvaltning 8. kursusgang 22.10.03 Risici vedr. personoplysninger i digital forvaltning Det digitale certifikat Baggrund: Kryptering, enkelt- og offentlig+privat Pressemeddelelse 6. februar 2003: Videnskabsminister Helge Sander.. digital signatur.. regeringsgrundlaget.. Danmark som førende IT-nation.. Tilbud om gratis digital signatur til alle danskere om en måned I første omgang: selvangivelse Senere: Andre offentlige digitale tjenester Erhvervslivet kan bruge signaturen til e-handel m.m. baseret på x.509 og andre internationale standarder 1,5 mill. har allerede homebanking-certifikat "Udfordringer" for det offentliges brug af digitale certifikater Udfordring nr. 1 Nødvendige standarder i en offentlig -infrastruktur De to vigtigste grundelementer: Standardisering (1) format for certifikat (2) protokoller for autentificering x.509 er den universelt accepterede standard for (1) og (2). udarbejdet af ITU Yderligere krav til en brugbar, fælles dansk standard: for at sikre udbredelse (3) konkretisering af certifikatformatet navne, identifikationsnumre (4) regulering: indehavernes opførsel: opbevaring centre: tilbagetrækningslister, 24/7 regler for signaturens gyldighed, hæftelse
x.509s certifikat-format (stadig forenklet) Lov om elektroniske signaturer (maj 2000) x.509-version Udsteder Indehavers navn Gyldighedsperiode Offentlig Indeh. Unik ID (v.2) Udvidelser (v.3) Signatur Certifikater skal bruges af email-klienter browsere af forskellig fabrikat, version m.m. Vanskeligt at få til at fungere i praksis Digital signatur efter lovens definition knæsættes som metode til signering af elektroniske meddelelser ( 13). Certifikater udstedes af private centre underkastet tilsyn ikke af statslig myndighed Det centrale begreb er "kvalificeret certifikat": ikke eksplicit krav om fremmøde ved udstedelse men center erstatnings-ansvarlig for at identitet er bekræftet ingen principiel grænse for certifikatets/signaturens anvendelse Bekendtgørelse om sikkerhedskrav til centre (oktober 2000) Eksplicit krav om personligt fremmøde & legitimation kan fraviges hvis identitet i forvejen er center bekendt herefter må "kvalificeret certifikat" forstås som baseret på fremmøde Begrebet "kvalificerede certifikater eller betegnelser.. fremkalde det indtryk.." - må kun bruges om certifikater i lovens forstand faren for falsk tillid til mindre sikre certifikater Offentlighed: Certifikatpolitik (CP) skal offentliggøres Certificeringspraksis (CPS) skal offentliggøres centre kan delvis undlade offentliggørelse med henvisning til forretningshemmeligheder og sikkerhed Præciseringer omkring intern sikkerhed "betroede medarbejdere ikke straffet for forbrydelser, der.. uegnet til.." Høring af bekendtgørelsesudkast (sommer 2000) Finansrådet: "Certificeringspraksis ikke offentliggøres.. sikkerhedskritisk.. forstås alligevel ikke af brugerne". Post Danmark: ".. meget betænkeligt at fravige.. fysisk fremmøde.." (drejer sig kun om undtagelsesbestemmelser) Erhvervs- og Selskabsstyrelsen: "Nøglecenter kan komme ud i virksomhed i stedet for omvendt" Ingen principielt imod kravet om fysisk fremmøde IT-Sikkerhedsrådet: ".. mangelfuld.. hastværk.." (rådet nu nedlagt)
Udfordring nr. 2 2002: OCES ("letvægtssignatur") Brugervenlighed OCES = Offentlige Certifikater til Elektroniske Services udviklet og vedtaget af MVTU Udtrykkeligt ikke krav om personligt fremmøde ved udstedelse dvs. ikke "kvalificerede certifikater" i lovens forstand Skyldes ønsket om brugervenlighed og hurtig udbredelse dårlige erfaringer med Kommunedatas kvalificerede certifikater i øvrigt samme opbygning med private centre under tilsyn en række præciseringer, bla. skal RSA og SHA-1 understøttes Hele det videre arbejde efter lov og bekendtgørelse har tilsyneladende ligget i OCES-udviklingen. OCES: formål IT- og Telestyrelsen. OCES - en fælles offentlig standard: "Kravene [til kvalificerde certifikater] gør det meget svært at få digitale signatur-løsninger hurtigt udbredt. Det gælder primært kravet om at brugerne skal møde personligt frem... tillige muligt for certificeringscentrene at begrænse deres erstatningsansvar...softwarebaseret, og det betyder, at det kan udbredes og anvendes billigere... kan principielt anvendes til al kommunikation mellem myndigheder indbyrdes og mellem myndigheder og virksomheder eller borgere. Det er desuden tilstræbt, at OCES-certifikater også med fordel kan bruges i den private sektor." Det vil sige hele den anvendelse, hvor loven forudsatte kvalificerede certifikater. CAs ansvar Samme generelle formuleringer i Lov og OCES-standard: "CA ansvarlig for at oplysninger i certifikat var korrekte på udstedelsestidspunkt.. Ansvar kan ikke gøres gældende overfor CA, hvis CA kan godtgøre at det ikke har handlet uagtsomt eller forsætligt" (Dvs. kun ansvarspådragende hvis CA ikke kan vise de har fulgt reglerne. Lov: Der kan ikke aftales dårligere forhold for "medkontrahenter" (indehavere og modtagere) OCES: Der kan træffes specielle aftaler med myndigheder og virksomheder, men ikke med private borgere.
Indehavers hæftelse Udfordring nr. 3 Dvs. hvad kan man komme til at hæfte for? Lov, 4: "En tydelig angivelse af eventuelle begrænsninger i certifikatets anvendelsesområde.. En tydelig angivelse af eventuelle begrænsninger med hensyn til de transaktionsbeløb, certifikatet kan anvendes til". Sikkerhed OCES-standard: Indeholder tilsyneladende ikke tilsvarende bestemmelser. Det er formentlig op til statslige myndigheder m.fl. at lave regler for anvendelsen/begrænsningerne for brug af OCES-signerede beskeder. Sikkerhed i OCES: udstedelse via CPR Sikkerhed ved personligt fremmøde Ansøger skal oplyse CPR-nummer udover navn og addresse (ingen af disse behøver stå i certifikatet) Nøglecenter tjekker at CPR-nummer og øvrige oplysninger matcher får ret til at tilgå CPR-registeret (beskrives som alternativ til fremmøde) Ansøger skal i den videre procedure (generering af par m.m.) bruge oplysninger som sendes via både den oplyste/kontrollerede adresse og via en anden kanal f.eks. epost Dvs. en tilsvarende procedure som ved udsendelse af meget andet materiale til en person med et bestemt CPR-nummer. regelmæssig udsendelse af selvangivelse, sygesikringsbevis m.m. på opfordring af borgere som ringer ind og oplyser navn, adresse og CPR-nummer MEN - her udsendes et generelt anvendeligt certifikat, snarere end en enkelt skrivelse el.lign. (indtil certifikatet spærres) Januar 2001: To certifikater blev udstedt lydende på medarbejdere hos Microsoft udstedet af VeriSign klasse 3, den mest sikre metode til autentificering ved udstedelse Klasse 3: Personligt fremmøde cpr-nr. / social security number ægtefælles navn kørekort mindst tre forskellige former for identifikation m.m. Forfalskerne brugte forfalskede papirer
Sikkerhed i OCES: den private Sikkerhed i OCES: den private OCES er rent software-baseret dvs. den private er lagret i en fil på brugerens PC hvorfra n kan stjæles ondsindet program OCES-standarden tænkes hardwarebaseret senere Hardwarebaseret privat : lagret på særligt chipkort forlader aldrig chipkortet kryptering med n foregår også internt på chipkortet Privat Symm. krypt. Krypteret privat Modforholdsregler mod tyveri af softwarebaseret privat kryptering af private passwordbeskyttelse af dekryptering/genskabelse af private OCES-standard pålægger indehaver at "tage rimelige forholdsregler" andre måde at kopiere softwarebaseret privat Password Symm. CA kan opbevare privat (som backup) efter aftale Sikkerhed: hvorledes lagres signerede dokumenter? IT- og Telestyrelsen anbefaler model 2 Studerende F. Attig får at vide fra SU-styrelsen, at man har stoppet udbetalingen af SU, da han har indsendt OCES-signeret begæring herom. Begæringen er falsk men verificeret med F. Attigs OCES-signatur. enten fordi F. Attigs er kompromitteret eller fordi SU-styrelsen har begået en fejl i verificeringen Hvorledes har SU-styrelsen lagret den forfalskede begæring? Metode 1: Oprindelig begæring inklusive OCES-signatur. Metode 2: Den oprindelige begæring, dog typisk i nyt format, og en log, der dokumenterer verifikation ved modtagelse. Loggens ægthed skal kunne bevises af myndigheden. "Admininistrativt lettest/billigst" Lettest at gemme i eksisterende ESDH-system Kan oftest ikke håndtere digital signatur, da hashværdi ændres (ændring af format => ændring af hashværdi) Inden afsendelse (efter endt brugsperiode i forvaltning) til arkivering hos Statens Arkiver skal overføres til andet format (TIFF) reformatering vanskeliggøres hvis "arkivalier" forefindes i alskens forskellige formater. 1: F.Attig: Jeg vil ikke F.Attig: Jeg vil ikke signatur have mere SU 2: have mere SU log
IT- og Telestyrelsen anbefaler model 2 "Sikkerhedsmæssigt ikke nødvendigvis bedre at verificere når F. Attig henvender sig" (argumentation understøttet af IT-Sikkerhedsrådet) Nøgler forventes knækket efter 5-6 år. OCES-CA ikke forpligtet til at gemme oplysninger om udstedte certifikater efter udløb af gyldighedsperiode Vurdering af sikkerhedsargumenter: Knækning af r uden betydning, hvis forvaltningen kan dokumentere modtagelsestidspunkt for F.Attigs begæring Certifikatoplysninger kan gemmes sammen med begæring F. Attigs certifikat Nøglecentrets offentlige OCES - "lille borgerkort" Ethvert OCES-certifikat kan knyttes til det CPR-nummer, der blev opgivet ved dets anvendelse. CA skal opbevare en database herover CA skal bruge certifikatets PID-nummer til at pege på CPR-nummer PID-nummer anbringes i x.509-certifikatets "unique user ID" PID-nummer er langt og unikt (Land + CA +...). CA skal fortælle myndigheder (f.eks. SU-styrelsen) og andre, hvilket CPR-nummer, der hører til et OCES-certifikat (efter nærmere regler). Bemærk: Samme person/cpr-nummer kan have flere certifikateter, der så har forskellige PID-numre, der alle peger på samme person. 1: F.Attig: Jeg vil ikke F.Attig: Jeg vil ikke signatur have mere SU 2: have mere SU log