NemID-hader udstiller elendig phishingbeskyttelse

Manden bag protest-sitet nejtilnemid.dk udstiller manglende phishingbeskyttelse af nemid.nu ved at købe domæner, der ligner siden og lave et falsk loginmodul, hvor brugeren kan indtaste brugernavn og kode.

NemID-haderen Rasmus Porsager har købt domæner, der ligner nemid.nu og lavet hjemmesider, der ligner NemID's hjemmesider , hvor brugerne kan indtaste brugernavn og kodeord, dog uden at oplysningerne bliver sendt videre.

DanID har netop offentliggjort en advarsel imod de falske nemidsider nemId.dk og nemId.nu (hvor det store I i virkeligheden er et lille L, red.) er erstattet af på sin rigtige hjemmeside og advaret imod phishing. Domænerne tilhører imidlertid Rasmus Porsager, der også står bag siden nejtilnemid.dk, hvor han samler underskrifter ind imod den fælles loginløsning.

Aktionen fra Rasmus Porsagers side går ud på at udstille, at firmaet DanID, der står bag NemID, ikke har købt alle de domæner, der ligner nemid.nu. Dermed er nemid.nu åbent for phishingangreb, hvor cyberkriminelle kan oprettet falske hjemmesider og forsøge at franarre brugerne deres brugernavn og kodeord.

Rasmus Porsager har skrevet en mail til DanID, som han har videresendt til Version2. Her skriver han følgende:

»Siden vil aldrig kunne gøre nogen skade ved jeres systemer, men nærmere gøre jer opmærksomme på et svagt punkt«

Rasmus Porsager oplyser i øvrigt, at hans falske sites aldrig har kunnet videresende nogen oplysninger, hvis brugere skulle have indtastet deres brugernavn og kodeord på hans sites.

Derudover oplyser han, at han frivilligt vil overføre domænerne til DanID, hvis de ønsker det, nu da han har demonstreret sin pointe.

DanID's kommentar:

Læs også: DanID efter phishing-aktivisme: Falsk domæne er ligegyldigt

Tips og korrekturforslag til denne historie sendes til tip@version2.dk

Kommentarer (68)

Jesper Kristensen

Hvorfor bruger han domæner der lægger sig op ad NemIDs "rigtige" domæner? NemID er jo netop lavet sådan at man skal indtaste sine loginoplysninger på websteder med alle mulige identiteter fra "nemid.nu" (DV) til "Oekonomistyrelsen (DK)" (EV), "danskebank.dk" (DV) osv. Så der er ingen grund til at efterligne nogen domæner, hvis man vil phishe NemID.

Rasmus Kaae

En anden ting er, at man som alm. it-kyndig kan undre sig over at DanID har valt navnet NemID når det åbenlyse domænenavn er optaget (læs: nemid.dk)

Så vidt jeg kan se tilhører det domæne et firma ved navn Assemble som har et produkt til offentlige institutioner som hedder NemID.

Jonathan Hansen

Det er enormt uheldigt, at nemid-login-systemet er baseret på Java, der bliver embedded direkte i de enkelte tjenesters eget website.

Jeg fatter virkelig ikke, at NemID ikke er baseret på OpenID-protokolen. Hvis det var, så skal DanID bare agere specifik OpenID-udbyder. Så vil alt login foregå på nemid.nu-domænet, og derved skal man blot holde øje med nemid-SSL-certifikatet i sin browser for at vide, at man er sikker.
På den måde ville Java blive overflødiggjort, og så ville det sørme også være en smal sag, at understøtte login fra mobile enheder, hvilket pt. ikke er muligt med det nuværende SlemID!

Thomas Bundgaard

Det kan nævnes, at der var en eller anden (Rasmus selv, måske?) der postede følgende:

"Jeg har netop set at NemID har givet mulighed for et alternativ til papkortet i form af en digital løsning.
Skynd jer ind og bestil via deres selvbetjening på http://NemlD.nu/ "

Siden er nu blevet ændret til en redirect til nejtilnemid.dk, men i nat/i morges var der en fuldstændig kopi af NemID's hjemmeside med en login-boks i midten. Der må være blevet overtrådt en del copyright der.

lille tilføjelse:
Jeg var lige ved at blive snydt. Det var faktisk først, da jeg begyndte at klikke mig rundt på siden, jeg fandt ud af at det var et scam. Man kunne nemlig ikke, da hele siden var bygget op omkring et baggrundsbillede, og så en java-boks i midten :)

Jesper Louis Andersen

Nu har der snart været så megen snak om NemID og Java - og igen vil jeg lige referere til at Danske Banks apps til iPhone og Android ikke brugere Java.

På iOS/iPhone benyttes der formentlig Obj-C som Apple vil have det. På Android benyttes der formentlig Java - eftersom stort set hele den del af platformen du ser er Java-baseret. På begge platforme er det dog muligt at eksekvere native-kode så man kan i princippet sagtens skrive koden i et andet sprog (C eller C++ i det her tilfælde).

Jesper Hedemann

Hvorfor er der ikke snart nogen der griber ind og siger til DanID, at de skal lave lorte om.

Det har jo en masse fejl, og er for nemt at knække.
også er det alt for nemt og stjæle oplysninger.

Tror dette er DanID's Windows vista/ME

Baldur Norddahl

Jeg synes tværtimod Rasmus har gjort DanID en tjenste og lidt god reklame. Han beviser nemlig styrken med papkortet via hans såkaldte phishing forsøg.

Han har nok ikke nosser til at implementere resten. Det han kunne gøre er at skrive et lille program som logger ind på en kendt netbank. Det er ganske simpelt:

1) spørg efter login og kodeord på phising site.
2) brug login og kodeord på netbank. Aflæs kodespørgsmål fra netbank.
3) vis kodespørgsmål på phising site. Modtag kodesvar fra papkort.
4) brug kodesvar til at gennemføre login på netbank.

Jeg vil dog ikke anbefale at man forsøger skrive et sådant program. Det er nok noget med at tilbringe et betragteligt antal dage bag tremmer, også selvom det bare var ment som en "demo".

Måske man kan skrive et program som udfører nævnte funktion lokalt på brugerens computer, således at man kan bevise at man ikke har haft "offerets" bankdetaljer forbi egen server. Det vil dog kræve en signed java applet som brugeren skal godkende, ellers kan man ikke tilgå trediepartsservere.

Klaus Johansen

Til Rasmus Kaae:

Det er korrekt at Danske Bank's applikationer IKKE bruger Java. Det skyldes, at bankerne har deres egen snabel ind i DanID's systemer, så bankerne kan lave deres eget login-dialog og videreformidle nøglekort-udfordringen til bank-kunden. (Man kan diskutere om det i øvrigt ikke øger risikoen for et man-in-the-middle-angreb yderligere).

Desværre kan denne metode kun anvendes indenfor finans-sektoren. Det betyder at alle andre sites (Skat, E-boks osv.) er afhængige af Java-applet'en og derfor ikke kan bruges på mobile enheder.

For yderligere info se afsnittet om "To motorer" her: http://epn.dk/teknologi2/computer/sikkerhed/article2115607.ece

Baldur Norddahl

Tjaeh det kræver jo så at den java applet som man skriver er i stand til at snakke med DanID, hvis det er muligt så er man kommet et skridt nærmere.

Nej, det bruger man selvfølgelig DanIDs egen applet til.

Det er der mange måder at gøre på. Den mest primitive er en afrikaner der manuelt taster ind i DanIDs system. Dernæst er der "screen scraping" - altså aflæse skærmbilledet automatisk. Og endelig så kan man jo bruge en alternativ class loader på deres applet til at indskyde dit egen input og output. Det sidste er faktisk ret nemt når nu det er java.

Mathias Mejborn

Men igen, det er jo brok for brokkens skyld. Hvad skulle der til med den gamle løsning hvor man havde nøglen liggende selv? Der skulle en 16 årig dreng bare hente en trojaner på nettet også havde han adgang til netbanken.
Hvorfor indser man bare ikke at det her er et skridt i en mere sikker retning?

Baldur Norddahl

Hvad skulle der til med den gamle løsning hvor man havde nøglen liggende selv?

Selvom der tilsyneladende er en del der tror det, så er den gamle løsning rigtig nok heller ikke god nok mere. Det er for let at stjæle en nøglefil.

Men i stedet for et papkort har vi brug for en elekronisk token, som ikke kan hackes eller immiteres.

For eksempel den her, som blev foreslået af en anden debatør: http://www.ftsafe.com/products/interpass.html

Den har et display, som f.eks. kan vise at man nu er i gang med at logge ind på netbanken. Så ved man at der er noget galt, hvis man nu befinder sig på en helt anden side.

Det eneste jeg kunne ønske mere er at de kombinerede den med den her: http://www.ftsafe.com/products/biopass.html

Mathias Mejborn

Jeg er helt enig Baldur, men det er et skidt i den rigtige retning og den her løsning har været billigere at implementerer end en fysisk token og er mere sikker end den gamle løsning, så jeg kan ikke se problemet.

Nu er sikkerhed jo ikke til for sikkerhedens skyld men for forretningens og hvis forretningen mener at de godt kan leve med den risiko der er ved at bruge papkort fremfor sådan en fysisk token du henviser til, så er det vel ok?

Men ud fra ratings er på sitet så kan jeg godt se at man ikke må synes godt om DanID....

Anonym (ikke efterprøvet)

Nu er sikkerhed jo ikke til for sikkerhedens skyld men for forretningens og hvis forretningen mener at de godt kan leve med den risiko der er ved at bruge papkort fremfor sådan en fysisk token du henviser til, så er det vel ok?

NEJ - for dem som har blot et minimum af indsigt i økonomi, så kræver konkurrence og innovation at sikkerhed FØRST OG FREMMEST tager udgangspunkt i KUNDENS sikkerhed.

Det er kunderne som driver markederne som driver innovationen som driver effektivisering så vi opbygger velstand og har råd til at finansiere velfærd.

Præcis derfor er One key the mest stupide man overhovedet kan gøre. Det fører til garanteret sammenbrud både sikkerhedsmæssigt og økonomisk.

Kunden er IKKE en trussel mod virksomheden og staten. One key overfører ALTID kontrollen fra borger til system og dermed er der ikke sikkerhed for nogen og samfundsøkonomien trækker skævt.

Problemet er at staten svigter sine primære opgaver. I stedet for at understøtte samfundet, så prøver man at detailstyre samfundet - den form for planøkonomi er selve årsagen til Danmarks deroute.

Carsten Nielsen

En hurtig tanke.
I kontantautomaten kan jeg hæve penge med mit bankkort vha. en 4-cifret kode.
Hvis man kunne gøre det samme på en computer til netbank, kreditforening, skat eller kommune osv., så ville det vel være ligeså sikkert.
Computeren skulle self. bygges til det eller via en USB-kortholder.
Men det er måske bare mig, der vrøvler.

Mathias Mejborn

NEJ - for dem som har blot et minimum af indsigt i økonomi, så kræver konkurrence og innovation at sikkerhed FØRST OG FREMMEST tager udgangspunkt i KUNDENS sikkerhed.

Jeg tror vi taler forbi hinanden Stephan, ellers så udtrykker jeg mig bare ikke klart nok :)
Selvfølgelig drejer det sig om kundens sikkerhed, men kun til en vis udstrækning, det skal nemlig kunne forsvares økonomisk. Hvis man mener at papkortet har tilstrækkelig sikkerhed fremfor en anden slags token (den der henvises til i debatten), så er det fordi at man vel har overvejet prisen på papkortet kontra prisen på den anden token og blevet enige om at man godt kan leve med den risiko som forskellen imellem de to giver?

Carsten Kanstrup

Nej. Din idé med en kortholder til computeren er faktisk ret genial og langt smartere end det besværlige papkort - forudsat naturligvis at chippen yder samme sikkerhed som engangsnøglerne.

Så mangler vi bare at erstatte det tåbelige terminalinterface til chippen med et berøringsfrit nærfelt interface, så kortet kan blive meget mere robust og frem for alt vandtæt. Man behøver så ikke engang at tage kortet op af lommen eller tasken. Når man indtaster en 6-cifret kode (bedre end 3 forsøg med 4 cifre), skal der udsendes et signal, der får kortet til at svare, hvis koden er rigtig (kortet skal være "usynligt" indtil da). Et sådant kort kunne også bruges til dørlås, billås etc., så man bl.a. ikke havde de sædvanlige problemer på stranden om sommeren; men ganske simpelt kunne tage kortet med i vandet.

Ak ja. Hvor kunne det være smart, hvis bankerne, PBS og NemID gad tænke sig om. Selvfølgelig vil det kræve en ny infrastruktur med nye terminaler; men man kunne godt udfase over en årrække. Det krævede jo også nye fjernsyn eller settop bokse at gå over til digital TV; men skridtet skal jo tages på ét eller andet tidspunkt, hvis man ikke skal fortsætte med stenalderteknologi.

Jesper Poulsen

Selvfølgelig drejer det sig om kundens sikkerhed, men kun til en vis udstrækning, det skal nemlig kunne forsvares økonomisk.

NEJ!

Det gælder kundens sikkerhed - PUNKTUM!

Mathias Mejborn

NEJ!

Det gælder kundens sikkerhed - PUNKTUM!

Ja i utopia, men nu er det sådan et der endnu ikke er fundet muligheden for at gro pengetræer, så sikkerhed vil ALTID være en afvejning af en risiko man er villig til at løbe kontra pris på løsningen!

Vijay Prasad

Ja i utopia, men nu er det sådan et der endnu ikke er fundet muligheden for at gro pengetræer, så sikkerhed vil ALTID være en afvejning af en risiko man er villig til at løbe kontra pris på løsningen!

Et tænkt eksempel; Gætter du på at DanID's udviklings-timer på NemID koster mere eller mindre end at tage en open source implementation af PKI (Som rigtigt mange klienter allerede understøtter direkte) ?

(Jeg advokerer ikke for PKI specifikt, mere som dagens state-of-the-art)

Mvh,

Mathias Mejborn

Et tænkt eksempel; Gætter du på at DanID's udviklings-timer på NemID koster mere eller mindre end at tage en open source implementation af PKI (Som rigtigt mange klienter allerede understøtter direkte) ?

Jeg gætter på DanID's løsning har kostet mere.

Baldur Norddahl

Et tænkt eksempel; Gætter du på at DanID's udviklings-timer på NemID koster mere eller mindre end at tage en open source implementation af PKI

Hvad er det for en open source PKI løsning som man uden udvikling kan rulle ud til 5 millioner danskere?

Det skal være brugervenligt så selv den største it-analfabet kan finde ud af det. Der må ikke være nogle svære ord eller koncepter. Husk at NemID bliver kritiseret for at være for svært.

Jesper Poulsen

Jeg gætter på DanID's løsning har kostet mere.

Er det så rimeligt at det er noget juks af rang der ikke beskytter kunderne (dig og mig) ordentligt?

Især ikke når det kunne gøres godt (og rigtigt) for langt færre penge!?

Jesper Poulsen

Ja i utopia,

Nej, i et frit marked med dagens åbne teknologi. Det er muligt og det er oven i købet muligt at gøre det billigere end det klyt DanID har stykket sammen.

TDC's Digitale Signatur var både bedre og billigere end NemID.

Mathias Mejborn

TDC's Digitale Signatur var både bedre og billigere end NemID.

Det kan godt være den var bedre og billigere (hvad kostede den?) men mere sikker var den ikke!

Per Hansen

Det er ikke så relevant om DanID's såkaldte digitale signatur er dyrere eller billigere end TDC's løsning, men mere sikker er den IKKE!

Hvis DanId bliver kompromitteret er ALLE danskere udsat for angreb på både netbank og identitetstyveri.
Det kan på ingen måde kaldes sikkert, men sjusket omgang med borgernes data, ejendomme og værdier!

Mathias Mejborn

Det kommer an på hvordan man vælger at se på det. Hvis man ser tilbage til dengang før NemID så var danske netbanker ret udsatte fordi at hr. og fru danmark ikke formået at beskytte deres computere imod diverse trojanske heste. Det var væsentligt nemmere at gennemfører et angreb mod danske netbanker før NemID!

Mit bud er at nøglerne ryger på en CRL liste hvis DanID bliver komprommitteret, worst case så skal alle have en ny nøgle.

Baldur Norddahl

Hvis DanId bliver kompromitteret er ALLE danskere udsat for angreb på både netbank og identitetstyveri.

Nej, for nøglerne er krypteret på en måde, så DanID ikke kan dekryptere dem uden at kende dit kodeord.

Ja, fordi enhver CA er en "trusted third party" hvilket vil sige at de kan lave nye nøgler. Det gælder også den gamle TDC løsning. Hvis rodnøglen bliver stjålet så er vi på den.

Marc Munk

Nej, for nøglerne er krypteret på en måde, så DanID ikke kan dekryptere dem uden at kende dit kodeord.

Aha... Det har desværre ikke meget hold i virkeligheden. Hvilket du burde vide hvis du har fulgt debatten her på version2.dk hvor svaret til folketinget har været linket til en del gange efterhånden...

http://www.ft.dk/samling/20072/almdel/uvt/spm/219/svar/574868/601811.pdf

Anonym (ikke efterprøvet)

Baldur skrev
Nej, for nøglerne er krypteret på en måde, så DanID ikke kan dekryptere dem uden at kende dit kodeord.

At knække passwords er en simpel operation som kan automatiseres, dvs. det er Security By Obscurity.

Baldur skrev
Ja, fordi enhver CA er en "trusted third party" hvilket vil sige at de kan lave nye nøgler. Det gælder også den gamle TDC løsning. Hvis rodnøglen bliver stjålet så er vi på den.

Hold nu op med at gentage den forsimplede betragtning. Den er tilbagevist - med behørig omhu kan man blokere for CAs misbrug ved at udstedet nye nøgler.

a) Gamle relationer skal beskyttes af formålsspecifikke authentikeringsnøgler som KUN borgeren kender.

Herunder bør man slet ikke kunne bruge identifikation til at finde de relationer som vedører borgeren. Hvis databasen ikke indeholder identificerende information, så kan en angriber ikke vide hvilken identitet som skal stjæles for at kunne overtage ejerskabet.

b) Nye relationer skal beskyttes ved at sikre transparans på Identifikationscertifikater.

Hvis CA ikke kan udstedet og bruge et nye certifikat i dit navn uden at publicere det så du kan vide det, så vil CA ikke kunne omgå sikkerheden. Det forudsætter at INGEN må acceptere en Digital Signatur som ikke kan verificeres uden at man kan se forskel på om det er borgeren eller en service provider som verificerer nøglen. I praksis er broadcast mekanismer bedst hertil.

Endvidere bør borgeren ved oprettelse af en Digital Signatur generere en asymmetrisk autentifikationsnøgle som skal godkende oprettelse af nye nøgler for dermed at sikre at når først borgeren er indrulleret, så er kontrollen over den pågældende identitet endeligt overgået til borgeren.

Den eneste måde reelt at beskytte mod man-in-the-middle er at borgeren verificerer transaktionen visuelt i den tamper-resistente device som beskytter de private nøgler - både de formålsspecifikke OG de certificerede.

For så vidt angår diskussionen i øvrigt, så overser de fleste at hovedproblemet med PKI er at man ikke har tænkt sikkerhed i standarden. Den fokuserer kun på at identificere og det er både kilden til alle sikkerhedsproblemer og selve hovedårsagen til at systemer gøres planøkonomiske og dermed ikke effektiviseres over tid.

Dette paper er en rimelig introduktion for nybegyndere
http://conf.isi.qut.edu.au/auscert/proceedings/2005/josang05user.pdf

Specifikke kommentarer

Mathias skrev
Selvfølgelig drejer det sig om kundens sikkerhed, men kun til en vis udstrækning, det skal nemlig kunne forsvares økonomisk. Hvis man mener at papkortet har tilstrækkelig sikkerhed fremfor en anden slags token (den der henvises til i debatten), så er det fordi at man vel har overvejet prisen på papkortet kontra prisen på den anden token og blevet enige om at man godt kan leve med den risiko som forskellen imellem de to giver?

Selvfølgelig har man ikke absolut sikkerhed, men du skal ikke se sikkerhed som en en-dimensionel størrelse.

Den kritiske forskel er om kontrollen ligger hos borgeren eller i systemet - hvilket BÅDE kræver at borgeren kontrollere de private nøgler OG at borgeren IKKE er identificeret overfor systemet.

Problemet er IKKE papkortet, men NemId online og navnlig de ikke-interoperable systeminterfaces som ødelægger sikkerheden i alle services.

Ved at lave en ufleksibel klient-side nøgle som man skal betale for uden at åbne op for noget, så gør man reelt fra asken i ilden.

Når man først har hardkodet dette bliver det endnu sværere og endnu dyrere at lave noget som virker.

Selve kommunikationsstandarden skal ADSKILLES fra hardware, så mange typer hardware og kommunikationsprotokoller kan levere. Det er det nemme.

Det svære er at løfte service-interfacet og gøre det tilstrækkeligt interoperabelt fordi de eksisterende identitets"standarder" og navnlig den måde staten laver sine egne proprietære version som kræver f.eks. cpr-nummer eller gatekeepere er lavet for at ligge kontrollen serverside, hvor den absolut ikke må ligge.

Baldur Norddahl

a) Gamle relationer skal beskyttes...
b) Nye relationer skal beskyttes...

Det er fint at du mener at have opfundet et system som er sikkert. Men det gamle TDC system, som jeg omtaler, har ikke disse foranstaltninger.

Derudover har du ikke gennemtænkt de angrebsmuligheder der er. Det er faktisk ikke muligt at sikre sig imod CA. Hvis det var, ville vi slet ikke have brug for CA (vi kunne bare alle være vores egen CA).

Det system du beskriver er ikke nyt. Det bruges for eksempel af ssh protokollen. Men den er sårbar første gange man etablere en forbindelse og også sårbar når en servernøgle udskiftes eller når du tager en ny klient i brug, som ikke kender serverens identitet endnu.

Baldur Norddahl

Aha... Det har desværre ikke meget hold i virkeligheden. Hvilket du burde vide hvis du har fulgt debatten her på version2.dk hvor svaret til folketinget har været linket til en del gange efterhånden...

Hvad mener du? Der står netop i det link, som du henviser til, at det ikke er teknisk muligt for DanID at dekryptere uden at "aflure" folks kode. "Aflure" betyder at de må vente indtil at "offeret" logger ind næste gang, hvorefter de må logge den indtastede kode. Der står også at det trick vil virke, også selvom du har lavet din egen nøgle (som f.eks. den gamle digitale signatur) idet de bare kan modificere java applet'en til at kopiere nøgle og kode over til dem.

Jeg svarede på hvad der vil ske hvis nogen fik fat i databasen med samtlige krypterede nøgler. Her har hackeren ikke nogen mulighed for at "aflure" og databasen er i princippet værdiløs. Dog er det korrekt, at det vil være muligt at bruteforce nøgler som er beskyttet med (for) simple kodeord. Men det er man jo selv herre over. Min nøgle får de ikke dekrypteret på den måde.

Marc Munk

Hvad mener du? Der står netop i det link, som du henviser til, at det ikke er teknisk muligt for DanID at dekryptere uden at "aflure" folks kode. "Aflure" betyder at de må vente indtil at "offeret" logger ind næste gang, hvorefter de må logge den indtastede kode. Der står også at det trick vil virke, også selvom du har lavet din egen nøgle (som f.eks. den gamle digitale signatur) idet de bare kan modificere java applet'en til at kopiere nøgle og kode over til dem.

Læs og forstå ad 1. Specielt det på toppen af side 3. Jeg har copy/pasted her her under så vi alle er enige om hvad det er vi skal læse og forstå...

Det bemærkes, at hvis DanID ved lov eller en
dommerkendelse blev tilpligtet at skabe adgang til
anvendelse af en borgers digitale signatur, ville DanID ved at omgå de etablerede tekniske og proceduremæssige sikkerhedsforanstaltninger gennem modificering af den etablerede løsning kunne muliggøre afluring af borgerens personlige kode, som efterfølgende kan anvendes til aktivering af borgerens digitale signatur eller dekrypteringsnøgle.

Skal vi fortsat sige at vores private nøgler er beskyttet mod misbrug eller skal vi sige det som det er..?

Baldur Norddahl

Det bemærkes, at hvis DanID ved lov eller en
dommerkendelse blev tilpligtet at skabe adgang til
anvendelse af en borgers digitale signatur, ville DanID ved at omgå de etablerede tekniske og proceduremæssige sikkerhedsforanstaltninger gennem modificering af den etablerede løsning kunne muliggøre afluring af borgerens personlige kode, som efterfølgende kan anvendes til aktivering af borgerens digitale signatur eller dekrypteringsnøgle.

Og på hvilken måde mener du at dette er forhindret med den gamle digitale TDC signatur?

"modificering af den etablerede løsning" betyder at de kan ændre den java-applet som kører i din browser, således at den hemmeligt sender dit kodeord til DanID. Noget den normalt ikke gør. TDCs digitale signatur bruger også en java applet, som tilsvarende kan modificeres til at gøre nøjagtigt det samme.

Marc Munk

Og på hvilken måde mener du at dette er forhindret med den gamle digitale TDC signatur?

Jeg har ikke udtalt mig om hvorvidt den gamle løsning var bedre..? Hvis du mener det er tilfældet må du gerne vise mig hvor det er så vi kan få afklaret evt miståelser.

Baldur Norddahl

Jeg har ikke udtalt mig om hvorvidt den gamle løsning var bedre..? Hvis du mener det er tilfældet må du gerne vise mig hvor det er så vi kan få afklaret evt miståelser.

Du har responderet på et svar på et indlæg, som sammenligner med TDC. Helt præcist stod der:

Det er ikke så relevant om DanID's såkaldte digitale signatur er dyrere eller billigere end TDC's løsning, men mere sikker er den IKKE!

Faktisk er sikkerheden omkring nøgler nok lidt bedre med NemID da det er sværere for malware at stjæle selve nøglen. NemID har nogle issues omkring man-in-the-middle som jeg mener er helt uacceptable. Så jeg vil mene at svaret er "både og".

Men bare for god ordens skyld, hvad mener du så vil være bedre?

Marc Munk

Du har responderet på et svar på et indlæg, som sammenligner med TDC. Helt præcist stod der:

Fair nok. Men hvis du ser på mit første indlæg så har jeg klippet en bid ud og spurgt til den del.

Faktisk er sikkerheden omkring nøgler nok lidt bedre med NemID da det er sværere for malware at stjæle selve nøglen. NemID har nogle issues omkring man-in-the-middle som jeg mener er helt uacceptable. Så jeg vil mene at svaret er "både og".

Malware problemet er minimalt i forhold til hvad du ellers lukker op for af misbrug vem nemid løsningen.

Men bare for god ordens skyld, hvad mener du så vil være bedre?

Der er kommet en del gode forslag her i tråden. Det optimale ville jo være at vi selv stod for oprettelse af vores nøgler. Hvis man af en eller anden besynderlige grund ikke mener det er muligt for alle så kunne det være lækkert med valgmuligheden for dem der kan.

Og skulle jeg vælge mellem digital signatur og sso løsningen ville jeg vælge ds. Selvom den også har de problem at jeg ikke kan være sikker på at jeg har den eneste private nøgle.

Baldur Norddahl

Malware problemet er minimalt i forhold til hvad du ellers lukker op for af misbrug vem nemid løsninge

Det er så her at vi er helt uenige. Jeg mener at de primære skurke netop er banditer, som vil bruge malware, sikkerhedshuller i din browser og flash, falske websites og så videre. De vil bruge alle disse værktøjer til at stjæle din identitet, så de kan stjæle dine penge, optage lån i dit navn og hvilken øvrige profit de nu kan få ud af det.

Derimod ser jeg ikke myndighederne som en særlig relevant skurk. Uanset hvilket system vi vælger, så har vi i sidste ende brug for at myndighederne garanterer for din identitet. Det er jo hele pointen. Hvis vi kan leve uden denne garanti kan vi bare bruge GPG og ignorere enhver form for digital signatur som myndighederne måtte finde på.

Der er kommet en del gode forslag her i tråden. Det optimale ville jo være at vi selv stod for oprettelse af vores nøgler. Hvis man af en eller anden besynderlige grund ikke mener det er muligt for alle så kunne det være lækkert med valgmuligheden for dem der kan.

Men så er jo vi netop tilbage til TDC løsningen, som jo lod dig lave din egen private nøgle. Det giver IKKE den ekstra beskyttelse, som du forventer. Selvom du selv har lavet din nøgle, så kan den nemt stjæles både af banditter og af myndighederne.

Det er derfor jeg er stor fortaler for at nøglen skal ud på en USB token, hvorfra nøglen aldrig kan indlæses igen. Det skal ikke være valgfrit. Derfor skal du ikke bare kunne lave din nøgle selv, da vi så ikke kan vide om du gør det ordentligt (*). Men det kan godt være, at enhver producent af USB tokens skal kunne ansøge om at få deres produkt godkendt, således at du kan vælge den der passer dig bedst.

(*) jeg er ikke bange for om du specifikt laver noget hø med din nøgle. Den vil såmænd være dit eget problem. Men jeg er bange for at nogen laver et dårligt program, som pludseligt bliver meget populært, således at en stor del af befolkningen sider med usikre nøgler. Tænk på skandalen med de usikre SSH nøgler i Debian - du stoler 100% på ham der har lavet dit program, og du har intet at have den tillid i. Det er en plausibel angrebsvinkel for svindlere.

Jesper Poulsen

Og på hvilken måde mener du at dette er forhindret med den gamle digitale TDC signatur?

Alene det faktum at den gamle digitale signatur fra TDC var/er [u]ægte[/u] PKI. Det ville kræve et dataindbrud at skaffe sig mulighed for tilsvarende adgang.

Baldur Norddahl

Alene det faktum at den gamle digitale signatur fra TDC var/er ægte PKI. Det ville kræve et dataindbrud at skaffe sig mulighed for tilsvarende adgang.

Det vil kræve nøjagtig det samme, som det DanID må gøre for at "aflure" din kode med NemID. Og det er trivielt. Uanset hvad du kalder det.

Marc Munk

Det er så her at vi er helt uenige. Jeg mener at de primære skurke netop er banditer, som vil bruge malware, sikkerhedshuller i din browser og flash, falske websites og så videre. De vil bruge alle disse værktøjer til at stjæle din identitet, så de kan stjæle dine penge, optage lån i dit navn og hvilken øvrige profit de nu kan få ud af det.

Det er jo også blevet ualmindelig meget lettere nu hvor de kun skal bruge en nøgle. Før kunne de måske slippe afsted med min netbank nøgle og kode men så fik de kun adgang til min netbank. Der ud over skulle de hvis jeg havde en digital signatur også kopiere den og min kode.

Derimod ser jeg ikke myndighederne som en særlig relevant skurk. Uanset hvilket system vi vælger, så har vi i sidste ende brug for at myndighederne garanterer for din identitet. Det er jo hele pointen. Hvis vi kan leve uden denne garanti kan vi bare bruge GPG og ignorere enhver form for digital signatur som myndighederne måtte finde på.

Det kunne da været lækkert hvis vi bare kunne ignorerer deres tåbelige påfund. Vi har iøvrigt ingen digital signatur her i landet der ikke er under udfasning...

Jeg er så heller ikke så bekymret for at myndighederne er skurken. Jeg er bekymret for hvad der sker den dag nemid ikke kan stå imod angrebene mere. Og enhver der har taget it-sikkerhed 101 ved at den dag kommer og man skal planlægge efter det. Det gøres sgu da ikke ved at lave en central løsning.

Men så er jo vi netop tilbage til TDC løsningen, som jo lod dig lave din egen private nøgle. Det giver IKKE den ekstra beskyttelse, som du forventer. Selvom du selv har lavet din nøgle, så kan den nemt stjæles både af banditter og af myndighederne.

Hvorvidt det er nemt at stjæle noget fra mig kan du jo så ikke rigtig udtale dig om.

Det er derfor jeg er stor fortaler for at nøglen skal ud på en USB token, hvorfra nøglen aldrig kan indlæses igen. Det skal ikke være valgfrit. Derfor skal du ikke bare kunne lave din nøgle selv, da vi så ikke kan vide om du gør det ordentligt (*). Men det kan godt være, at enhver producent af USB tokens skal kunne ansøge om at få deres produkt godkendt, således at du kan vælge den der passer dig bedst.

(*) jeg er ikke bange for om du specifikt laver noget hø med din nøgle. Den vil såmænd være dit eget problem. Men jeg er bange for at nogen laver et dårligt program, som pludseligt bliver meget populært, således at en stor del af befolkningen sider med usikre nøgler. Tænk på skandalen med de usikre SSH nøgler i Debian - du stoler 100% på ham der har lavet dit program, og du har intet at have den tillid i. Det er en plausibel angrebsvinkel for svindlere.

Og hvem skulle så stå for at genere disse nøgler? Hele debian historien er iøvrigt ikke specielt relevant her af et par grunde.

1) der er intet bevis for at det blev misbrugt i de par år der var mulighed for det.

2) det ville ikke være sket hvis man havde sendt den pågældende patch upstream.

Som det er iøjeblikket skal jeg have 100 tillid til danid og deres java fætter. Som angiveligt ifølge deres support skulle kræve admin rettigheder. Jeg har dog ikke haft mulighed for at verificere dette.

Du mener altså det er bedre at have 100 % tillid til et privat firma med lukket kode fremfor et projekt der kører med peer review på alt kode?

Baldur Norddahl

Det er jo også blevet ualmindelig meget lettere nu hvor de kun skal bruge en nøgle. Før kunne de måske slippe afsted med min netbank nøgle og kode men så fik de kun adgang til min netbank. Der ud over skulle de hvis jeg havde en digital signatur også kopiere den og min kode.

Det er jo så en debat om vi overhovedet skal have en SSO eller et digital signatur system (som kan bruges som SSO).

Personligt mener jeg at det er ok, fordi det er nemmere at lave ordentlig sikkerhed engang, i stedet for at skulle starte forfra hver gang.

Der skal ikke herske nogen tvivl om at jeg mener at NemID ikke har løftet opgaven med ordentlig sikkerhed. Mit budskab er at både TDCs og andre traditionelle PKI løsninger som er baseret på nøglefiler heller ikke løfter den opgave.

Jeg er så heller ikke så bekymret for at myndighederne er skurken. Jeg er bekymret for hvad der sker den dag nemid ikke kan stå imod angrebene mere.

Enhver PKI løsning der er baseret på en central CA har et rod certifikat, som kan blive stjålet. Om det er TDCs rodcertifikat, DanIDs rodcertifikat, Verisigns SSL-rodcertificat eller DanIDs database med alle private nøgler der bliver stjålet har ca. samme konsekvens. Samtlige nøgler må smides ud.

Når vi kritisere den nuværende løsning må vi gøre os klart, om alternativerne kan gøre det bedre.

Hvorvidt det er nemt at stjæle noget fra mig kan du jo så ikke rigtig udtale dig om.

Til det er der to ting at sige:

1) Det er irrelevant om du personligt har super NSA sikkerhed. Systemet skal være sikkert for alle i kongeriget.

2) Så længe der ikke er en brugbar løsning indbygget i alle de gængse operativsystemer og browsere, er du nødt til at acceptere at køre et program udviklet til formålet. Hvis det program, om det er skrevet i java eller andet sprog, kommer fra myndighederne, så jo. Så kan jeg udtale mig om hvor nemt det er for myndighederne at stjæle den private nøgle fra dig: Nemt.

Og hvem skulle så stå for at genere disse nøgler?

Det er mindre vigtigt, så længe der er argumenteret for kvaliteten og sikkerhed for at der kun eksisterer en enkelt kopi på din USB token. Det kan være din USB token kommer med en knap, så første gang du trykker på knappen så laver den nøglerne. Eller det kan være at myndighederne har lavet nøglen på forhånd og indlæst på din USB token. Det gør principielt ingen forskel. De må naturligvis ikke gemme en kopi af din nøgle, men hvis de gør alligevel, så har de ikke opnået meget som de ikke kunne i forvejen i kraft af at være "trusted third party".

Jeg mener at debian historien er særdeles relevant fordi den illustrerer hvor lidt der skal til, for at gøre nøglerne usikre. Den traditionelle med mange øjne på kildekoden fandt muligvis til sidst fejlen, men det tog flere år. I mellemtiden var der tonsvis af usikre servere.

Jeg tror ikke der er noget bevis for ond vilje i debian sagen. Hvilket kun viser at din nøgle kan være usikker ikke kun på grund af ond vilje, men på grund af noget meget farligere: Indkompetance.

Jesper Poulsen

Det vil kræve nøjagtig det samme, som det DanID må gøre for at "aflure" din kode med NemID.

DanID har den private nøgle til NemID liggende. DanID har ingen adgang til en privat nøgle som jeg har liggende. Ingen.

Marc Munk

Det er jo så en debat om vi overhovedet skal have en SSO eller et digital signatur system (som kan bruges som SSO).

Nej det er en debat om hvorvidt vi skal have et digital signatur eller en sso løsning. NemID er IKKE en digital signatur.

Personligt mener jeg at det er ok, fordi det er nemmere at lave ordentlig sikkerhed engang, i stedet for at skulle starte forfra hver gang.

Men det er jo netop ikke lavet ordentligt fra starten af. Det er det der er hele problemet. Og en sso løsning er efter min mening heller ikke det vi skal frem til. Hvorfor skulle jeg kunne bruge min adgang til netbank til at logge ind på skat.dk? Skat havde allerede en løsning der fungerede fint?

Der skal ikke herske nogen tvivl om at jeg mener at NemID ikke har løftet opgaven med ordentlig sikkerhed. Mit budskab er at både TDCs og andre traditionelle PKI løsninger som er baseret på nøglefiler heller ikke løfter den opgav

Du ved godt at nemid løsningen også er basseret på nøgle filer også ikke? Den store forskel er bare med nemid har du ingen kontrol over din "private" nøgle...

Enhver PKI løsning der er baseret på en central CA har et rod certifikat, som kan blive stjålet. Om det er TDCs rodcertifikat, DanIDs rodcertifikat, Verisigns SSL-rodcertificat eller DanIDs database med alle private nøgler der bliver stjålet har ca. samme konsekvens. Samtlige nøgler må smides ud.

Når vi kritisere den nuværende løsning må vi gøre os klart, om alternativerne kan gøre det bedre.

Det problem du meget belejligt vælger at overse her er at vi har samlet alle de "private" nøgler hos nemid og ikke blot rodnøglerne. Alt er samlet altså må det alt andet lige være noget af en lækkerbisken for de kriminelle du siger du fryger så meget..?

Til det er der to ting at sige:

1) Det er irrelevant om du personligt har super NSA sikkerhed. Systemet skal være sikkert for alle i kongeriget.

2) Så længe der ikke er en brugbar løsning indbygget i alle de gængse operativsystemer og browsere, er du nødt til at acceptere at køre et program udviklet til formålet. Hvis det program, om det er skrevet i java eller andet sprog, kommer fra myndighederne, så jo. Så kan jeg udtale mig om hvor nemt det er for myndighederne at stjæle den private nøgle fra dig: Nemt.

1)

Jeg påstår ikke at have en NSA level secutity på mit system men det er ok sikkert efter min mening. Men alligevel skal jeg straffes fordi der er nogle der ikke kan finde ud af at bruge en pc?

2)

Okey? jeg savner lidt en pointe. Det enste jeg har skrevet om programmet fra danid er at det angiveligt skulle kræve admin rettigheder. Det mener du måske er meget fair? Som tidligere dokumenteret så har danid mulighed for at tilgå min privat nøgle alligevel så det er næppe derfor de har valgt at benytte sig af en java applet der kræver admin rettigheder.

Det er mindre vigtigt, så længe der er argumenteret for kvaliteten og sikkerhed for at der kun eksisterer en enkelt kopi på din USB token. Det kan være din USB token kommer med en knap, så første gang du trykker på knappen så laver den nøglerne. Eller det kan være at myndighederne har lavet nøglen på forhånd og indlæst på din USB token. Det gør principielt ingen forskel. De må naturligvis ikke gemme en kopi af din nøgle, men hvis de gør alligevel, så har de ikke opnået meget som de ikke kunne i forvejen i kraft af at være "trusted third party"

Jeg mener ikke det er mindre relevant hvem der laver mine nøgler. Mine nøgler bør laves hos mig selv. Stephan har givet et par eksempler på hvordan det kan foregå...

Jeg mener at debian historien er særdeles relevant fordi den illustrerer hvor lidt der skal til, for at gøre nøglerne usikre. Den traditionelle med mange øjne på kildekoden fandt muligvis til sidst fejlen, men det tog flere år. I mellemtiden var der tonsvis af usikre servere.

Flere år er måske lige i overkanten. Det var så vidt jeg husker 22 måneder. Altså ikke engang 2 år. Og som allerede nævnt så ville problemet ikke være opstået hvis patchen var blevet sendt upstream.

Jeg tror ikke der er noget bevis for ond vilje i debian sagen. Hvilket kun viser at din nøgle kan være usikker ikke kun på grund af ond vilje, men på grund af noget meget farligere: Indkompetance.

Og det kan ikke ske hos DanID?

Baldur Norddahl

DanID har den private nøgle til NemID liggende. DanID har ingen adgang til en privat nøgle som jeg har liggende. Ingen.

Med fare for at gentage mig selv, så må jeg igen fortælle dig at du tager grusomt fejl.

For at din private nøgle kan bruges er du nødt til at anvende et program. Da der ikke findes nogen standardløsning som er acceptabel i de gængse operativsystemer og browsere, er du nødt til at acceptere et program udviklet af myndighederne (eller deres stedfortræder, førhen TDC nu DanID). Dette program HAR adgang til din private nøgle, ellers kan det ikke fungere. Dette program KAN modificeres til at sende din private nøgle med kode videre til myndighederne. Hvilket er præcist det samme som kræves for at DanID kan dekryptere de nøgler de har liggende.

Er det så svært at forstå?

Baldur Norddahl

Nej det er en debat om hvorvidt vi skal have et digital signatur eller en sso løsning. NemID er IKKE en digital signatur.

Enig, NemID er ikke en digital signatur. Men det problem du beskriver kommer af at have et fælles system, uanset om dette system er en digital signatur eller ej.

Hvorfor skulle jeg kunne bruge min adgang til netbank til at logge ind på skat.dk? Skat havde allerede en løsning der fungerede fint?

Fordi hvis vi har en løsning så vi digitalt kan identificere os over for hinanden, så åbnes der så mange flere muligheder. Det kan bruges i alle situationer hvor to parter har brug for med sikkerhed at vide hvem den anden er. Det kan også bruges hvis man har behov for at bevise nogle egenskaber, for eksempel din alder eller din adresse uden at videregive andre irrelevante oplysninger (f.eks. uden at videregive dit CPR nummer). Man kan udvikle sider hvor det er sikkert at børn ikke har adgang. Man kan have debatfora uden trolde. Man kan forhindre svindel på auktionsider. Og så videre.

Og hvis man er lidt smart, så kan man endvidere udvikle et system, således at jeg kan sende dig en krypteret email som kun du kan læse. Også uden at myndighederne har mulighed for at dekryptere. Myndighederne er nemlig kun nødvendige som trusted third party til at garantere for din identitet. Du kan lave en nøgle ved siden af, som vi bruger til at kryptere med, som du signere med din digitale signatur så jeg ved at det er den rigtige nøgle.

I et traditionelt PKI system har man desværre blandet de to funktioner sammen.

Du ved godt at nemid løsningen også er basseret på nøgle filer også ikke? Den store forskel er bare med nemid har du ingen kontrol over din "private" nøgle...

I NemID løsningen ligger der ingen nøglefil på din harddisk, som nemt kan stjæles. Og det er vigtigt. Men naturligvis burde de have valgt en løsning hvor nøglen ligger på en USB token i din lomme i stedet for på deres server.

Det problem du meget belejligt vælger at overse her er at vi har samlet alle de "private" nøgler hos nemid og ikke blot rodnøglerne. Alt er samlet altså må det alt andet lige være noget af en lækkerbisken for de kriminelle du siger du fryger så meget..?

Det er meget sværere at bryde ind hos DanID. Det vil være lidt af en overskrift hvis det skete. Mens der ikke er nogen tvivl om der dagligt brydes ind i tusinder af private computere (botnets, virus, etc).

Endnu engang: Hvis rodnøglen bliver stjålet er ALLE nøgler signeret med denne rodnøgle øjeblikkeligt værdiløse. De skal alle tilbagekaldes med det samme. Så der er ikke nogen praktisk forskel på om de stjæler rodnøglen eller databasen med de private nøgler.

Men alligevel skal jeg straffes fordi der er nogle der ikke kan finde ud af at bruge en pc?

Jeg ved ikke om du skal straffes, men vi er nødt til at designe et system som er beregnet til at blive brugt af masserne.

Okey? jeg savner lidt en pointe. Det enste jeg har skrevet om programmet fra danid er at det angiveligt skulle kræve admin rettigheder. Det mener du måske er meget fair? Som tidligere dokumenteret så har danid mulighed for at tilgå min privat nøgle alligevel så det er næppe derfor de har valgt at benytte sig af en java applet der kræver admin rettigheder.

De skal næppe bruge admin rettigheder. De skal bruge adgang til din private nøgle, uanset om denne ligger på deres server eller lokalt på din maskine. Ellers kan programmet jo ikke udføre dets funktion. Og hvis det har adgang til din nøgle, så kan det også skjult sende den videre til myndighederne.

De meget omtalte USB tokens fungere så at det er hardwaren i tokenen der signere. Nøglen kommer aldrig forbi computerens CPU og det er faktisk umuligt at udlæse nøglen. På den måde vil et program aldrig kunne sende nøglen videre i det skjulte.

Og det kan ikke ske hos DanID?

Du argumentere selv for at upstream ville have opdaget Debian fejlen. Jeg argumentere blot for at løsningerne skal godkendes (ikke det samme som at hemmeligholdes) af eksperter, helst i et åbent forum. Vi skal have en garanti for at der ikke kommer slamsoftware, hvor nogen af uvidenhed har brugt et kryptolib forkert - ligesom det skete for debian.

Jeg argumenterer endvidere for at alle nøgler skal opbevares på enheder hvorfra de ikke kan udlæses. Det skal ikke være valgfrit. Hvis du har en enhed der kan klare kravspecifikationerne, hvoraf et af kravene er at du kan bevise at du ikke selv tog en kopi af nøglen inde du indlæste den, skal du være velkommen til at bruge din egen løsning.

Og sidst er jeg enig med Stephan i at vi skal udvikle en løsning som gør det sværest muligt for banditter, inklusiv myndighederne, at dekryptere kommunikation borgerne imellem. Det gøres IMHO bedst ved at dekoble identifikation fra kryptering. Jeg er ikke enig at der allerede eksisterer en brugbar løsning, det er noget der skal udvikles først.

Peter Kyllesbeck

Det er derfor jeg er stor fortaler for at nøglen skal ud på en USB token, hvorfra nøglen aldrig kan indlæses igen.

Det kaldes også et write-only-device.
Så er det vel enklere bare at slette nøglen. ;-)

Der menes write-once-device ( .. hvortil nøglen aldrig kan skrives igen.)

Baldur Norddahl

Det kaldes også et write-only-device.
Så er det vel enklere bare at slette nøglen. ;-)

Der menes write-once-device ( .. hvortil nøglen aldrig kan skrives igen.)

Nej, helt misforstået. Du kan overskrive nøglen med en ny, men du kan ikke udlæse den igen. Det er ikke en memorystick.

Og nej, det er ikke det samme som at slette nøglen. Nøglen benyttes ved at bede token, som indeholder en lille CPU, om at bruge nøglen til at signere, kryptere eller dekryptere data. Så CPU'en på token kan naturligvis læse nøglen, men det er ikke muligt at udlæse nøglen fra token tilbage til et andet medie.

Det er ikke nyt, der er en standard for det her og det er sådan de faktisk fungerer. Derfor kan du i spec listen for en sådan USB token se hvilke algoritmer der er supporteret.

Vijay Prasad

Enhver PKI løsning der er baseret på en central CA har et rod certifikat, som kan blive stjålet. Om det er TDCs rodcertifikat, DanIDs rodcertifikat, Verisigns SSL-rodcertificat eller DanIDs database med alle private nøgler der bliver stjålet har ca. samme konsekvens. Samtlige nøgler må smides ud.

(Nu går jeg lige ud fra at du mener den private nøgle til rod-certifikatet, og ikke selve rod-certifikatet)

At rod-nøglen bliver stjålet betyder at tyven kan lave nye certifikater. Hvis man antager at alle certifikater skal publiseres af CA før de kan bruges - som Stephen tidligere har beskrevet, så vil man opdage en sløset CA der mister sin rod-nøgle.

Mvh,

Vijay Prasad

For at din private nøgle kan bruges er du nødt til at anvende et program. Da der ikke findes nogen standardløsning som er acceptabel i de gængse operativsystemer og browsere

Bare lige for at forstå det her, hvilke scenarier er det der kræver special-udvikling?

De USB token du selv beskriver fungerer fint med gængse browsere (PKCS#11 interface, som DanID vist også udbyder)

Mvh,

Baldur Norddahl

Bare lige for at forstå det her, hvilke scenarier er det der kræver special-udvikling?

Ja, jeg husker godt hvor godt det virker (ikke!) med den gamle digitale TDC signatur. Af samme grund bruger de ikke længere browseren men har lavet en java applet når man skal logge ind på offentlige websider med digital signatur.

Før de lavede denne java applet havde man ingen kontrol. Var man først logget ind, forblev man logget ind indtil man genstartede browseren. Dertil kom at det ikke var super simpelt at importere certifikatet i første omgang.

Jeg ved ikke om browserne er blevet bedre i mellemtiden. Jeg er ikke for optimistisk. Men hvis de er (på alle platforme) så er det selvfølgelig oplagt at bruge denne eksisterende infrastruktur.

Kan du ikke forklare mig, hvordan man med den eksisterende infrastruktur i browserne (altså uden at bruge java eller andre programmer), kan få vist en besked "du er nu i gang med at overføre 100.000,00 kr til konto 1111-11111111, godkend?" i displayet på en USB token med display?

Baldur Norddahl

At rod-nøglen bliver stjålet betyder at tyven kan lave nye certifikater.

Derfor bliver man nødt til at invalidere rod-nøglen, hvilket også automatisk invaliderer alle eksisterende nøgler lavet med rod-nøglen.

Anonym (ikke efterprøvet)

Høfligst - alle.

Debatten blander tingene sammen og formår ikke at analysere problemet køligt og afbalanceret.

1) For god ordens skyld. De private nøgler må ALDRIG forlade en mobil tamperresistent device - alle nøgleoperationer skal ske i devicen. Dette kan IKKE etableres i DanIds konstruktion.

2) Flere har fanget pointen med at man kan og skal forbygge CAs mulighed for misbrug. Det er en principiel detalje. Det kan IKKE etableres i DanIds konstruktion.

3) Det er også ved at gå op for flere at den eneste måde at forebygge man-in-the-middle er display på devicen. NemId beskytter ikke nogen mod noget - tværtimod sænker det alle til mindre end mindste fællesnævner.

4) De færreste har endnu fanget forskellen mellem formålsspecifik authentificering og identifikation. Førstnævnte er nødvendigt og en forudsætning for digitalisering - sidstnævnte er samfundsøkonomisk og sikkerhedmæssigt destruktivt. DanId leverer kun hvad vi ikke kan bruge til noget.

5) De fleste tror stadig at sikkerhedsdiskussionen enten drejer sig om at beskytte mod 3. parts kriminelle eller mod den "onde" NemId/stat. Sure - begge er væsentlige problemstillinger.

Men man overser at den helt store røver er nedgangen i konkurrenceevnen fordi man fastlåser samfundsprocesser til en forældet centralistisk tankegang - denne faktor alene kommer til at koste Danmark et meget stort milliardbeløb som kun kan betales ved at sænke velfærden/levestandarden.

Er det et problem at nogen har lavet en lille happening for at demonstrere de åbenlyse sikkerhedsproblemer som NemId skaber?

Det er det kun for dem som ønsker at skjule realiteterne og opretholde illusionen af at NemId er lovligt etableret og har en fremtid, mens man ødelægger infrastrukturen og hardkoder alle serviceleverandører op mod totalt forfejlede koncepter og her endda en monopolistisk pengemaskine. Hver eneste krone man pøser ind i dette projekt koster 100 kroner yderligere uden afkast.

Demokratiet bryder sammen når beslutningsprocesser ikke formår at løfte sig til tidens problemstillinger. Konket: Formålet med Digital Signatur er IKKE at identificere - det er et etablere en platform, vi kan bygge digital sikkerhed ovenpå. At fastlåse alle markedsprocesser er selvdestruktivt og ineffektiviserende.

Marc Munk

Enig, NemID er ikke en digital signatur. Men det problem du beskriver kommer af at have et fælles system, uanset om dette system er en digital signatur eller ej.

Problemet bliver jo ikke mindre af at det er en sso løsning. En dårlig en af slagsen endda.

Fordi hvis vi har en løsning så vi digitalt kan identificere os over for hinanden, så åbnes der så mange flere muligheder. Det kan bruges i alle situationer hvor to parter har brug for med sikkerhed at vide hvem den anden er. Det kan også bruges hvis man har behov for at bevise nogle egenskaber, for eksempel din alder eller din adresse uden at videregive andre irrelevante oplysninger (f.eks. uden at videregive dit CPR nummer). Man kan udvikle sider hvor det er sikkert at børn ikke har adgang. Man kan have debatfora uden trolde. Man kan forhindre svindel på auktionsider. Og så videre.

Vi havde en løsning der var bedre end det vi bliver påtvunget nu. DS løsningen kunne godt laves bedre ja men hvorfor så ikke bruge pengene på at forbedre DS istedet for at udvikle noget hø..?

Og hvis man er lidt smart, så kan man endvidere udvikle et system, således at jeg kan sende dig en krypteret email som kun du kan læse. Også uden at myndighederne har mulighed for at dekryptere. Myndighederne er nemlig kun nødvendige som trusted third party til at garantere for din identitet. Du kan lave en nøgle ved siden af, som vi bruger til at kryptere med, som du signere med din digitale signatur så jeg ved at det er den rigtige nøgle.

Der er intet til hinter for at du kan sende mig en krypteret mail uden nemid?

I NemID løsningen ligger der ingen nøglefil på din harddisk, som nemt kan stjæles. Og det er vigtigt. Men naturligvis burde de have valgt en løsning hvor nøglen ligger på en USB token i din lomme i stedet for på deres server.

Så er vi enige... :)

Det er meget sværere at bryde ind hos DanID. Det vil være lidt af en overskrift hvis det skete. Mens der ikke er nogen tvivl om der dagligt brydes ind i tusinder af private computere (botnets, virus, etc).

Kunne det tænkes at man kunne komme ind via en arbejdsstation hos en nemid medarbejder?

Endnu engang: Hvis rodnøglen bliver stjålet er ALLE nøgler signeret med denne rodnøgle øjeblikkeligt værdiløse. De skal alle tilbagekaldes med det samme. Så der er ikke nogen praktisk forskel på om de stjæler rodnøglen eller databasen med de private nøgler.

Systemet skal jo designes efter at det ikke er muligt at sikre rodnøglerne. Som alt andet skal vi designe efter de forskellige senarier vi kan forudse og gerne dem vi ikke forudse.

Jeg ved ikke om du skal straffes, men vi er nødt til at designe et system som er beregnet til at blive brugt af masserne.

Jeg er ikke nogen stor fan af det her med at vi skal køre efter laveste fælles nævner. Det kommer der oftest ikke noget godt ud af.

De skal næppe bruge admin rettigheder. De skal bruge adgang til din private nøgle, uanset om denne ligger på deres server eller lokalt på din maskine. Ellers kan programmet jo ikke udføre dets funktion. Og hvis det har adgang til din nøgle, så kan det også skjult sende den videre til myndighederne.

Med hensyn til adminrettighederne så er det som sagt ikke noget jeg har verificeret men blot noget jeg har hørt.

Og ja hvis de har adgagn til nøglen kan den sendes videre men det er jo ikke nødvendigt når de selv har nøglen og skal kunne levere den hvis de får besked på det.

De meget omtalte USB tokens fungere så at det er hardwaren i tokenen der signere. Nøglen kommer aldrig forbi computerens CPU og det er faktisk umuligt at udlæse nøglen. På den måde vil et program aldrig kunne sende nøglen videre i det skjulte.

Det lyder ganske spændende. Har du evt et link eller noget?

Du argumentere selv for at upstream ville have opdaget Debian fejlen. Jeg argumentere blot for at løsningerne skal godkendes (ikke det samme som at hemmeligholdes) af eksperter, helst i et åbent forum. Vi skal have en garanti for at der ikke kommer slamsoftware, hvor nogen af uvidenhed har brugt et kryptolib forkert - ligesom det skete for debian.

I dit eksempel må danid jo være debian ikke? Det sætter jo danid i et skræmmende lys. DanID har så vidt jeg ved ikke vist noget som helst kode.

Jeg argumenterer endvidere for at alle nøgler skal opbevares på enheder hvorfra de ikke kan udlæses. Det skal ikke være valgfrit. Hvis du har en enhed der kan klare kravspecifikationerne, hvoraf et af kravene er at du kan bevise at du ikke selv tog en kopi af nøglen inde du indlæste den, skal du være velkommen til at bruge din egen løsning.

Og sidst er jeg enig med Stephan i at vi skal udvikle en løsning som gør det sværest muligt for banditter, inklusiv myndighederne, at dekryptere kommunikation borgerne imellem. Det gøres IMHO bedst ved at dekoble identifikation fra kryptering. Jeg er ikke enig at der allerede eksisterer en brugbar løsning, det er noget der skal udvikles først.

Nu begynder det at ligne noget. Lad os så få det koblet sammen med åbne snitflader så virksomheder med de rette kompetancer kan tilbyde servicen. Så er vi ved at være i mål.

Jesper Poulsen

[quote]Og ja hvis de har adgagn til nøglen kan den sendes videre men det er jo ikke nødvendigt når de selv har nøglen og skal kunne levere den hvis de får besked på det.[quote]

Men de skal kunne skrive en logfil på alle de maskiner der kobler sig op. Deres java-applet har derfor de samme rettigheder på systemet som den bruger der aktiverer appletten har. Det er i sig selv skræmmende.

Baldur Norddahl

Der er intet til hinter for at du kan sende mig en krypteret mail uden nemid?

Bortset fra at jeg ikke lige ved hvordan man bruger NemID til at sende krypteret mail, så er problemet at være sikker på hvem afsender og modtager er.

Vi kan udveksle offentlige nøgler, for eksempel PGP nøgler. Og så er det bare at gå i gang. Men siden vi to aldrig har mødtes, hvordan ved vi at der ikke sider en tredie person, som overfor dig lader som om han er mig og overfor mig lader som om han er dig? Det jeg tror er din offentlige nøgle er i virkligheden den tredie persons nøgle. Du er i en tilsvarende position.

Derfor er det relevant med en "trusted third party", som er myndighederne (CPR registeret) som kender os begge, og som kan garantere at vi snakker med den rigtige.

Det eneste myndighederne behøver gøre i den forbindelse er at publicere en liste med offentlige nøgler. Så kan du få publiceret din offentlige nøgle efter at myndighederne har verificeret din identitet. Så skal jeg bare hente nøglen fra dette register, for at være sikker på at det kun er dig som modtager der kan læse min mail.

Det eneste problem er at en sådan liste måske implicit er det samme som at lægge hele CPR registeret til offentlig download. Stephans ide med at publicere alle nøgler har samme problem.

Vi skal bruge et system, hvor du kan vælge hvad du vil fortælle mig om dig selv. Kun hvis du har godkendt det, skal jeg kunne finde dig. End ikke dit navn bør være tilgængeligt uden godkendelse. Hvis jeg kun har behov at kende din alder, så er det også den eneste oplysning som skal overføres. Vi skal huske på folk der har brug for adressebeskyttelse eller som skal beskyttes imod at blive kontaktet af en forfølger etc.

Baldur Norddahl

Det lyder ganske spændende. Har du evt et link eller noget?

http://en.wikipedia.org/wiki/PKCS11
http://en.wikipedia.org/wiki/Hardware_Security_Module

Lad os ikke bruge mere krudt på DanIDs nøgledatabase. Vi er vist alle enige om at det er en skidt løsning. Jeg forsøger bare at pointere at en løsning med nøglefiler også er skidt og at trusselsbilledet her i slutningen af 2010 er så det er nødvendigt med USB tokens.

Marc Munk

Tak for læsestoffet og ja jeg tror også vi i bund og grund af enige om at nemid er en skidt ide der er implementeret på en dårlig måde. Man kunne have gjort det bedre for de mange penge man har brugt på nemid.

Vijay Prasad

4) De færreste har endnu fanget forskellen mellem formålsspecifik authentificering og identifikation. Førstnævnte er nødvendigt og en forudsætning for digitalisering - sidstnævnte er samfundsøkonomisk og sikkerhedmæssigt destruktivt. DanId leverer kun hvad vi ikke kan bruge til noget

Jeg er enig i at det er en vigtig del (nok den vigtigste for at give dig kontrol over egne data) - men, jeg er ikke helt inde i hvordan det tekniske hænger sammen (sub-keys?) - hvis nogen har et godt link der forklarer det?

Altså den formåls-specifikke nøgle skal på en måde "bevise" at man har ret til en ydelse, uden at identificere hvem man er. Hvordan laver man sådan en nøgle?

Mvh,

Baldur Norddahl

Altså den formåls-specifikke nøgle skal på en måde "bevise" at man har ret til en ydelse, uden at identificere hvem man er. Hvordan laver man sådan en nøgle?

Man lader CA signere en række dokumenter, hvor hvert dokument indeholder en ID på din nøgle og en oplysning, for eksempel din alder. Så kan du vælge hvilke dokumenter du vil viderebringe til modtageren.

Vijay Prasad

hvor hvert dokument indeholder en ID på din nøgle og en oplysning, for eksempel din alder.

Ah OK, simpelt :-) Jeg var løb i cirkler om at de formåls-specifikke nøgler var afledte/signerede at sin identitet.

Mvh,

Anonym (ikke efterprøvet)

Jeg er enig i at det er en vigtig del (nok den vigtigste for at give dig kontrol over egne data) - men, jeg er ikke helt inde i hvordan det tekniske hænger sammen (sub-keys?) - hvis nogen har et godt link der forklarer det?

Altså den formåls-specifikke nøgle skal på en måde "bevise" at man har ret til en ydelse, uden at identificere hvem man er. Hvordan laver man sådan en nøgle?

Du kan dele identitet op i logisk adskilte problemstillinger - authentificering, ansvar, integritet, kommunikation, postive credentials, negative credentials, ikke -verificerede statenments etc.

Hver af disse kan dækkes på forskellig vis med flere forskellige teknologier. I princippet bør modellen være inklusivt interoperabel mod alle mulige tekniske mekanismer mappet op mod en meta-strukturering af identitet.

F.eks. kan du med et Blinded Certifiate eller såkaldte Selective Disclosure beviser udvælge hvilke credentials, du vil vise uden at identificeres.

Men identitet skal ses som en SAMLING af beviser/transaktioner snarere end som en enkelt nøgle.

Anonym (ikke efterprøvet)

Hver af disse kan dækkes på forskellig vis med flere forskellige teknologier. I princippet bør modellen være inklusivt interoperabel mod alle mulige tekniske mekanismer mappet op mod en meta-strukturering af identitet.

Hvad er "meta-strukturering af identitet"?

Sammenlign med den fysiske verden, dvs. ikke-automatiserede processer. Her vil modparter i aftaler og processer afkræve hinanden dokumentation og bevis for en række forskellige forhold. Og de vil tilpasse sig den mekanisme til at håndtere et givet sikkerhedskrav som modparten kan levere.

Det vi gør er at afdække alle de risici som er relevante for den pågældende transaktion og evaluere de beviser som foreligges på deres betingelser i forhold til vores krav for at gennemføre transaktionen.

F.eks. Autentificering (genkendelse) dækker så alle de mekanismer som tjener til at fortsætte en relation/transaktion eller med andre ord tekniske mekanismer til at sammenholde ellers uafhængige sessioner. I den fysiske verden vil det i mange tilfælde være rigeligt med den indbyrdes relation mellem 2 personer eller et simpelt ihændehaverbevis såsom f.eks. en bankbog eller en biografbillet (genkendelse med henblik på kobling mellem køb og autorisation til adgang).

Authentificering kan håndteres med forskellige teknologier - PGP, userid-password. cookies, en serie engangskoder specifikt relateret til det konkrete relation (e.g. Jydske Bank men IKKE NemId) etc. - de har forskellige styrker og svagheder, men de etablerer alle genkendelse uden nødvendigvis at lække yderligere information.

I sammenligning hermed kan NemId reelt kun etablere en dårlig overvågningsmodel som samtidig trækker en ikke-relevant tredjepart ind i alle transaktioner.

Log ind eller opret en konto for at skrive kommentarer

Pressemeddelelser

Affecto Denmark reaches highest Microsoft Partner level

Affecto Denmark, a leading provider of data-driven solutions, has reached the highest level in the Microsoft partner ecosystem: Managed Partner.
22. jun 13:45

Innovate your business with Affecto's IoT Explorer Kit

Are you unsure if Internet of Things fits your business strategy?
31. maj 2017

Big Data Lake Summit: Fast and Trusted Insights

If you want to outpace, outsmart and outperform your competition in a digital world, you need trusted data that can be turned into actionable business insights at speed.
24. apr 2017