Digital Forvaltning 9.11.2004: Digital signatur

Digital Forvaltning 9.11.2004: Digital signatur Hvorfor autentificering? Digital signatur vs. Den fælles Pinkode Vurdering af digital signatur: infrastruktur autentificering standardisering brugervenlighed: udstedelse & opbevaring på PC brug (forvaltningen): arkivering brugervenlighed: forståelse

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

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. CPR EPJ Græsted- Gilleleje Told - Skat Sundhedsportal Virksomhedsportal forbindelse til det øvrige internet

Risiko 1: identitets-forfalskning ("maskerade") Sundhedsportal Jeg er Jens Hansen, og vil se min journal Autentificering = bekræftelse af identitet (beskyttelse mod maskerade) Krav (fundamentale og pragmatiske): sikker billig brugervenlig (let at bruge) brugbart (skal have anvendelser) ved sikkerhedssvigt: rimelige hæftelsesregler

Risiko 2: 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 3: internt misbrug Sammenkoblingen af digitale forvaltningsøer bygger på softwarebaseret adgangskontrol meget kompleks pga. antallet af systemer regler/organisationspolitikker sundhedspersonale må kun se i journaler 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

Uddybning af sikkerhedsmæssige krav til autentificering Jeg er Jens Hansen, og vil se min journal Sundhedsportal Autentificering (god, sikker a.): bekræftelse af identitet dvs. tjek af besked som indeholder: jeg er Jens Hansen + log mig på +.. Løsninger baseres på varianter af: afsender har/kender 1-2 hemmeligheder Løsning med digital signatur: afsender har privat nøgle plus password Løsning med pinkode: afsender har pinkode

Den fælles pinkode (Netborger.dk) mindst 8 tegn (tal eller bogstaver) kan ses som et password bestilles / genbestilles via nettet lige som digital signatur administreres af KMD giver adgang til en lang række offentlige og private services

Den fælles pinkode vs. digital signatur: diffusionsteori Antal brugere: Digital signatur: 150.000 (maj 2004) Den fælles Pinkode: 400.000 (januar 2004) Rogers model for diffusion: relative advantage, compatibility, complexity, trialability, observability. egenskaber ved en innovation, som kan forklare dens diffusion

Den fælles pinkode: sikkerhedsmæssige svagheder Kun 1 hemmelighed (pinkoden) angriber skal kun skaffe 1 hemmelighed Pinkoden er en delt hemmelighed kendes af KMD Sårbart over for ordbogsangreb kan ikke bruges til non-repudiation/uafviselighed Ross Andersens analyse af ATM: mange eksempler på internt tyveri/bedrageri

Services, mål i relation til it-sikkerhed Hemmeligholdelse Autentificering Integritet (beskyttelse mod ændring) Non-repudiation (uafviselighed) Tilgængelighed Adgangskontrol

Infrastruktur Jens Hansen: XYZab98n2c wlsjv CA: Certifikatudsteder +nøglecenter Jens Hansen: XYZab98n2c wlsjv Jens Hansen: XYZab98n2c wlsjv privat nøgle signeret besked (henvisning til digitalt certifikat)

Digitalt certifikat Indehavers navn m.m. Offentlig nøgle Signatur fra CA Jens Hansen: XYZab98n2cwlsjv 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 nøgle sendes ved autentificering hører sammen med hemmelig privat nøgle

Digital signatur 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 nøgle dekryptering sker med offentlig nøgle digitalt certifikat giver sammenhæng mellem offentlig nøgle og (påstået) afsender Uddybning man krypterer kun en hashværdi af beskeden hvis beskeden ønskes hemmeligholdt, krypteres den på anden vis

Infrastruktur Jens Hansen: XYZab98n2c wlsjv CA: Certifikatudsteder (+nøglecenter) Jens Hansen: XYZab98n2c wlsjv Jens Hansen: XYZab98n2c wlsjv privat nøgle signeret besked (henvisning til digitalt certifikat)

Kryptering (enkelt nøgle) krypteringsnøgle de-krypteringsnøgle = krypteringsnøgle Jens Hansens journal @jk3?!?4o8pdj Jens Hansens journal krypteringsalgoritme de-krypteringsalgoritme

enkelt nøgle vs. PKI: offentlig+privat nøgle enkelt nøgle (konventionel, symmetrisk): krypteringsnøgle = de-krypteringsnøgle hurtig upraktisk: hvordan distribuere krypteringsnøgle? offentlig+privat nøgle (to-nøgle, asymmetrisk): lettere nøgledistribution den enkelte behøver kun 1 nøglepar kun offentlig nøgle skal distribueres giver dog nyt problem: autentifikation af nøgle-indehaver fleksibilitet: kan bruges både til hemmeligholdelse og autentificering langsom

PKI: hemmeligholdelse Modtagers offentlige nøgle Modtagers private nøgle Jens Hansens journal @jk3?!?4o8pdj Jens Hansens journal Kryptering+dekryptering

PKI: autencitering Afsenders private nøgle Afsenders offentlig nøgle Jeg er Jens Hansen og vil se min journal @jk3?!?4o8pdj Jeg er Jens Hansen og vil se min journal Modtager har certifikatet, og stoler derfor på at den offentlige nøgle hører til Jens Hansen Jens Hansen: XYZab98n2cwlsjv

Autentificering - flere detaljer "Jeg er Jens Hansen og vil se min journal" "Jeg er Jens Hansen og vil se min journal" Besked sendt af indehaver af privat nøgle og er uændret. Privat nøgle indehaves af Jens Hansen hash RSA "MAC"/ signatur privat nøgle Certifikat (I stedet for certifikat kan medsendes oplysninger, som muliggør at modtager kan søge efter certifikat hos nøglecenter)

RSA (n,e) (n,d) M M e (mod n) = C C C d (mod n) = M M

RSA: lille eksempel A = 1, B = 2, C = 3, D = 4, E = 5,... Offentlig nøgle = (33,3) 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 Offentlig nøgle = (33,3) Hvad er den privat nøgle (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 Der eksisterer ikke bevis for, at der ikke findes bedre algoritmer.

Teknisk konklusion på digitale certifikater 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 nøglelængde)

Nødvendige standarder 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 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 signaturens gyldighed, hæftelse

x.509s certifikat-format (stadig forenklet) x.509-version Udsteder Indehavers navn Gyldighedsperiode Offentlig nøgle Certifikater skal bruges af email-klienter browsere af forskellig fabrikat, version m.m. Vanskeligt at få til at fungere i praksis Indeh. Unik ID (v.2) Udvidelser (v.3) Signatur

Lov om elektroniske signaturer (maj 2000) Digital signatur efter lovens definition knæsættes som metode til signering af elektroniske meddelelser ( 13). 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 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.."

Finansrådet: Høring af bekendtgørelsesudkast (sommer 2000) "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)

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." Dvs. alt 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.

MEN - her udsendes et generelt anvendeligt certifikat, snarere end en enkelt skrivelse el.lign. (indtil certifikatet spærres) 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

Sikkerhed ved personligt fremmøde Januar 2001 (jf. Forno & Feinbloom) 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: opbevaring Autentificering er baseret på et system med to hemmeligheder: Noget brugeren har: den private nøgle (i signaturfilen på PCen) Noget brugeren ved: password (som bruges til oplåsning af signaturfilen) Svarer til Finansrådets standard for netbanker

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 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 ondsindet program Privat nøgle Symm krypt. Krypteret privat nøgle Password Symm. 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 certifikateter, der så har forskellige PID-numre, der alle peger på samme person.

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. Sikkerhed: hvorledes lagres signerede dokumenter? 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 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-signatur.

IT- og Telestyrelsen anbefaler model 2 "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 2: log have mere SU have mere SU

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 1: F.Attig: Jeg vil ikke F.Attig: Jeg vil ikke signatur 2: log have mere SU have mere SU

Netbanktyveri fra Nordea (offentliggjort juni 2004) Hacker stjal 25.000 kr. fra privatkundes konto. Hackeren maskererede sig overfor Nordeas netbank som kunden Overførte 25.000 kr. til egen konto Blev opdaget fordi overførslen kunne spores Metode: kopierede signaturfil og opsnappede password (dvs. begge hemmeligh.) dette skete ved hjælp af program, hackeren havde udviklet, og lokket kunden til at installere (eller rettere, kundens søn) ved at foregive det var et brugbart program faktisk et spionprogram!!

Beskyttelse mod tyveri i netbanker Gode tommelfingerregler: (omend ikke tilstrækkelige) Forsigtighed ved download ville have forhindret tyveriet Hver bruger sit login-navn kunne principielt også have forhindret tyveriet Firewall kan stoppe dele af uønsket kommunikation Antivirus og antispyware kan identificere og fjerne kendte virus/spywareprogrammer

Lov om visse betalingsmidler 11 om Brugers hæftelse: Stk. 2: Op til 1.200 kr. hvis personlig kode er anvendt. Stk. 3: Op til 8.000 kr. hvis groft uforsvarlig opførsel har muliggjort den uberettigede anvendelse af den personlige kode. (Jeg ved ikke hvem der hæftede for de 25.000 / 8.000 / 1.200 ) Ross Anderson: Hvis bruger har ansvaret skærpes offentlig opmærksomhed og debat øges brugerens sikkerhed Hvis finansvirksomhed har ansvaret øges finansvirksomhedens sikkerhed

Netbanker: skal grænsefladen designes, så brugeren forstår sikkerheden? Høj sikkerhed kan være i konflikt med brugervenlighed stærke/svage passwords Den fælles Pinkode vs. digital signatur Målsætning for usable security (jf. Herztum et al.): Users are are reliably made aware of the security tasks they need to perform are able to figure out how to successfully perform those tasks don t make dangerous errors sufficiently comfortable with the interface to continue using it Problem: ikke muligt at forudsige/definere korrekt brugeradfærd i relation til download, firewall, m.m.

Installation af netbank Uforståelige meddelelser => brugeren opgiver at forstå hvad der foregår Forno & Feimbloom: Certifikater lette at forfalske (fx. Microsoft-certifikat) Certifikater bør derfor indeholde MAC-adresse Vil kun øge sikkerheden for den bruger som forstår oplysningen

Installation af netbank (fortsat) Stort antal koder => bruger kan miste overblikket 3-4 koder kontonummer, password, m.m. Stort antal begreber, som ofte ikke forklares => mister overblik 8-14 begreber authencitet, verifikation, signering, certifikat, sikker forbindelse, privat nøgle, signaturfil,..

Design-strategier Instruer forklar hvert skridt (bedre) manglende standardisering: umulig at forudsige fx browserbeskeder ikke tilstrækkeligt til at skabe forståelse for brug af firewall m.m. Automatiser allerede høj grad af automatisering fx af signeringsprocessen husk password uønsket browserbeskeder: kan undgås men bruger forhindres i at bruge egen, kendte browservariant Skab forståelse vanskeliggøres af stalddørs -egenskaben: trial-and-error uønsket vanskeliggøres af brugeres manglende motivering