Kursusgang 4: Autencificering med asymmetrisk kryptering. Digital signatur i Danmark. Pressemeddelelse 6. februar 2003:

Transkript

1 Kursusgang 4: Autencificering med asymmetrisk kryptering. Digital i Danmark. x.509 Digital Signatur i Danmark Lars' oplæg om Lov om elektroniske er. OCES NJ: Evaluering Bo: Kursusgang 5 Synopsis Pressemeddelelse 6. februar 2003: Videnskabsminister Helge Sander.. digital.. regeringsgrundlaget.. Danmark som førende IT-nation.. Tilbud om gratis digital til alle danskere om en måned I første omgang: selvangivelse Senere: Andre offentlige digitale tjenester Erhvervslivet kan bruge en til e-handel m.m. baseret på x.509 og andre internationale standarder 1,5 mill. har allerede homebanking-certifikat Vil du tage imod tilbuddet om gratis digital? Ja Nej Ved ikke Afstemning gentages ved afslutningen af denne kursusgang Et bud på den fundamentale problemstilling ved autentificering Anvendelighed (udvalget af tjenester) og brugervenlighed (installation, brug) Nødvendige elementer i en offentlig nøgle-infrastruktur De to vigtigste grundelementer: (1) format for certifikat (2) protokoller for autentificering x.509 er den universelt accepterede standard for (1) og (2). udarbejdet af ITU Sikkerhed (nøgle-kompromittering) Uafviselighed (hæftelse) Bemærk: Sikkerhed drejer sig her om autentificering, ikke hemmeligholdelse Yderligere krav til en brugbar, fælles dansk standard: for at sikre udbredelse (3) konkretisering af certifikatformatet navne, identifikationsnumre (4) regulering: indehavernes opførsel: nøgleopbevaring nøglecentre: tilbagetrækningslister, 24/7 regler for ens gyldighed, hæftelse

2 Værktøjer vs. anvendelser x.509s certifikat-format (forenklet) Lokal dansk konkretisering International standardisering Basale algoritmer OCES: konkretisering af format regler for indehaver, centre, gyldighed m.m. x.509: certifikat-format autentificerings-protokol Værktøjer: Hashing: SHA-1 Asymm. kryptering: RSA x.509-version Udsteder Indehavers navn Gyldighedsperiode Offentlig nøgle Indeh. Unik ID (v.2) Udvidelser (v.3) Signatur 1. Hvilken oplysning giver en? 2. Hvordan verificerer modtager den oplysning, en giver? 3. Hvorfor er der anført algoritmer (f.eks. RSA+SHA-1) i felterne både for offentlig nøgle og? x.509-version Udsteder Indehavers navn Gyldighedsperiode Offentlig nøgle Indeh. Unik ID (v.2) Udvidelser (v.3) Signatur x.509s certifikat-format (forenklet) 1. Hvilken oplysning giver en? At udsteder bekræfter sammenhæng mellem offentlig nøgle og øvrige oplysninger, herunder navn m.m. 2. Hvordan bekræftes den oplysning, en giver? Sammenligning af hashværdi af certifikatoplysninger dekrypteret med udsteders offentlige nøgle 3. Hvorfor er der anført algoritme (f.eks. RSA) i felterne både for offentlig nøgle og? Der er tale om to forskellige nøglepar Certifikatets formål set i relation til formålet med offentlige nøglesystemer Offentlig nøgle-kryptering løser nøgledistributions-problemet symmetrisk kryptering. Men: To parter som ikke kan udveksle en hemmelig nøgle, vil ofte ikke kunne være sikre på hinandens identiter m.m. Det er baggrunden for nødvendigheden af, at tredjepart (certifikatudsteder) bekræfter sammenhæng mellem offentlig nøgle og øvrige oplysninger, herunder navn m.m. Indførelsen af en tredjepart introducerer nye problemstillinger: på hvilken måde kontrollerer udsteder oplysningerne om indehaver? hvorledes genereres nøglerne? (Oveni nøgleopbevaringsproblemet (uafhængigt af krypteringsprincip) )

3 Data-autentificering "Jeg byder 10 mia for Navision. Mvh. B. Gates" "Jeg byder 10 mia for Navision. Mvh. B. Gates" Besked sendt af indehaver af (n,d) og er uændret. hash RSA "MAC"/ (n,d) Data-autentificering + personautentificering Person-autentificering "Jeg byder 10 mia for Navision. Mvh. B. Gates" "Jeg byder 10 mia for Navision. Mvh. B. Gates" Besked sendt af indehaver af (n,d) og er uændret. (n,d) indehaves B. Gates. Kunstig besked, f.eks. modtagers offentlige nøgle, tilfældigt tal, etc. Kunstig besked, f.eks. modtagers offentlige nøgle, tilfældigt tal, etc. Afsender er indehaver af (n,d). Afsenders identitet er som i certifikat. hash RSA "MAC"/ hash RSA "MAC"/ (n,d) (I stedet for certifikat kan medsendes oplysninger, som muliggør at modtager kan søge efter certifikat hos nøglecenter) (n,d) Certifikat Certifikat

4 Kursusgang 4: Autencificering med asymmetrisk kryptering. Digital i Danmark. x.509 Digital Signatur i Danmark Lars' oplæg om Lov om elektroniske er. OCES NJ: Evaluering Bo: Kursusgang 5 Synopsis Lov om elektroniske er (maj 2000) Digital efter lovens definition kan erstatte traditionel/håndskrevet ( 13). dette gælder som tilføjelse til andre loves bestemmelser om signering Alice og Bob afgør i øvrigt selv hvordan de vil signere lovændringer kan være nødvendige for specifikke områder: signeret komm. mellem forvaltning og borger/virksomhed signeret komm. indbyrdes mellem borgere/virksomheder indenfor lovregulerede område som lejerboligmarkedet Certifikater udstedes af private nøglecentre underkastet tilsyn ikke af statslig myndighed Det centrale begreb er "kvalificeret certifikat": ikke eksplicit krav om fremmøde ved udstedelse men nøglecenter erstatnings-ansvarlig for at identitet er bekræftet ingen principiel grænse for certifikatets/ens anvendelse Bekendtgørelse om sikkerhedskrav til nøglecentre (oktober 2000) Eksplicit krav om personligt fremmøde & legitimation kan fraviges hvis identitet i forvejen er nøglecenter bekendt krav om forsikring til dækning af erstatninger 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)

5 2002: OCES ("letvægts") 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 nøglecentre 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 -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. OCES Anvendelighed (udvalget af tjenester) og brugervenlighed (installation, brug) 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" Sikkerhed (nøgle-kompromittering) Uafviselighed (hæftelse) (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.

6 Indehavers hæftelse 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". 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 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 nøglepar 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 får Modstander-Mogens et generelt anvendeligt certifikat, snarere end en enkelt skrivelse el.lign. (indtil certifikatet spærres) Sikkerhed i OCES: den private nøgle Sikkerhed i OCES: den private nøgle OCES er rent software-baseret dvs. den private nøgle er lagret i en fil på brugerens PC hvorfra nøglen kan stjæles ondsindet program OCES-standarden tænkes hardwarebaseret senere Hardwarebaseret privat nøgle: nøgle lagret på særligt chipkort nøgle forlader aldrig chipkortet kryptering med nøglen foregår også internt på chipkortet Privat nøgle Symm. krypt. Krypteret privat nøgle Modforholdsregler mod tyvere af softwarebaseret privat nøgle kryptering af private nøgle passwordbeskyttelse af dekryptering/genskabelse af private nøgle OCES-standard pålægger indehaver at "tage rimelige forholdsregler" andre måde at kopiere softwarebaseret privat nøgle Password Symm. nøgle CA kan opbevare privat nøgle (som backup) efter aftale

7 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-. enten fordi F. Attigs nøgle 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-. Metode 2: Den oprindelige begæring, 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, da hashværdi ændres ved (æ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 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 nøgler 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 nøgle 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 certifikatet, der så har forskellige PID-numre, der alle peger på samme person. 1: F.Attig: Jeg vil ikke F.Attig: Jeg vil ikke have mere SU 2: have mere SU log

8 OCES Afstemning Anvendelighed (udvalget af tjenester) og brugervenlighed (installation, brug) Hvor mange vil tage imod tilbuddet fra staten / TDC om gratis offentlig til marts? Sikkerhed (nøgle-kompromittering) Uafviselighed (hæftelse) Kursusgang 4: Autencificering med asymmetrisk kryptering. Digital i Danmark. x.509 Digital Signatur i Danmark Lars' oplæg om Lov om elektroniske er. OCES NJ: Evaluering Evaluering af kursusgang 1-3 Studenteroplæg - har fungeret godt Øvelsesopgaver - Hjemmeforberedelse/entusiasme kunne være højere - Kun muligt at arbejde med småopgaver på selve kursusdagen Programmeringsopgaver? Bo: Kursusgang 5 Synopsis

9 Synopsis 1-2 studerende pr. gruppe 1-2 sider i synopsis definere problemstilling, litteraturgrundlag, og skitse af analyse af problemstilling (hovedpointer) Afleveres lige før projektintensiv periode Funktion: grundlag for mundtlig eksamen definerer problemstilling som I vil holde oplæg om og som vi derefter spørger til Forslag: Deadline for aflevering af udkast til synopsis ca. 1. april??