Kommentar om NemID: Løsningen findes - hvorfor så ikke bare gøre det?

Det er absolut nødvendigt at give brugere mere information om, hvilken side de sender deres NemID-oplysninger til, skriver Patrick Mylund Nielsen fra sikkerhedsfirmaet Kaspersky Labs.

Kernen af problemet med de man-in-the-middle/typosquatting-angreb mod NemID, som Version2 og Ingeniøren har omtalt, er måden, NemID er sat op på. Tjenester, der bruger NemID, gør det ved at indsætte en Java-applet på deres egen side. Den skal brugerne stole på:

Det, man ser i NemID-rammen, er egentlig en anden side. Den kommer fra danid.dk, ikke nordea.dk. Brugeren har imidlertid kun mulighed for at bekræfte identiteten af den ene side (den fra Nordea) og kan ikke være sikker på, at det, der er i NemID-rammen, også kommer fra NemID i virkeligheden.

På hver side, der bruger NemID, skal brugeren selv finde det korrekte domæne - i dette tilfælde Nordea.dk - og så forsikre, at SSL-certifikatet, der bruges, er udstedt til Nordea.dk.

Det er måske ret let på Nordea.dk, men bliver straks mere kompliceret på det lokale biblioteks hjemmeside, f.eks. herlevbibliotek.dk-”var der bindestreg i adressen eller ikke?” En hacker behøver bare at købe et domæne og tilsvarende SSL-certifikat, der ligner det rigtige (f.eks. herlev-bibliotek.dk) for at kunne fremvise en side, der ser rigtig ud men med et NemID-login-felt, der ikke faktisk kommer fra danid.dk.

Hvis den side, der blev indsat i NemID-feltet, blev åbnet separat, f.eks. i et popup-vindue, ville det se nogenlunde således ud:

I dette vindue kan brugeren bekræfte, at siden kommer fra danid.dk, og at serverens SSL-certifikat er gyldigt, uafhængigt af om pop-up’en blev åbnet af Nordea.dk, Danskebank.dk eller Herlevbibliotek.dk.

Som eksempel på denne metode kan vi kigge på ”Log ind med Facebook":

Efter et klik på Facebook-knappen åbnes en pop-up fra Facebook:

Brugeren behøver ikke at stole på, at dr.dk sender login-oplysninger til Facebook. I stedet overlader siden kontrollen til en popup fra Facebook, der forsvinder igen, når man er logget på. Derefter har dr.dk adgang til den nødvendige information kontoen.

Brugeren behøver altså kun at bekræfte at der står ”https://www.facebook.com” i pop-up-vinduets adressefelt for at være sikker på, at den dr.dk-side, de var inde på - hvad enten den er falsk eller ej - ikke får fat i deres login-oplysninger.

Der er ingen grund til, at en tjeneste som NemID ikke kan benytte samme metode som Facebook, Visa, m.fl. Tjenesten vil sandsynligvis ikke blive sværere at benytte. Langt de fleste browsers blokerer nemlig ikke popups, så længe brugeren selv klikker på et link for at åbne den.

Det vil dog kræve at NemID-platformen ændres, så den understøtter login via pop-up-vinduer, og at de forskellige tjenester, der bruger NemID, ændrer deres sider, så de bruger det system i stedet.

Er det et seriøst problem?

Et typosquatting-angreb mod NemID kræver, at brugeren selv navigerer til en side, der ikke er den korrekte, f.eks. herlev-bibliotek.dk i stedet for herlevbibliotek.dk, eller en mellemmand kan manipulere brugerens forbindelse. Med et SSL-certifikat udstedt til herlev-bibliotek.dk kan en ondsindet hacker overbevise brugeren om, at alt er ok (der står ”https”, og certifikatet er gyldigt), selv om Nem-ID-rammen sender informationen videre til deres eget system i stedet for NemID.

To forhold gør, at jeg synes, at det er en absolut nødvendighed at give brugere mere information om, hvilken side de sender deres NemID-oplysninger til:

1) Det er finans- og personsikkerhed, vi taler om. Det er bankkonti med livsopsparinger og pensioner, adresser, sundhedsoplysninger, m.m. Det er ikke ”bare” adgang til følsomme billeder på f.eks. Facebook. Det er uacceptabelt, at der findes angreb, der er lette at udføre i praksis, også selv om det er usandsynligt, at ét angreb rammer en stor procentdel af brugerne.

2) Der er så mange forskellige sider, der bruger NemID, og det er for svært at bekræfte, at hver enkelte af dem ikke er kompromiteret, og om adressen er stavet korrekt. Et unificeret login-vindue med én adresse, f.eks. danid.dk eller nemid.nu, som man skal huske og bekræfte, ville give brugere en betydeligt større chance for at opdage, at noget er galt, før de sender deres NemID-brugernavn og password.

NemID går langt for at sikre brugerne. Teknologier som to-faktor-autenticering, og at der er mulighed for at scanne efter malware på computeren, når NemID-vinduet åbnes, hjælper til at forsikre, at it-kriminelle ikke med lethed kan få adgang til brugeres konto.

Der eksisterer dog, som vi har set, et angreb, der er både teoretisk og praktisk muligt, let at udføre, og som kan bruges til både at komme uden om to-faktor-autenticeringen, og til at lokke login-informationerne ud af nogle få, uheldige brugere. Relativt få vil blive ramt, ja, men der findes en nem måde at løse problemet på - så hvorfor ikke bare gøre det?

En løsning som den ovenfor beskrevne er sikker-adgang.dk, der imidlertid kun benyttes af offentlige myndigheder:

Her behøver brugeren kun at bekræfte, at de er på ”sikker-adgang.dk”, og at der står ”https”, for at være sikker på, at de sender deres login-oplysninger til det korrekte sted. Hvis DanID/NemID, og ikke Økonomistyrelsen, sørgede for at centralisere inlogningsprocessen, så bankerne og andre tjenester, der bruger NemID, også deltager, ville vi have opnået en omfattende løsning.

For at gå et trin videre: Det ville hjælpe - både mod denne form for angreb, men også generelt - hvis bankerne og NemID ikke bare brugte to-faktor-autenticering ved første login, men ved alle kritiske handlinger, f.eks. overførsel af penge.

Hvis login-informationen opsnappes af en hacker, kan de overføre penge, lave ændringer i adresser, osv., uden at behøve at give mere information end brugerens password—hvilket de fik fat i første gang—som bekræftelse. Hvis to-faktor-autenticering også blev brugt ved separate handlinger ville hackeren skulle lokke en kode fra nøglekortet ud af brugeren for hver handling, de ville foretage. Det ville være besværligt at implementere med det fysiske nøglekort, men ikke med den nye, digitale nøgle, og det vil være meget lig den model, der eksempelvis bruges i de svenske banker i dag.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (52)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Kasper Dupont

Jeg er i store træk enig i løsningen, dog mener jeg ikke et popup vindue er en acceptabel løsning. I stedet skal man blot redirectes en tur frem og tilbage imellem de to sites i det vindue man allerede havde åbent.

Popups opfører sig forskelligt afhængigt af browseren, og med nogle bliver de blokkeret. Når nu popups er blevet misbrugt så meget at det har været nødvendigt at blokkere for dem i mange tilfælde, så er det en uheldig idé at forslå popups til legitime anvendelser. Med popups kan det også lade sig gøre at skjule URLen. Hvis man skjuler URLen og lader siden selv præsentere et forfalsket URL felt kan man måske stadig slippe afsted med phishing.

Redirect frem og tilbage mellem to sites er en løsning der allerede bruges nogen steder, og man undgår de problemer som en popup ville introducere.

  • 5
  • 0
Jonas Finnemann Jensen

Er det ikke bare at tilbyde nemID som openID provider... Så kan sites der ønsker at kræve nemID login bare modtage openID og tjekke at openID provideren er danID.dk
Så kunne man bruge nemID alle steder på nettet, fedt!
Man ville også kunne sætte mit-eget-domæne.dk/com/org/etc til at delegere til nemID som openID provider. Så kan man logge ind med mit-domæne.dk/com/org/etc alle steder og bruge nemID som login...

Men det ville nok være for godt. For hvordan skulle danID kunne kræve 2kr per login, som openID provider.
Hvis vi skal støtte IT-infrastruktur skulle vi nok gøre det helt ud næste gang, så vi får noget for pengene...

  • 4
  • 1
Patrick Mylund Nielsen

Langt de fleste browsere blokerer ikke pop-ups, der skabes som resultat af, at brugeren klikker på musen (på f.eks. "Log ind med NemID"), men du har helt ret: Der er ingen grund til at det nødvendigvis skal være en pop-up. Det kunne sagtens være et byt til en ny side, og ja, det ville nok virke mere naturligt.

Begge metoder ville gøre det betydeligt lettere at verificere logon-sidens gyldighed.

  • 2
  • 0
Brian Matzon

og en gang til ... /me shakes fist at timout

Browseren beskytter mod dette.


nææ, afaik, så handler det om browser + om TLD er idn enabled.
www.ñandú.cl i firefox ser fint ud - dvs uden puny code.

Når dk-tld bliver IDN enabled så har vi problemet.

وزارة-الأتصالات.مصر virker også fint i Firefox, mens chrome laver det til punycode.

i firefox styres det af: network.IDN.whitelist.<tld>

  • 0
  • 0
Casper Bang

God artikel Patrick. Igen, jeg ser problemet som værende den skide Java applet. Java har aldrig integreret særlig godt med browsere og gør det ej heller her. Jeg fatter ikke hvorfor man holder fast i denne model der ikke alene er fejlbehæftet, svær at gennemskue, men også udelukker Android og iOS klienter.

  • 3
  • 0
Jens Larsen

Ser hverken redirect eller pop-up som nogen rigtig løsning, det er bare et krumspring mere for en phiser. Og er enig med Brian Matzon, enten have et andet tegn fra utf8, bruge et ekstra - et sted, eller som Thomas Brodersen skrev, et helt andet navn der lyder legit.
Den normalle bruger tænker formetenlig ikke for meget over hvilken side de bliver redirect til/popper op når de skal logge ind på skolens hjemmeside for at se hvad lille ole har for af lektier til imorgen (eller et andet tilfælde hvor de ikke lige er opmærksomme på addresselinjen)

  • 0
  • 0
Lasse Schulin-Zeuthen

hej alle

Inden jeg drukner i kommentarer. Helt enig, dette er ikke den optimale løsning, selvfølgelig skulle det være decentralt, kontrollen til folk selv, umuligt at snyde med mere.

MEN når vi nu er hvor vi er, så har vi pt en løsning hvor selv fornuftige kompetente mennesker ikke har en ærlig chance for at se om vi bliver snydt - og det er noget hø.

Med en fast kendt url, evt to-faktor nogle flere gange, evt besked (sms) når der ændres ting eller godkendes pengetransaktioner evt, så ville vi da komme fra ubrugelig til brugbar.
Så kan dem der vil rent faktisk vurdere om det er falsk eller sandt. Vi kan IKKE sikre os imod folk der klikker på en link til den skumlebank.com, vælger at indtaste på en http:// side og ikke verificere en URL, men vi kan da i det mindste forvente at brugeren har en MULIGHED for at vurdere det.

my 2 cent

/Lasse

  • 4
  • 0
Lasse Schulin-Zeuthen

Jeg prøver vel bare at være realistisk.
Disse forbedringer kan være implementeret i NemId inden jul! Så kan netbanker etc få det med i deres kommende opdatering, og så er vi da kommet fra ubrugeligt til brugbart.

Et nyt projekt vil jo ikke være i luften før om x år, for slet ikke at tale om hele den tid man skal vente på udbud og alt muligt mærkeligt samt evt erstatning til NemId, der jo reelt set har leveret det som er aftalt med nu afdøde ITST.

  • 3
  • 0
Christian Nobel

Jeg prøver vel bare at være realistisk.

Og dermed gøre det til en sovepude for vi aldrig slipper af med det?

Nej tak.

Hvis ikke dette skal går rigtig, rigtig galt, så er der kun en mulighed:

Skrot NemID her og nu

Og så lav det rigtigt.

I den mellemliggende tid må bankerne hive deres gamle login systemer frem fra arkivet, og det offentlige gå tilbage til den fælles pinkode.

Off-topic: Det samme mener jeg så i øvrigt gør sig gældende for IC4 og rejsekortet - hvis først fundamentet er ved at revne og synke, så er det galmandsværk at bygge endnu mere ovenpå.

  • 3
  • 3
Niels Didriksen

Skrot NemID her og nu


Jeg mener faktisk at NemID er helt fint til Bankformål. Og set isoleret i forhold til det, kan MITM-problematikken også mitigeres, hvis man gør en indsats istedet for at stikke hoved i sandet.

Det er mere det med at lade bankerne lege enerådig, alfaderlig, monopoltildelt nøgleholder og underskriver, når borgerne laver indlæg i golfklubbens forum, opretter datingprofiler og skriver med sin læge der er et problem. Det tjener INGEN at bankerne har fået skudt sig ind som en MITM der ordner alt dette på vegne af os, og tager en krone pr gang vi skal checke mail på datingprofilen eller lave nye indlæg om handicaps. Udover banken selvfølgeligt. Hvorfor man også sagtens kan betragte NemID som erhvervsstøtte.

Derfor skal NemID kastes tilbage til banken hvor det hører til, og TDC's udemærkede og ÆGTE digitale signatur redes fra døden og gøres til et rent offentligt styret anliggende. Og jeg foreslår der bygges en brugerflade ovenpå, der ligner NemID som vi kender og anvender den idag.

Derved skal der ikke skrottes noget, kun reddes noget fra skrotning. Og så skal der laves lidt brugerfladehalløj, hvilket jo er et relativt begrænset projekt ifht. at lave det hele forfra. Eller reparere NemID, da det jo i sin natur ikke lader sine værste brister reparere.

  • 3
  • 0
Christian Nobel

@Niels.

Du kan have ret i at bankerne kan lege som de vil, og hvis bankerne vil lave et fælles loginsystem, så er det op til dem - men det skal aldrig lege digital signatur.

Hvis man forfølger din ide, så kræver det i hvert fald at Nets tilbagebetaler det tre cifrede beløb de har malket statskassen for i forbindelse med at lave en ikke-signatur.

Det kan ikke være meningen at det offentlige skal financiere en privat virksomheds loginsystem.

  • 2
  • 0
Rasmus Faber-Espensen

Derfor skal NemID kastes tilbage til banken hvor det hører til, og TDC's udemærkede og ÆGTE digitale signatur redes fra døden og gøres til et rent offentligt styret anliggende.

Hvad er det ved TDCs løsning (POCES1), du synes er bedre end DanIDs?

TDC tog også penge for deres løsning (fra 2 kr til 6 kr pr. unik bruger pr. år). Man kunne naturligvis fritkøbe løsningen, men nogen skal jo betale.

Hvis POCES1-CA'en var korrupt, kunne den udstede et certifikat i dit navn og dermed bruge det til at logge på i dit navn (tilsvarende at et korrupt DanID i teorien kan logge på i dit navn).

Hvis POCES1-CA'en blev kompromitteret, kan angriberen udstede certifikater i alle danskeres navne (tilsvarende at hvis DanIDs server bliver kompromitteret mister de kontrollen over brugernes sikkerhed).

Med den algoritme der blev anvendt til POCES1-login-løsningen (generer XMLDSig på en challenge) virker et MITM-angreb ca. lige så nemt som den gør mod NemID.

Hertil kommer: en angriber, der har kontrol over en maskine, hvor du laver blot én signatur med POCES1 (medmindre du havde din nøgle på en hardware-enhed, hvilket så godt som ingen havde), kan stjæle din nøgle og dermed udgive sig som dig helt indtil at du opdager det og spærrer dit certifikat (det er ikke et problem med NemID).

Der er andre fordele ved et helt standard PKI setup med nøgler placeret lokalt hos brugeren, men de helt basale problem-stillinger omkring trust er meget de samme som for NemIDs setup.

  • 1
  • 0
Jesper Mørch

Det samme mener jeg så i øvrigt gør sig gældende for IC4 og rejsekortet - hvis først fundamentet er ved at revne og synke, så er det galmandsværk at bygge endnu mere ovenpå.

Ah Christian, for STASI-sympatisører og andre med ekstreme kontrol- og overvågnings-tilbøjeligheder er Rejsekortet da en kærkommen gave.

I øvrigt udmærker både Rejsekortet, IC4 og NemID sig ved at være typiske eksempler på offentlige projekter. Funktionaliteten er så elendig at den enkelte borger skal tvinges over på de elendige tiltag med lovgivning. Til gengæld sprænger de alle budgetter og forgælder os alle sammen i mange år frem.

  • 1
  • 1
Jesper Mørch

Hvad er det ved TDCs løsning (POCES1), du synes er bedre end DanIDs?

  1. Der var tale om en ægte digital signatur, hvor de enkelte nøgler blev kontrolleret af den enkelte bruger, i modsætning til NemID som er et centraliseret login
  2. Der var mulighed for at logge på offentlige instanser UDEN om DanID
  3. Der var ikke en statsstøttet monopoliseret privat virksomhed som agerede gate-keeper
  4. Der var ikke tale om security-by-obscurity
  5. Med en krypteret p2p-forbindelse som var teknisk mulig med certifikatet, ville det kræve kontrol over den enkelte session at kunne foretage et MitM-angreb
  6. Man kunne signere og evt. kryptere emails m.m. digitalt uden at skulle sende dem en tur forbi DanID først (Ikke alle dokumenter m.m. vedkommer DanID m.fl.)
  7. Der var ikke tale om samme grad af samfundsskadelig virksomhed som bl.a. Stephan Engberg jævnligt har advaret imod med NemID
  • 3
  • 0
Jesper Mørch

Det skidt ville ikke lade mig redigere mit ovenstående indlæg...

Hvad er det ved TDCs løsning (POCES1), du synes er bedre end DanIDs?

  1. Der var tale om en ægte digital signatur, hvor de enkelte nøgler blev kontrolleret af den enkelte bruger, i modsætning til NemID som er et centraliseret login
  2. Der var mulighed for at logge på offentlige instanser UDEN om DanID
  3. Der var ikke en statsstøttet monopoliseret privat virksomhed som agerede gate-keeper
  4. Der var ikke tale om security-by-obscurity
  5. Med en krypteret p2p-forbindelse som var teknisk mulig med certifikatet, ville det kræve kontrol over den enkelte session at kunne foretage et MitM-angreb
  6. For at kompromittere folks certifikater skulle man kompromittere hver enkelt certifikat enkeltvist.
  7. Man kunne signere og evt. kryptere emails m.m. digitalt uden at skulle sende dem en tur forbi DanID først (Ikke alle dokumenter m.m. vedkommer DanID m.fl.)
  8. Der var ikke tale om samme grad af samfundsskadelig virksomhed som bl.a. Stephan Engberg jævnligt har advaret imod med NemID
  9. Uden et økonomisk incitament, gav det ikke mening at forsøge at knække hver enkelt certifikat, hvorimod NemIDs centraliserede certifikat-bunke pludselig bliver interessant på en helt anden måde.
  10. Med de decentraliserede certifikater var det vanskeligt at begå både identitets-tyveri og økonomisk kriminalitet i større stil, og slet ikke i samme hug som muligheden fordrer nu.

Skal jeg fortsætte?

  • 6
  • 0
Rasmus Faber-Espensen

Der var tale om en ægte digital signatur, hvor de enkelte nøgler blev kontrolleret af den enkelte bruger, i modsætning til NemID som er et centraliseret login


Der er både fordele og ulemper ved at have nøgler decentralt vs. centralt. At kalde den ene løsning for "ægte" er ikke rigtigt noget argument. Hvorfor er en "ægte" digital signatur bedre end en "uægte"?

Der var mulighed for at logge på offentlige instanser UDEN om DanID

Du kunne ikke logge på før at serveren i den anden ende havde kontaktet TDCs OCSP-responder og deres PID-CPR-service. Det var ganske vist serveren og ikke din lokale maskine, der foretog opslagene, men du slap ikke for TDC (og senere DanID, da de overtog driften).

Der var ikke en statsstøttet monopoliseret privat virksomhed som agerede gate-keeper

Tjah, hvis du skulle have udstedt et POCES certifikat skulle du gennem TDC, og hvis du skulle bruge POCES til en login-løsning, skulle du lave en aftale med TDC. Du kunne gratis bruge det til sikker e-mail, men det var så også det.

Der var ikke tale om security-by-obscurity

Det er korrekt. Er NemID kun security-by-obscurity?

Med en krypteret p2p-forbindelse som var teknisk mulig med certifikatet, ville det kræve kontrol over den enkelte session at kunne foretage et MitM-angreb

Det er korrekt. Desværre var det ikke den løsning, der i praksis blev anvendt. I starten så man et par steder, der anvendte klient-autentificeret SSL, men brugeroplevelsen var simpelthen for dårlig, så alle gik over til at bruge OpenSign appletten fra OpenOCES, der ikke havde samme sikkerhed.

Man kunne signere og evt. kryptere emails m.m. digitalt uden at skulle sende dem en tur forbi DanID først (Ikke alle dokumenter m.m. vedkommer DanID m.fl.)

Hverken ved signering eller dekryptering bliver dokumentet sendt til DanID.

Der var ikke tale om samme grad af samfundsskadelig virksomhed som bl.a. Stephan Engberg jævnligt har advaret imod med NemID

Her synes jeg også du og Stephan Engberg må være lidt mere konkrete. Hvad er det DanID skal gøre anderledes? Som jeg forstår Stephan Engberg mener han, at det er skadeligt, at NemID af de fleste opfattes som "godt nok", og at det skader samfundet, at der derfor ikke bliver lagt nok energi i at udforske bedre muligheder. Så skal jeg forstå, at du mener at POCES1 var bedre, fordi den var så tilstrækkelig dårlig, at den ikke blokerede for alternativer?

Jeg synes det er en sund diskussion, at diskutere, hvad der kan gøres bedre. Om ikke andet kommer OCES formodentligt i nyt udbud i ca. 2015. Men jeg synes ikke det er konstruktivt blot ukritisk at nedsable NemID uden at forholde sig til de problemstillinger, som den rent faktisk løser mindst lige så godt som POCES1 gjorde.

Efter min opfattelse er NemIDs væsentligste sikkerhedsmæssige udfordringer 1) den indledende autentifikation: hvordan sikrer man at andre ikke kan få et NemID i dit navn og 2) MITM-angreb.

Den væsentligste brugsmæssige udfordring er brugen af Java-applets og at man derfor ikke kan bruge NemID på f.eks. smartphones.

De tre problemer kan formodentligt løses, men jeg har endnu ikke set nogle forslag, der ikke til gengæld giver problemer med brugervenlighed, sikkerhed eller tilgængelig for handicappede.

  • 4
  • 2
Rasmus Faber-Espensen

Nå, du indredigerede et par punkter mere:

Uden et økonomisk incitament, gav det ikke mening at forsøge at knække hver enkelt certifikat, hvorimod NemIDs centraliserede certifikat-bunke pludselig bliver interessant på en helt anden måde.
Med de decentraliserede certifikater var det vanskeligt at begå både identitets-tyveri og økonomisk kriminalitet i større stil, og slet ikke i samme hug som muligheden fordrer nu.

Jeg synes du mangler at forholde dig til, at POCES1 havde et tilsvarende centralt angrebspunkt: CAen. Hvis en angriber skulle have fået kontrol over CAen var login og signering kompromitteret. Eneste forskel i forhold til et angreb på NemID er at en angriber med fuld kontrol over NemID-serveren måske ville kunne få adgang til at dekryptere gamle mails.

  • 2
  • 0
Niels Didriksen

Man kan som bekendt ikke forklare noget til en person, hvis levebrød afhænger af ikke at forstå det.

Og med mindre der er mange med dit navn i Danmark, kunne man jo fristes til at tro, at du var en Cryptomatic medarbejder. I det tilfælde burde du måske lige nævne det, så vi andre ikke behøver gøre det. Specielt i lyset af, at Søren Winge fra Nets tidligere kom med følgende kommentar vedr. et af NemID-nedbruddene: "Konsulenterne fra Cryptomathic er så tæt knyttet til DanID, at de nærmest er faste medarbejdere hos selskabet."
http://www.comon.dk/art/163779

Senest har en længere række af eksperter og interessenter her på sitet påpeget ulemperne ved NemID-konstruktionen som den ser ud idag, så du behøver faktisk ikke lede længe for at finde argumentation fra interessenter med indsigt. Heriblandt Ulf Munkedal, It-sikkerhedsrådet og andre.

Jeg synes det er bundråddent at du forsøger at påstå at min private PKI-nøgle ligger lige så sikkert i et privat firma som i min egen lomme, uden at jeg har en jordisk mulighed for at kontrollere hvordan og af hvem den bliver behandlet og brugt. Og al den faglitteratur jeg har læst om emnet, understreger til hudløshed pointen af at den private nøgle bliver genereret privat, opbevaret privat og anvendt privat. Det er sådan set konceptet, som det er blevet finpudset af matematikere i de sidste ca 30 år.
Som det ser ud nu kommer vi ALDRIG til at have vores egne nøgler, eftersom al DanID har efterkommet som respons på kritikken er at borgernes egne nøgler bliver DECENTRALE. Og det er sandeligt ikke det samme som PRIVATE. Og med den attitude der er blevet lagt for dagen indtil videre, tror jeg det skal tolkes som pålydende.

Det synes klart for mig, at DanID og underleverandører vil kæmpe med næb og klør for at forsvare deres geniale pengemaskine, bla. ved at sørge for at der ALDRIG kommer konkurrence på delkomponenterne og at "signaturen" ALDRIG kan anvendes uden at det sker gennem DanID. Og for at det kan lade sig gøre er ovenstående jo nødvendigt.

At TDCs certifikat ikke kunne bruges til andet end sikker email er noget vrøvl. At det måske ikke blev det, er en anden sag, men igen; Den har jo heller ikke været tvangsfodret.

  • 6
  • 0
Rasmus Faber-Espensen

Jeg argumenterer som privat person. Jeg udtaler mig ikke på hverken Cryptomathics eller DanIDs vegne.

Min pointe er at der ikke er noget magisk ved at have sin private nøgle liggende hos sig selv:

Et nøglepunkt i sikkerhedsmodeller er, at der er nogen personer eller organisationer, som man vælger at stole på. Du stoler på at Microsoft og/eller Linus Torvalds ikke lægger bagdøre ind i dit OS, du stoler på at din computerfabrikant ikke lægger spionsoftware ind i din computer og du stoler på at din compiler genererer den korrekte kode.

Det smarte i en PKI-model er at vi kan kommunikere sammen, selvom vi ikke kender og stoler på hinanden, hvis blot vi stoler på den samme person/organisation (CAen).

Men hvis det så viser sig, at vi ikke burde havet stolet på CAen - hvis den bliver kompromitteret eller hvis den selv eller en insider snyder, bryder sikkerhedsmodellen sammen.

Den problemstilling er fuldstændig parallel for POCES1 og NemID: Man er tvunget til at stole på TDC/DanID.

Der er andre løsninger, f.eks. web-of-trust, der ikke har samme problemer, men web-of-trust passer dårligt til forholdet mellem stat og borgere og jeg har svært ved at se, hvordan Stephan Engbergs ide om afledte nøgler kan gøres forståelig for den gennemsnitlige borger.

Men jeg synes det er interessant at diskutere, hvad der kan gøres bedre. Men det ville nok være mere konstruktivt, hvis du imødegik mine argumenter, i stedet for at diskutere min person og min arbejdsgiver.

Endelig forstår jeg ikke, hvorfor du mener, jeg har sagt, at TDCs løsning ikke kunne bruges til andet end sikker email. Tværtimod vil jeg mene, at det fortrinsvis blev brugt som en login-løsning (jeg brugte det f.eks. selv primært til at bestille frisørtider og til at logge på Skat).

  • 2
  • 1
Jesper Mørch

Så skal jeg forstå, at du mener at POCES1 var bedre, fordi den var så tilstrækkelig dårlig, at den ikke blokerede for alternativer?

Jeg vil nærmere sige, at selvom OCES-certifikatet ikke var optimalt, var den i det mindste ikke et MitM-angreb for overhovedet at få adgang.

Hele tankegangen omkring at man lader en enkelt instans sidde med fuld kontrol over ikke kun alle borgeres økonomi men også deres privatliv, er ubehagelig.

Det er decideret samfundsskadeligt at opbygge selve skelettet i den form for digital forvaltning, hvor man skal stole blindt på en finansiel virksomhed, som kun har det ene formål at de skal tjene penge for enhver pris.

Det er en samfundsskadelig tankegang at man giver en enkelt virksomhed monopol på at kunne tilgå og manipulere alle borgeres liv og økonomi OG lader det være op til den enkelte borger at skulle bevise sin uskyld.

Det er samfundsskadeligt at indbygge overvågnings-mekanismer i alle digitale konstruktioner i det danske samfund, og det er i den grad samfundsskadeligt at ignorere sikkerheds-konsulenter og -specialister som advarer imod realistiske scenarier, blot fordi man tilsyneladende har en anden agenda.

Ovenstående er blot et udvalg af argumenterne imod den samfundsskadelige konstruktion som NemID er.

Der er både fordele og ulemper ved at have nøgler decentralt vs. centralt.

Eneste forskel i forhold til et angreb på NemID er at en angriber med fuld kontrol over NemID-serveren måske ville kunne få adgang til at dekryptere gamle mails.

Det er et stort sikkerhedsmæssigt problem når nøglerne er centralt lagrede, da du ganske enkelt ikke selv har kontrollen med dem.

Som nævnt tidligere i indlægget, er selve NemID-adgangen reelt et MitM-angreb som foregår mellem dig og den instans du ønsker adgang til.
Da du ikke selv har den fulde kontrol over dine egen private nøgle (som reelt slet ikke er privat, når du ikke selv har kontrollen over den), fjerner du en stor del af den troværdighed, der bør være omkring hele den digitale adgang til alt, inkl. adgangen til den offentlige forvaltning.

En af de største problemstillinger for mig er, at DanID handler på vegne af mig, og dermed i realiteten ikke behøver mit samtykke for at handle i mit navn.

Misbrugspotentialet er med denne konstruktion ganske enkelt for stort!

En sikkerhedskonstruktion må aldrig være afhængig af at informationerne ikke bliver misbrugt selvom muligheden foreligger.
Sådan en konstruktion kan kun betragtes som kompromitteret allerede i designfasen og er dermed ubrugelig i praksis.
En troværdig sikkerhedskonstruktion skal opbygges, så teknikken og konstruktionen så vidt muligt forhindrer misbrug og dermed overvågning. Med NemID er man desværre gået den modsatte vej.

Jeg tror at det i bund og grund er den allerstørste enkeltstående sikkerhedsbrist i hele NemID-konstruktionen. Desværre kræver lige netop denne anke, at hele konstruktionen ændres fundamentalt, for at kunne blive troværdig, og så længe der er økonomiske interesser involveret i at fastholde denne konstruktion, kommer det ikke til at ske.

Så længe vi har politikere siddende som:
1. Ikke har den fornødne teknisk viden om IT m.m.
2. Ikke vil indrømme deres himmelråbende fejltagelser
Kommer der ikke til at ske noget som helst

Giver ovenstående mening?

  • 5
  • 0
Casper Bang

Det er korrekt. Desværre var det ikke den løsning, der i praksis blev anvendt. I starten så man et par steder, der anvendte klient-autentificeret SSL, men brugeroplevelsen var simpelthen for dårlig, så alle gik over til at bruge OpenSign appletten fra OpenOCES, der ikke havde samme sikkerhed.

Nu bliver jeg nysgerrig; hvad var det ved SSL der gjorde brugeroplevelsen dårlig? Når jeg er ude og få NemID til at virke for folk, handler det typisk om opsætning af Java, tilladelser til appletten, fokus i rette felt - med andre ord, en virkelig ringe brugeroplevelse for alm. folk.

SDC's tidligere bankløsninger brugte også en applet-løsning fra Cryptomathic, hvor det var op til irreterede programmører som jeg selv, at logge og indkapsle HTTP kommunikationen i et særskildt program hvis man ønskede en nem måde at komme ind og kigge på sin konto.

Og nu jeg har fat i en Cryptomatic mand. Selv om applet-koden er obfuscated og bliver lazy-loaded, med alle de sikkerhedshuller i Java, hvad forhindrer en virus i at at indstallere et AOP hook i JVM'en på folks PC'er og systematisk indstallere MITM angrebet dér?

  • 4
  • 0
Patrick Mylund Nielsen

Igen, jeg ser problemet som værende den skide Java applet. Java har aldrig integreret særlig godt med browsere og gør det ej heller her.

Jeg kan forstå argumentet, at en signeret applet kan bruges--på en relativt sikker måde--til at opnå systemadgang og scanne efter malware målrettet mod NemID, Nordea, el.l., men ud over det ser jeg heller ikke meget, der bakker op bag brugen af Java. Jeg synes især det er svært at argumentere for når Java applets' popularitet er så dalende, som den er. Mange danskere har Java på deres maskine, og har dermed tilføjet en kæmpe angrebsvektor, kun fordi de bruger NemID eller de tidligere online banking systemer.

Google Chrome har taget et skridt i den rigtige retning med den obligatoriske bekræftelse af enkelte Java applets, men det er langt fra universielt.

  • 3
  • 0
Jesper Mørch

Og nu jeg har fat i en Cryptomatic mand. Selv om applet-koden er obfuscated og bliver lazy-loaded, med alle de sikkerhedshuller i Java, hvad forhindrer en virus i at at indstallere et AOP hook i JVM'en på folks PC'er og logge MITM angrebet dér?


Hvorfor stoppe dér?
Hvad med at generere falske websider fra netbanken, så man som bruger ser sin netbank UDEN de uautoriserede bankoverførsler som foregår imens i baggrunden, men hvor alle andre tal ellers passer? - også de nye som evt. indtastes.
Det burde være en smal sag at beregne i JavaScript, Flash e.lign. og, nu jeg nævner Flash, burde det også være en smal sag at tænde en brugers indbyggede webcam, så man med lidt god vilje kan affotografere papkortet.

Som jeg ser det er NemID ikke designet til at maksimere sikkerheden, men derimod til at minimere risikoen for sort arbejde, maksimere muligheden for overvågning og maksimere profitten hos gatekeeper (DanID).

Please correct me if I'm wrong ...

  • 5
  • 0
Jesper Lund Stocholm Blogger

Men jeg synes det er interessant at diskutere, hvad der kan gøres bedre. Men det ville nok være mere konstruktivt, hvis du imødegik mine argumenter, i stedet for at diskutere min person og min arbejdsgiver.


Jeg er lidt splittet over NemID, for på den ene side er jeg bruger af systemet, som er ovenud tilfreds med NemID. Det virker langt bedre og på langt flere steder end TDCs løsning og det virker langt bedre på tværs af browsere og operativsystemer som jeg kommer i nærheden af (måske lige bortset fra mobilplatforme).

Men som IT-professionel falder kæden af for mig på nogle punkter:

  1. Jeg forstår simpelthen ikke, hvordan NemID virker - for det er ikke dokumenteret nogen steder.

  2. Hvorfor er Applet obsfuscated? Hvis man har resourcer til at opsætte mitm-angreb på Nordea, så har man ganske sikkert også mulighed for at omgå denne sløring af koden. Til gengæld vanskeliggør man ganske almindelige computerkyndiges mulighed for at gennemse koden og vurdere hvad den gør.

Ad 1)
Jeg stoler (mindst lige så meget) på DanID som på TDC - jeg har intet problem med kravet om, "at stole på nogen", men jeg mangler information om, hvad der sker i Applet, hos DanID etc. Argumentet er sikkert, at det vil give "onde" mennesker bedre mulighed for at bryde systemet, men det har jeg rigtigt svært ved at anerkende. De onde har sandsynligvis resourcerne til det alligevel.

Hvis man ikke vil udgive Applet som OSS, så kopiér Microsofts koncept omkring "shared source", hvor nogen uvildige får adgang til kildekoden og herefter for os andre kan verificere, at alt går rigtigt til.

IT-Politisk Forening kunne eksempelvis være nogen, der (burde) kunne stille med disse eksperter.

  • 4
  • 0
Niels Didriksen

Jeg argumenterer som privat person. Jeg udtaler mig ikke på hverken Cryptomathics eller DanIDs vegne.


Det mener jeg er common courtesy at gøre opmærksom på. Ellers fremstår det jo bare på samme måde, som da Ivan Damgård i egenskab af professor frikendte NemID for en sikkerhedsbrist, uden at nævne at han var medejer af Cryptomatic før andre gjorde opmærksom på det. Et fact der muligvis er irrellevant, men lidt uklædeligt ikke at være på forkant med.

I din sammenligning mellem TDCs certifikat og NemID, fortæller du at de stort set er ens, bortset fra at NemID er en lille smule ringere, fordi en kompromittering tillader dekryptering af ældre beskeder. Det er jo ikke rigtigt. TDC ville ALDRIG kunne dekryptere en borgers signatur, hvis de fik fat i cipher-tekst. DanID vil ALTID kunne. En forskel der er til at få øje på, hvis man ikke vender kikkerten for det blinde øje, eller har interesse i at sløre den. Og hvor mange andre professionelle CA'er kender du, der ligger inde med kundernes private nøgler? Nej, vel.

Så argumenterer du for at TDCs teknologi var utilstrækkelig, ifht. det danske samfunds behov. Det er muligt. Men det retfærdiggør ikke at man laver en konkurrence-resistent, formynderisk, umyndiggørende, ufleksibel løsning, der blæser på best-practice istedet. Man burde (som jeg tidligere skrev) have arbejdet videre med hvad man havde, og lavet det rigtigt. Sjovt nok, argumenterer du for, at vi nu arbejder videre med NemID nu vi har det, og jeg undrer mig over hvorfor samme ræsonnement ikke kunne anvendes på den signatur samfundet allerede havde investeret i og taget i anvendelse? Eller rettere, det undrer jeg mig ikke over, for jeg ville nok mene det samme, hvis jeg var underleverandør.

Linus Torvalds og Microsoft TVINGER mig ikke til at bruge deres produkter, de er åbne for peer-review (ms delvist), jeg kan anvende deres systemer på talløse måder i samspil med andre, jeg kan mitigere risici med yderligere sikkerhedslag osv osv. DanID er "Æd skovsneglen med pistolen for panden hvis du vil deltage i det danske samfund". Frivillighed min bare.

Som Jesper Mørch skriver ovenfor; "Misbrugspotentialet er med denne konstruktion ganske enkelt for stort". Og kombineret med den attitude og fremgangsmåde der er udvist siden ibrugtagelse løber det jo koldt ned af ryggen.

  • 7
  • 1
Rasmus Faber-Espensen

hvad var det ved SSL der gjorde brugeroplevelsen dårlig?

Nu er jeg ikke UX-ekspert, men det primære problem, jeg hørte om, var at der var for lidt information om, hvad der skete: brugeren fik blot en boks op, som bad brugeren om at vælge et certifikat og blev derefter bedt om en adgangskode. Afhængig af browser var der mere eller mindre information, men jeg husker mindst én version af Firefox, hvor jeg efter at have fået udstedt et nyt certifikat (og ikke slettet det gamle, da jeg havde krypteret post liggende) blev præsenteret for en dialog, hvor jeg skulle vælge mellem at bruge "Rasmus Faber-Espensen" eller "Rasmus Faber-Espensen" og kun nummer to certifikat virkede.

Herudover var der en del tekniske problemer. Det var (afhængig af server) besværligt at logge signaturen, det var umuligt at implementere en logud-funktion, der var ingen mulighed for at sikre, at nøglen lå password-beskyttet osv.

Selv om applet-koden er obfuscated og bliver lazy-loaded, med alle de sikkerhedshuller i Java, hvad forhindrer en virus i at at indstallere et AOP hook i JVM'en på folks PC'er og logge MITM angrebet dér?

Hvis en angriber får kontrol over din computer har du i princippet tabt (i hvert fald så længe vi ikke distribuerer hardware-enheder med display). Det eneste man kan gøre er at gøre det så besværligt som muligt for angriberen. I princippet er det en tilsvarende problemstilling som DRM, snyd i MMO-spil osv. Her er det blot ikke den legitime ejer af maskinen, men en angriber, der er "modstanderen".

Jeg er lidt irriteret over, at det skal være nødvendigt at skrive det her: men alt det ovenstående er mine egne, personlige holdninger. Jeg udtaler mig ikke på vegne af hverken Cryptomathic eller DanID.

  • 0
  • 1
Rasmus Faber-Espensen

TDC ville ALDRIG kunne dekryptere en borgers signatur, hvis de fik fat i cipher-tekst.

Hvis de lagde et forfalsket certifikat ind i certifikat-databasen, ville alle brugere, der havde tilkoblet sig deres LDAP-service, derefter begynde at kryptere mails under en nøgle, som TDC kunne dekryptere.

jeg undrer mig over hvorfor samme ræsonnement ikke kunne anvendes på den signatur samfundet allerede havde investeret i og taget i anvendelse? Eller rettere, det undrer jeg mig ikke over, for jeg ville nok mene det samme, hvis jeg var underleverandør.

Cryptomathic var også underleverandør til TDCs digitale signatur-løsning.

  • 0
  • 0
Niels Didriksen

Hvis de lagde et forfalsket certifikat ind i certifikat-databasen, ville alle brugere, der havde tilkoblet sig deres LDAP-service, derefter begynde at kryptere mails under en nøgle, som TDC kunne dekryptere.


Ja naturligvis, indtil det blev opdaget og IKKE retrospektivt. Som NemID kan. Og så er vi tilbage ved humlen igen. Hvad får man ud af at deponere nøglen til borgernes digitale identiteter i en bank.?1) DanID skal tjene kartel-penge og 2) embedsmænd synes sikkert det er et rart værktøj at have. 3) Borgerne får.... i bedste fald INTET ud af det, ifht. rigtige løsninger.

Som PHK siger i en analyse:
"NemID er ikke en “digital signatur”, det er “single sign-on” og skal ses og analyseres i det lys. Hvis de havde kaldt den det fra starten havde der ikke blevet så meget larm.

At der existerer et certifikat per bruger, er i virkeligheden bare en implementeringsdetalje, fordi de services der skal logges ind til ikke er under samme kontrol-domæne.
[...]
Det det offentlige opnår, er at der komme en central log over alle anvendelser af certifikater, der kan udleveres imod en dommerkendelse, det ville man ikke have hvis borgerne rendte rundt med certifikatet på en USB dims lommen"
[...]
Det borgerne mister ved de centraliserede certifikater, er to ting:

For det første at vi ikke har nogen sikkerhed for, eller mulighed for at undersøge om, særligt betroede insiders, herunder f.eks PET, ikke skriver under for os med vores signatur.

For det andet kan vi ikke bruge vores certifikater til andre ting, f.eks til at låse den elektroniske lås på vores hoveddør op med (en indlysende anvendelse: Udsted et bevis til blikkenslageren der kan åbne døren netop en gang imellem 10:00 og 14:00 på torsdag.)"

Jeg hæfter mig også ved du har unladt at komme med skyggen af forslag til hvad man som borger får ud af NemID ifht. rigtige PKI'er. Eller kommet med eksempler på hvilke andre fortilfælde der er på at professionelle CA'er alene ligger inde med kundernes nøgler.

Det er muligt at cryptomatic også var underleverandør til TDC's signatur-løsning, men heller ikke der svarede du på, hvorfor den skulle skrottes istedet for at arbejdes videre med den, som du foreslår vi gør med NemID's mangler.

  • 4
  • 1
Jesper Mørch

Hvis de lagde et forfalsket certifikat ind i certifikat-databasen, ville alle brugere, der havde tilkoblet sig deres LDAP-service, derefter begynde at kryptere mails under en nøgle, som TDC kunne dekryptere.


Det kan godt være du ignorerer fejlmeddelelser, men hvis mit certifikat, som først udløber meget senere, pludselig får validitetsproblemer, og alle andre jeg kender til, får samme problem med deres certifikat, ville det nok få mig til at reagere.

Hvis min private nøgle som er genereret hos mig på min computer pludselig ikke kan tilgå mine mails, vil jeg nok også blive opmærksom på at der er noget galt.

Jeg tillader mig at tvivle på at mine mails gemt på min lokale computer pludselig ville blive indkodet med et eksternt men centralt certifikat på en måde, så 3'part ville kunne dekryptere dem.

Jeg tillader mig også at tvivle på at de nøgler som blev genereret på min computer, hvor den offentlige nøgle efterfølgende blev offentligt tilgængelig pludselig ville have et ekstra sæt matchende nøgler jeg ikke kendte til.
I så fald ville problemstillingen ikke skyldes arkitekturen og/eller konstruktionen, men derimod en dårlig kompromittérbar algoritme

  • 2
  • 0
Rasmus Faber-Espensen

Jeg skal gerne give jer ret i, at det var sværere for TDC at kunne angribe krypterede mails end det er for DanID. Min pointe var blot, at det ikke var umuligt (PET kunne f.eks. få TDC til at udstede et falsk certifikat, få det lagt på LDAP-serveren, opsnappe den sendte mail, dekryptere den og derefter erstatte den med en, der var krypteret med det ægte certifikat). Men det er nok lidt et sidespor: brugsscenarierne for POCES1 og NemID er 1) login, 2) digital signatur og først på en meget fjern tredjeplads krypteret email.

Og det er nok én af grundene til forskellene mellem TDC's løsning og NemID: TDC's løsning var designet til sikker email og der blev så strikket en løsning sammen, så den også kunne bruges til login. NemIDs løsning er designet til login og digital signatur, men kan også bruges til sikker email.

Der er også truffet væsentlige andre sikkerhedsvalg. Det er tydeligt at se på designet, at man har tænkt mere på at prøve at beskytte brugeren i tilfælde af at hans maskine er kompromitteret. Man har også ønsket at gøre det lettere at bruge flere forskellige computere (også f.eks. en på biblioteket), og der er blevet lagt mere vægt på tilgængelighed for handicappede.

Det er faktisk heller ikke rigtigt, at TDC's løsning blev fuldstændig skrottet. F.eks. er signaturen fra appletten i samme format som fra OpenSign-appletten, som TDC's løsning anvendte.

Det var mit indtryk, at diskussionen her handlede om, hvordan man skulle implementere løsningen, hvis man skulle gøre det rigtigt. Niels Didriksen mener at det rigtige er at gå tilbage til TDC's løsning, og jeg forklarer, hvorfor at den på langt de fleste punkter ikke var mere sikker end NemID.

Jeg synes diskussionen om, hvad der kan gøres bedre, er rigtig interessant. Hvis I foretrækker at forklare, hvordan TDC's løsning skal modificeres, så den bliver bedre, er jeg også meget interesseret.

  • 0
  • 0
Rasmus Faber-Espensen

eksempler på hvilke andre fortilfælde der er på at professionelle CA'er alene ligger inde med kundernes nøgler.

Lige umiddelbart ved jeg at Luxtrust i Luxemborg og BankID i Norge har lignende systemer. Udover det er det meget almindeligt at CAer implementerer key escrow og lignende, så at de ligger inde med en kopi af brugerens private nøgle (jeg ved godt, at det ikke er helt det samme).

Det er ikke fordi, at jeg ikke kan se problemstillingen ved at opbevare nøglerne centralt, men der er også fordele: nem mobilitet, centraliseret sikkerhed osv. og det er svært at designe et system, der ikke har ca. de samme ulemper: single point of trust, mulighed for overvågning osv.

  • 0
  • 0
Rasmus Faber-Espensen

Lad venligst være med at antyde at NemID er en digital signatur. Med din position kan du ikke være uvidende om de faktiske forhold.

Man kan ikke få udstedt kvalificerede certifikater til sit NemID, da NemID ikke opfylder kravene i Lov om Digitale Signaturer. Men man kan underskrive beskeder digitalt med den RSA nøgle, der opbevares på DanIDs servere. Det er altså en digital signatur i almindeligt sprogbrug.

  • 0
  • 0
Jesper Mørch

NemIDs løsning er designet til login og digital signatur, men kan også bruges til sikker email.


Kære Rasmus
Kan du ikke venligst forklare mig hvordan jeg med NemID kan signere noget som helst UDEN at DanID signerer noget som helst på vegne af mig?
Jeg er sikkert lidt dum, men jeg kan ikke helt forstå hvordan jeg med NemID kan signere noget som helst uden at benytte mig af DanIDs IT-systemer.
Med den digitale signatur fra TDC var det intet problem, da jeg selv lå inde med mit eget certifikat.

Jeg har i øvrigt lidt svært ved at forholde mig til en PRIVAT nøgle som jeg ikke selv har kontrol med. Jeg har i min naivitet bare altid troet at hvis jeg skulle kunne underskrive noget som helst, skulle jeg selv føre pennen, og ingen andre måtte have adgang til at kunne underskrive på vegne af mig - heller ikke digitalt ...
- Men, som sagt er jeg nok også lidt dum.

  • 0
  • 0
Peter Stricker

Det er altså en digital signatur i almindeligt sprogbrug.


Jeg er lidt i tvivl om, hvad du mener med "almindeligt sprogbrug". Tænker du på Jette Knudsens pressemeddelelser?

Der er vist ikke mange har på Version2, der køber Henrik Udsens (*) forklaring om at digital signatur slet ikke skal forstås bogstaveligt.

(*) Notat vedr. elektronisk signatur, https://danid.dk/export/sites/dk.danid.oc/da/dokumenter/henrik_udsen_not...

  • 0
  • 0
Rasmus Faber-Espensen

Kan du ikke venligst forklare mig hvordan jeg med NemID kan signere noget som helst UDEN at DanID signerer noget som helst på vegne af mig?

Det kan du ikke. Det tror jeg heller ikke at nogen har påstået.

Ingen af os kan gå og huske vores 617-cifrede hemmelige nøgle - for slet ikke at snakke om at foretage kryptografiske beregninger med den. Så i praksis er vi nødt til at placere den et sted udenfor os selv.

I TDC's løsning lå den i en nøglefil på computeren, og du bad computeren om at dekryptere den private nøgle med dit kodeord og derefter signere med den på dine vegne. I NemID ligger den i en hardware boks på DanIDs server og du beder DanIDs server om at kontrollere dit brugernavn, password og engangskode og derefter signere med den på dine vegne.

Jeg ved godt at det er en forsimpling, og jeg kan godt se forskellen på om bitsene ligger fysisk på en computer, du har kontrol over, eller om de ligger på en computer, som DanID har kontrol over.

Men på den anden side: det er din private nøgle, som ligger på DanIDs server. Den kan kun anvendes af en person, der har adgang til dit brugernavn, adgangskode og nøglekort (dvs. forhåbentigt kun dig), og du kan foretage alle de kryptografiske privat-nøgle operationer, du har lyst til med den. Det er svært i praksis at skelne den fra en privat-nøgle, som du har til at ligge på en hardware-token. Du er nødt til at stole på at DanID ikke lyver, når de siger, at det kun er dig, der har adgang til din private nøgle - men du er også nødt til at stole på producenten af din hardware-token.

Jeg synes det er mere interessant, hvis man prøver at overveje hvad konsekvenserne af de to løsninger er: Hvem kan underskrive på dine vegne? Hvem kan logge ind på dine vegne? Hvem kan se, hvad du foretager dig på nettet? osv. Og med de briller på, så har jeg svært ved at se forskel på dem.

  • 2
  • 1
Thue Kristensen

Når dk-tld bliver IDN enabled så har vi problemet.

.dk har allerede IDN. Se for eksempel http://fårup.dk.

Men DK hostmaster har (meget smart!) valgt, at det kun er ganske få ekstra tegn som æøå som er tilladte. Så vi får aldrig noget problem med daƞid.dk .

De bogstaver som jeg synes er problematiske, og som er tilladte af DK hostmaster, er ö, ä, ü, og é. Så hvis man er en nogenlunde kompetent administrator af et sikkerhedskritisk domaine, så registrerer man bare alle variationer af sit domainenavn med disse, så burde man være sikker. Hvis der er nogen som er interesserede, så er némid.dk stadig ledigt!

Sidebemærkning: Browserne har algoritmer til at bestemme, hvornår det er sikkert at vise IDN i stedet for punycode. I tilfældet daƞid.dk tillader Chromium ikke ASCII sammen med ƞ i samme komponent.

  • 1
  • 0
Rasmus Faber-Espensen

Jeg er lidt i tvivl om, hvad du mener med "almindeligt sprogbrug".

Det er selvfølgelig nok rigtigt, at "digital signatur" trods alt ikke helt er en del af "almindeligt sprogbrug". Men jeg er dog ikke før Version2-debatterne om NemID stødt på nogen, der definerer det meget anderledes end f.eks. her:

digital signatur, elektronisk signatur, kode på elektroniske dokumenter, der entydigt identificerer afsenderen.

Mht. Henrik Udsen, så er jeg nok uenig i hans konklusion om, at det ville kunne være lovligt at udstede kvalificerede certifikater med en central nøgle server a'la NemID. Jeg er nok enige med de fleste i, at forbuddet mod opbevaring af private nøgler er for klart. Men jeg er ikke jurist og han har jo ret i, at kun en konkret afgørelse fra en domstol vil kunne afgøre det endeligt. Men DanID har jo heller ikke valgt at udstede kvalificerede certifikater, så jeg ved ikke hvorfor det er relevant. Jeg kan ikke læse, at han nogen steder skriver, at "digital signatur" ikke skal tages bogstaveligt (blander du det måske sammen med "egenkontrol"?)

  • 0
  • 0
Jesper Lund Stocholm Blogger

I NemID ligger den i en hardware boks på DanIDs server og du beder DanIDs server om at kontrollere dit brugernavn, password og engangskode og derefter signere med den på dine vegne.


Det var min opfattelse, at hele humlen ved at have sådan en certificeret level X hardware "tamper-proof" dims var, at kommunikationen imellem mig (i vores tilfælde en applet) og hardware-dimsen var krypteret, så DanID (eller hvem hardware-dimsen er opmagasineret ved) ikke kan aflytte disse ting?

(det er detaljer som disse, som det kunne være rart at DanID dokumenterede)

  • 2
  • 0
Jesper Mørch

Du er nødt til at stole på at DanID ikke lyver, når de siger, at det kun er dig, der har adgang til din private nøgle - men du er også nødt til at stole på producenten af din hardware-token.


Se, så er det jo lidt problematisk, når DanId gentagne gange har bevist at de er bedre til at tjene penge og omgås sandheden letsindigt, end de er til at fortælle den fulde sandhed, og tænke på brugernes sikkerhed og privatliv.

  • 4
  • 0
Thue Kristensen

Men på den anden side: det er din private nøgle, som ligger på DanIDs server. Den kan kun anvendes af en person, der har adgang til dit brugernavn, adgangskode og nøglekort (dvs. forhåbentigt kun dig), og du kan foretage alle de kryptografiske privat-nøgle operationer, du har lyst til med den.

Jeg giver jo jævnligt mit login/password til en applet uden kildekode skrevet af DanID. Og DanID kan også få en engangskode, hvis de falskt angiver at et login-forsøg fejlede.

Det er svært i praksis at skelne den fra en privat-nøgle, som du har til at ligge på en hardware-token. Du er nødt til at stole på at DanID ikke lyver, når de siger, at det kun er dig, der har adgang til din private nøgle - men du er også nødt til at stole på producenten af din hardware-token.

Forskellen er, at jeg kan anskaffe hardware-token fra en producent jeg stoler på. Jeg har i øjeblikket ikke noget valg om at "stole" på DanID.

  • 1
  • 0
Michael Kristensen

Problemet er ikke hvilken tekniske løsning som den værste.
Problemet er at vi tvinges til at putte alle vores æg i en og samme kurv.
Når adgangen til alle vores informationer, konti, signaturer osv. er kontrolleret samme sted fra, så bliver dette sted et mål for folk med onde hensigter.
Hvis vi laver en løsning i stil med den i artiklen beskrevne, så er der bare nogen som angriber DNS'en e.lign. En løsning med kraftig kryptering mellem bruger og DanID (baseret på lange engangsnøgler gemt på en USB nøgle e.lign.) er en forbedring, men vil blot blive angrebet imellem DanID/bruger og websitet. Der er sikket forbedringer til sidstnævnte setup, men pointen er at den aldrig bliver sikker nok, sålænge at een "nøgle" åbner alle døre.
Hvad løsningen på problemet er, ved jeg ikke, men jeg syntes ikke om at alle mulige offentlige og mindre offentlige websider udbyder alverdens informationer om mig til enhver som formår at skaffe sig adgang via DanID.

  • 3
  • 1
Christian Nobel

Hvad løsningen på problemet er, ved jeg ikke, men jeg syntes ikke om at alle mulige offentlige og mindre offentlige websider udbyder alverdens informationer om mig til enhver som formår at skaffe sig adgang via DanID.

Mon ikke løsningen er at vi erkender at IT ikke er så let som nogle vil foregøgle befolkningen.

Rigtig mange mennesker har et blasert forhold til computere, for bevares, set på overfladen er alt blevet lettere, men det er da kun fordi der er et kæmpe lag nedenunder som er vildt komplekst og som er baseret på årevis af udvikling.

Vi er nødt til at tage sikkerhed alvorligt, og det gøres bla. ved at tage den kompetente borger seriøst, samt ikke at lægge alle æg i samme kurv.

Det store spøgelse i hele denne diskussion er at det offentlige har vejret morgenluft og tror der kan spares penge ved at lade borgerne agere tasteaber - og i det spil mener man åbenbart at midlet helliger målet, og at man kan tillade sig at gå på kompromis med sikkerheden.

Men det går altså ikke, så vi er nødt til at gå tilbage til start, koble hjernen ind, og så lave decentrale løsninger hvor der ikke bruges samme nøgle til alt - man har immervæk heller ikke samme fysiske nøgle til huset, bankboksen, bilen, cyklen, haveskuret, konens kyskhedsbælte, og hvad ved jeg.

Det eneste der kan begrunde en monolitisk løsning som NemID er en sygelig trang til at indføre et central overvågningssystem, som Honecker ville være grøn af misundelse over, og hvis ikke vi gør modstand nu, så tegner det ikke godt for fremtiden.

  • 5
  • 0
Christian Nobel

Hvad skal man sige, når vi samtidig ser overskrifter som at 9 ud af 10 er glade for NemID?

Det er jo det der er så deprimerende: Jette og hendes kumpaner sidder med et gigantisk propaganda apparat, som kan blive ved med at bringe løgn, usandheder, omgåelse af sandheden og fortielser på banen.

Og vi andre kan kun stå på sidelinien og pippe lidt samt skrive hist og pist, men selv om der så er politikere (hvilket der trods alt nok er) der har læst det, så sker der intet.

Problemet er at Kafka har ikke levet forgæves, og f.eks. NemID er et sådan Kafkask projekt, for uagtet hvor meget der fra kompetent side gøres opmærksom på det, selv til de såkaldte magthavere, så er chancen for at det bliver ændret på det uhyggelig lille - og på sigt bliver vi alle til Josef K'ere i det spil.

  • 4
  • 1
Log ind eller Opret konto for at kommentere