Kursusgang 3: Digital signatur. Den danske OCESstandard. Målsætning for digital signatur. Signatur (digital & alm. underskrift) Sikkerhedsmål

Transkript

1 Kursusgang 3: Digital signatur. Den danske OCESstandard. Målsætning for digital signatur Digital Signatur Hashing x.509-certifikater Kvantekryptering Den danske OCES-standard Udveksling af tekst på en juridisk bindinde måde "Jeg byder 10 mia for Navision. Mvh. B. Gates" Signatur (digital & alm. underskrift) Sikkerhedsmål M = Besked = "Jeg byder 10 mia for Navision. Mvh. B. Gates" Hvilke sikkerhedsmål er relevante? Hvilke er de vigtigste? Knyttet til besked Bekræfter at besked kommer fra underskriver Bekræfter at besked ikke er ændret Besked Signatur Autentificering Access control Hemmeligholdelse Integritet Nonrepudiation Tilgængelighed

2 Krav til autentificering Digital signatur Vi kan acceptere, at modtager (og måske afsender) skal bruge hemmelig nøgle Krav til metode: må ikke kunne brydes på anden måde end ved udtømmende søgning længde af nøgler/hemmeligheder/hashkoder er tilstrækkelig stor til at gøre udtømmende uoverkommelig Signaturen Afhænger af besked Afhænger af nøglepar Certifikat bekræfter underskrives identitet CA bekræfter certifikats gyldighed (Certifikat Authority, certificeringscenter) Besked Signatur Certifikat CA Forenkling "Besked autentificering" I første omgang antager vi at parterne kender hinandens identitet og offentlige nøgler derfor ikke brug for certifikater og certificeringscentre Besked-autentificering besked er uændret (sv.t. integritet) kommer fra påstået afsender (sv.t. autentificering i sædvanlig forstand) MAC = Message Autentication Code betegner nøgle-baseret tekst til besked-autentificering. Besked MAC

3 Pfleeger Besked-autentificering A: A pub, A priv B: B pub, B priv A vil sende besked M til B over ubeskyttet kanal som C har adgang til. C kender begge offentlige nøgler 1) Hvorledes skal A kryptere beskeden M til B? 2) Hvorledes skal A bevise at hun er kilden til M? 3) Hvorledes skal A opnå både 1 og 2? Antag: kanalen er udsat både for aktive og passive angreb (dvs. både aflytning og modifikation) beskeden M har ikke nogen kendt struktur (fx. er M et kontonummer i binær repræsentation) eksempel: B står efter dekryptering med "xxx " A: A pub, A priv B: B pub, B priv A vil sende besked M til B over ubeskyttet kanal som C har adgang til. C kender begge offentlige nøgler Ad 2) Hvorledes skal A bevise at hun er kilden til M? A sender: (A priv (M)) M B dekypterer: M' = A pub (A priv (M)). Hvis M' = M, kan B kan stole på både besked og afsender. A priv (M) er en "MAC" OBS: Metode principielt OK men upraktisk hvis M er lang. Besked-autentificering (asymmetrisk kryptering) Besked-autentificering med digital signatur M M Besked sendt af indehaver af (n,d) og er uændret. "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. RSA A priv (M) hash RSA Signatur A priv (n,d)

4 Besked-autentificering + bekræftelse af afsenders identitet Autentificering fx. ved logon på netbank. "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 af B. Gates. Kunstig besked, fx. tilfældigt tal genereret af modtager Afsender er indehaver af (n,d). Afsenders identitet er som i certifikat. hash RSA Signatur hash RSA Signatur (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 Kursusgang 3: Digital signatur. Den danske OCESstandard. Digital Signatur Hashing x.509-certifikater Kvantekryptering Den danske OCES-standard Krav til hashfunktion Tre elementære krav - for at en hashfunktion overhovedet er praktisk brugbar: 1. variabel inputlængde 2. fast outputlængde 3. overkommelig at beregne Sammenligning med krypteringsalgoritme: Lighedspunkt: output langt nok til at forhindre udtømmende søgning lavineeffekt ønskværdig Forskel: ikke ønske om inverterbarhed ikke injektivitet kollisionsproblematik

5 Hashing ved "iterativ kompression" Blok 1 Blok 2 Blok n Krav til hashfunktion med kryptografisk styrke Tre ikke-elementære krav: For at en hashfunktions brug i autentificering ikke kan brydes med rå kraft (udtømmende søgning) fordi det vil være for tidskrævende. I.V. Kom pression Kom pression Størrelser (eksempel: SHA-1): Blokstørrelse 512 bit Størrelse af hashværdi 160 bit "Kompressions-funktion" komprimerer 512 -> 160 bit SHA-1: 80 iterationer per blok krav om kollisions-modstandsdygtighed Kom pression Hashværdi 4. envejs-egenskab: Givet h = H(x), må x ikke kunne findes. ellers afsløres den delte hemmelighed Antal nødvendige forsøg for at gætte x: ~ cirka 2 n 5. svag kollisions-modstandsdygtighed: Givet x, må man ikke kunne finde y hvor H(x) = H(y) ellers kan besked forvandskes (omend ikke arbitrært) Antal nødvendige forsøg for at gætte y: ~ cirka 2 n 6. stærk kollisions-modstandsdygtighed Der må ikke kunne findes x og y hvor H(x) = H(y). jf. fødselsdagsangreb (omend ikke arbitrær forvandskning) Kræver kun 2 (n/2) forsøg, dvs. kræver dobbelt så lang kode som man tror Krav til hashfunktioner: Svag kollisons-resistens. Svag kollisions-resistens er: Givet besked M med hashværdi H generering af besked M' med samme hashværdi H skal være uoverkommelig jævnfør det grundlæggende krav: ingen hurtigere angreb end "rå kraft" Antag hashmetode er simpel xor: M= blok 1 + blok blok m H = Hash(M) = blok 1 + blok blok m Angreb: Vi vil erstatte M med F X, hvor Hash(F X) = Hash(M) Løsning: X = Hash(M)+Hash(F) Fordi Hash(F (Hash(M)+ Hash(F) )) = Hash(F) + Hash(M) + Hash(F) = Hash(M) Kan bruges også uden kendskab til H (ved opsnapning af krypteret udgave af H)

6 Fødselsdags-angreb Modstander- Mogens modificerer Sandsynlighed for sammenfaldende fødselsdag Alices eksamensopgave Alices eksamensopgave Opgaven sendt af Alice og er uændret. Analogi: Hvad er sandsynligheden for at der i et lokale med k personer er mindst to med samme fødselsdag (f.eks. 24. februar)? Allerede med k=23 er sandsynligheden > 50%! hash RSA Signatur Morale: 64 bit hashværdi (n,d) Hvis 64 bit er nok til at sikre svag kollisions-modstandsdygtighed, skal der bruges 128 bit til at sikre stærk kollisions-modstandsdygtighed. Fødselsdagsangrebet: fremgangsmåde Modstander-Mogens' forfalskede besked er F Alice giver Modstander-Mogens et udkast M Modstander-Mogens genererer: en variation M' af M der for Alice ser acceptabel ("forbedret") ud en variation F' af F der for Mogens er acceptabel som forfalsket besked således at M' og F' har samme hashværdi H Alice sender M' med krypteret udgave af hashværdi H Modstander-Mogenserstatter undervejs M' med F' Hvis Modstander-Mogens alene varierer M, kræves ca forsøg Hvis Modstander-Mogens varierer både M og F, kræves kun ca forsøg Kursusgang 3: Digital signatur. Den danske OCESstandard. Digital Signatur Hashing x.509-certifikater Kvantekryptering Den danske OCES-standard

7 Forudsætningere for PKI PKI (offentlig nøgle-infrastruktur) er i sig selv kun et princip jf. Pfleeger s. 437: ".. room for interpretation". Oprettelse af certifikat (og annullering) Registreringsenheder Certificeringscentre Elementer i en offentlig nøgleinfrastruktur Kontrol af certifikat (1) Format for certifikat x.509 er den universelt accepterede certifikatstandard udarbejdet af ITU men er kun en generel ramme OCES-standard konkretiserer certifikatformatet navne, identifikationsnumre Almindelige certifikatindehavere (borgere) Dig. signatur + certifikat Serviceudbydere (fx. digital forvaltning) (2) Statslig regulering (love, cirkulærer m.m.) regler for signaturens gyldighed, hæftelse nøglecentre: tilbagetrækningslister, 24/7 indehavernes opførsel: nøgleopbevaring (3) Standarder for brug af signatur/certifikater Autentificering, krypteret mail, m.m. 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 signaturen? 2. Hvordan verificerer signaturmodtager den oplysning, signaturen giver? 3. Hvorfor er der anført algoritmer (f.eks. RSA+SHA-1) i felterne både for offentlig nøgle og signatur?

8 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 signaturen? At udsteder bekræfter sammenhæng mellem offentlig nøgle og øvrige oplysninger, herunder navn m.m. 2. Hvordan bekræftes den oplysning, signaturen giver? Sammenligning af hashværdi af certifikatoplysninger signatur 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 signatur? 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 ved 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? RSA: Generering af nøglepar Kursusgang 3: Digital signatur. Den danske OCESstandard. 1. Find to primtal p og q af passende størrelse (fx 512 bits) (p <> q) 2. Udregn n = p*q 3. Udregn f(n) = (p-1)(q-1) 4. Den offentlige nøgle er (n,e) hvor: 1 < e < f(n) gcd(e,f(n)) = 1 5. Den private nøgle er (n,d), hvor: e*d mod f(n) = 1 Digital Signatur Hashing x.509-certifikater Kvantekryptering Den danske OCES-standard

9 Kursusgang 3: Digital signatur. Den danske OCESstandard. Digital Signatur Hashing x.509-certifikater Kvantekryptering Den danske OCES-standard Lov om elektroniske signaturer (maj 2000) Der står ikke at elektronisk signatur er ligeså bindende som håndskrevet signatur. det må komme an på domstolspraksis men kun at elektronisk signatur i lovens forstand opfylder andre loves krav til elektronisk signering 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/signaturens 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)

10 2002: OCES ("letvægtssignatur") 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 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 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.

11 Sikkerhed i OCES: udstedelse via CPR Sikkerhed i OCES: den private nøgle 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 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) OCES er rent software-baseret dvs. den private nøgle er lagret i en fil på brugerens PC hvorfra nøglen kan stjæles 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 Modforholdsregler mod tyveri 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" CA kan opbevare privat nøgle (som backup) efter aftale Sikkerhed i OCES: den private nøgle OCES - "lille borgerkort" Privat nøgle Fjern angriber Symm. krypt. Mange muligheder for tyveri af "signaturfil" Krypteret privat nøgle Ethvert OCES-certifikat kan knyttes til det CPR-nummer, der blev opgivet ved dets oprettelse. 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). Password Symm. nøgle Bemærk: Samme person/cpr-nummer kan have flere certifikater, der så har forskellige PID-numre, der alle peger på samme person.

12 Afslutning: hvad skal vi med OCES?? Mulige eksamensspørgsmål Hvad er fordele og ulemper ved at bruge en 10-cifret PIN-kode i stedet for digital signatur? Dvs. hver borger får sendt en 10-cifret PIN-kode bruges til autentificering over for det offentlige svarer til cpr-nummer men hemmelig Svarer til KMDs "fælles PIN-kode" udstedt til borgere bruges til logon på e-boks Gør rede for hvorledes kryptering kan bruges til besked-autentificering. (Dvs. message authentication; der tænkes ikke offentlig nøgleinfrastruktur med certifikater m.m.). Gør rede for principperne i offentlig nøgleinfrastruktur Gør rede for OCES-standarden