DanID: Java-applet skal beskytte mod man-in-the-middle-angreb

Den omstridte Java-applet i NemID-løsningen er blandt andet valgt, fordi det hæver sikkerheden, når der skal overføres dokumenter, lyder forklaringen fra DanID.

En tilsyneladende lille og undseelig del af det samlede NemID-design har fået bølgerne til at gå højt om den nye officielle digitale signatur. Brugen af en signeret Java-applet, når brugerne skal logge ind med NemID, har fået IT-Politisk Forening op i det røde felt.

Version2 har tidligere spurgt DanID, som står bag NemID, om grunden, og har bragt svaret. Men da svarede DanID på, hvorfor man valgte en signeret Java-applet, i stedet for en usigneret, uden at forholde sig til andre mulige teknologier som almindelig SSL-kryptering.

Når brugerne accepterer en signeret applet, giver man samtidigt appletten fuld adgang til computeren, og det er helt unødvendigt, når nu den private nøgle ikke længere ligger lokalt, men på DanID's servere, mener foreningen.

Læs også: Forening: Unødvendigt at bruge usikker Java-applet til NemID

Nu har DanID fremlagt flere oplysninger, både som offentlige pressemeddelelser og i skriftlige svar til Version2, og her fremgår det, at en løsning med SSL-kryptering af data med almindelig HTML ikke bliver anset som sikkert nok.

For eksempel skal NemID også kunne bruges i sammenhænge, hvor borgerne kan up- og downloade dokumenter undervejs. Det kan være en bolighandel eller en aftale med forsikringsselskabet, som så kan gemmes lokalt.

I den forbindelse beskytter Java-appletten mod man-in-the-middle-angreb, fordi DanID med denne løsning har bedre kontrol over dataene hele vejen fra afsender til modtager. Man-in-the-middle-angreb foregår ved, at malware ændrer i de data, brugeren ser i browseren eller modtager, og her er Java-appletten altså bedre sikret end SSL-kryptering, lyder forklaringen.

Det gælder også helt generelt, skriver Søren Winge, kommunikationschef hos PBS, som er DanID's moderselskab, i debatten på Dorte Tofts blog.

»Anvendelsen af en applet sker primært fordi, at teknologien indeholder væsentlige funktioner i forhold til at beskytte mod kendte hackerangreb (bl.a. Browser Helper Objects - BHO), hvor brug af HTML og SSL ikke yder nok beskyttelse. Det er altså nødvendigt at have et stykke kode på brugerens PC, og her er appletten valgt, fordi den har en høj modenhed og lav påvirkning på brugeren,« lyder begrundelsen.

Appletten bliver også brugt til at gemme en lokal log-fil, der i krypteret form gemmer oplysninger om eventuelle problemer, der opstår med at køre NemID-appletten.

»DanID gemmer logfiler lokalt af hensyn til efterfølgende fejlsøgning. Det har været foreslået, at appletten kunne sende informationen. Men af privacy årsager har vi valgt ikke at sende log informationen til DanID, men i stedet gemme filen på brugeres disk og lade det være op til brugeren at sende filen med f.eks. e-mail, hvis brugeren måtte have brug for det. Det er kun oplysninger om applettens funktioner, der gemmes i log filen,« skriver kommunikationschefen.

Poul-Henning: NemID er et fremskridt

Dorte Toft har i øvrigt også spurgt Version2-blogger Poul-Henning Kamp om hans mening om sikkerheden ved NemID generelt, fordi han har erfaring med kryptering.

Hans svar lyder - med en tekst, der egentligt var tiltænkt Version2-bloggen - at NemID er et fremskridt.

»Ja, det (NemID, red.) kunne være bedre, men det kunne ved gud også nemt have været meget værre. Pris jer lykkelige for fremskridt, hvor små de end måtte være,« konkluderer han.

Ved at bruge engangskoder på papkort får man en god allround-sikkerhed, mener han, når nu folk har så lidt styr på, hvad der kører af malware på deres computere, skriver han i indlægget under overskriften 'NemID: Bedre end meget andet offentlig IT'.

Læs også Poul-Henning Kamps nye blogindlæg om NemID: NemID – Har I drukket af natpotten?

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (21)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Per Hansen

man vil lave man-in-the-middle angreb, så angriber man DanId istedet, da man så får FULD adgang til alle data/konti/identiteter for alle danskere. DER er problemet!

  • 0
  • 0
Peter Mogensen

Fantastisk som DanID kan snakke udenom.

At der er dele af problemet man evt. kan løse bedre med en applet ændrer jo ikke på det grundliggende problem at brugeren ikke har noget valg. Man er tvunget til at stole på DanID og man er tvunget til principielt at give dem fuld adgang til ens computer. Ikke at jeg umiddelbart tror de vil misbruge det, men det er for et system, der er så centralt i samfundet ganske enkelt designet forkert.

Jeg må anbefale folk at køre alle NemID opgaver i en selvstændig virtuel maskine. Så er man da ude over de ubegrænsede applet-rettigheder.

... og så er vi slet ikke nået til de centralt lagrede private nøgler.

  • 0
  • 0
Jonas Finnemann Jensen

Dette er godt nok lidt off-topic, men hvis man trænger til et godt grin, kan man læse om teknikken bag NemID her: https://www.nemid.nu/om_nemid/hvad_er_nemid/sikkerhed/teknikken_bag_nemid/

Der står bl.a.

I PKI er det et afgørende element, at kun brugeren selv har kontrol over den private nøgle. I NemID er brugerens private nøgle opbevaret på en central signaturserver...

Og

Generering og anvendelse af den private nøgle kan kun foregå i specielle sikrede kryptografiske hardware-moduler under brugerens fulde kontrol

Gad godt vide hvordan jeg har fuld kontrol over det "specielt sikrede kryptografisk hardware-modul" :)

On topic, enig, kan ikke se hvad de skal med en signeret (closed-source) java-applet... De er også begyndt at bruge det til digital signatur... Hvilket er endnu mere tvivlsomt!

  • 0
  • 0
Niels Didriksen

Hvorfor lugter det her af, at en håndfuld DanID folk har været hasteindkaldt til at finde på et (bare et eller andet) svar til den frådende horde? (Som de fleste af deres svar på kritik stinker af)

"Hmm.. det skal være noget med sikkerhed.. Noget med at brugeren er dum.. nåhnej den har vi brugt.. noget med farlige pædofile nazi terrorister.. ja, det kan bruges.. hmm.. noget med internettet generelt ikke kan bruges til vores "enorme" sikkerhedskrav.. man-in-the-middle...? Jaaaaa det lyder tilpas farligt og creepy, den napper vi...."

Og hvad pokker er nu det med at de ikke kan finde ud af at lave en sikker download af dokumenter uden eksekverbar kode på brugerens pc (for mobiler ect. er åbenbart permanent droppet i denne latterlige vision for et digitalt samfund)... Det er godt nok synd for de lande omkring os, der anvender åbne standarder og testede metoder, at de er så hamrende usikre...

Og forresten så vil jeg IKKE opfordre alle NemID brugere til at komme til at smide deres papkort ud hver dag, for derefter at bestille nye næste dag, da det jo ville være en voldsom belastning for nemid hvis der var ret mange der kom til det.

  • 0
  • 0
Flemming Frandsen

I gamle dage (med digital signatur) var det ikke muligt at lave et angreb på en klient, uden at kompromittere klienten.

Med NemID SSO'en er transport-krypteringen skilt ad fra authentication, så der er ingen forhindringer i vejen for at lave en MITM hvor man:

1) Proxy'er for netbanken eller T&S, men serverer siderne via http.

2) Laver om på siderne så de inkluderer en kosmetisk identisk applet i stedet for NemIDs, som ikke laver andet end at sende alle indtastningerne fra brugeren tilbage til proxyen.

3) Tilbage på proxyen kører man det rigtige website i en rigtig browser, men i stedet for at checke åbningstiderne i børnehaven på kommunens website bruger man pap-koderne fra brugeren til at dumpe alle brugerens aktier, brugeren stikker man selvfølgelig bare en fejl, så får man en ny pap-kode.

Mao: At bruge den Java Applet gør jo at man rigtigt nemt kan lave en Man In The Middle, helt uden brugeren har nogen chance for at opdage det (nej, brugere kan ikke i praksis se forskel på http og https).

  • 0
  • 0
Lars Sørensen

Hvorfor ikke skelne mellem hvad brugeren vil: 1) Netbanking - Her har Jyske Bank været nævnt nogle gange. Papkort, HTTPS, ingen Java-Applet. Det virker. Det vil jeg gerne kunne mobilt. Kunne jeg før, kan ikke når jeg kummer på NemID. 2) Kommunikation, filudveksling - Det vil jeg nok gøre hjemmefra. Her kan jeg også leve med en applet.

Jeg antager at også her gælder 80/20 reglen: 80% vil kun bruge netbank, men begrænses af der øvrige 20% behov for filudveksling.

Og ligeledes i samme hug: Hvorfor kan den digitale signatur ikke leve ved siden af NemID? Fordi vi i Danmark kun kan(vil?) bruge en metode til det hele...

Internettet har altid - trods koordinerende standarder - været heterogent og vil altid være det.

  • 0
  • 0
Morten Borg

Jeg har ikke nok teknisk indsigt i sikkerhedsmodellerne til at tale for eller imod deres argumenter, men at fremhæve det som en fordel at appleten kan gemme en logfil over problemer med appletten forekommer som en ren absurditet...

  • 0
  • 0
Henrik Stig Jørgensen

I den forbindelse beskytter Java-appletten mod man-in-the-middle-angreb, fordi DanID med denne løsning har bedre kontrol over dataene hele vejen fra afsender til modtager.

Java-appletten INTRODUCERER et man-in-the-middle-angreb!

Man-in-the-middle-angreb foregår ved, at malware ændrer i de data, brugeren ser i browseren eller modtager, og her er Java-appletten altså bedre sikret end SSL-kryptering, lyder forklaringen.

Forkert. Appletten bruger vel selv SSL mellem sig og DanID serveren, eller har I opfundet jeres helt egen krypteringsprotokol? Det er i øvrigt som at sammenligne pærer og bananer - Java vs. SSL. Det er dybt usagligt.

Når SSL-krypteringen ikke anses som værende sikker nok kunne det måske skyldes at der mangler en klientside-validering af server-certifikatet, men det ville der implicit have været hvis man havde brugt Mutually Authenticated SSL - noget man aktivt har fravalgt da det kræver at privatnøglen befinder sig på klientsiden.

Det er altså DanIDs egen skyld at de ikke kan udnytte SSL i sin sikreste form.

I øvrigt er man-in-the-middle ikke nødvendigvis noget der sker på klientmaskinen; det kunne også være en uvedkommende tredjepart, som gennem et elendigt sikkerhedsdesign får al kommunikation mellem to parter proxyet/relayet gennem sig i ukrypteret form eller hvor man er i stand til at fjerne krypteringen. Kender vi den slags man-in-the-middle-angreb fra den virkelige verden? Ja, det hedder NemID!

Anvendelsen af en applet sker primært fordi, at teknologien indeholder væsentlige funktioner i forhold til at beskytte mod kendte hackerangreb (bl.a. Browser Helper Objects - BHO), hvor brug af HTML og SSL ikke yder nok beskyttelse. Det er altså nødvendigt at have et stykke kode på brugerens PC, og her er appletten valgt, fordi den har en høj modenhed og lav påvirkning på brugeren,

Igen er det dybt usagligt; man kan da også bruge applets i two-way SSL (altså hvor privatnøglen ligger på klientmaskinen). Det er ikke enten-eller.

Det har været foreslået, at appletten kunne sende informationen. Men af privacy årsager har vi valgt ikke at sende log informationen til DanID, men i stedet gemme filen på brugeres disk

Af privacy årsager? I har jo allerede krænket enhver form for privacy-hensyn man kunne have;

  • en signeret bootstrap-applet, der downloader arbitrær kode til folks computer og har fuld adgang til hele maskinen.

  • et statssanktioneret man-in-the-middle-angreb hvor DanID har fuld og ubesværet adgang til al information der sendes eller stilles til rådighed for borgeren gennem NemID.

  • 0
  • 0
Rene Madsen

men jeg er vist ved at blive klogerer...

Intet valg og vi bliver ved med at sige det er sikkert og for dit eget bedste til du ikke kan huske andet.

Surt opstød kan forekomme - var ved at få kaffen galt i halsen, da jeg læste artiklen. For at beskytte mod man-in-the-middle angreb, det er da den værste gang teknisk inkompetence jeg længe har hørt!

  • 0
  • 0
Jesper Mørch

For at beskytte mod man-in-the-middle angreb, det er da den værste gang teknisk inkompetence jeg længe har hørt!

Hvor er det dog dejligt at vi i Danmark slet ikke behøver at spekulere på IT-sikkerhed længere... Når de som står bag en af landets største sikkerhedsmæssige digitale fadæser nogensinde i ramme alvor mener at man beskytter mod man-in-the-middle-angreb ved selv at begå det... Til gengæld trækkes det så ned over hovedet på størstedelen af befolkningen. Men, når de der står bag den selvudråbte sikkerhed ikke kan kende forskel på man-in-the-middle og SSL, har vi ikke længere noget at frygte... Vores sikkerhed er allerede fuldt kompromitteret... Velkommen til DDR ver. 2

  • 0
  • 0
Jesper Mørch

En tilsyneladende lille og undseelig del af det samlede NemID-design har fået bølgerne til at gå højt om den nye officielle digitale signatur.

Hvilken del af »Digital Signatur« er det I ikke kan stave til?? NemID er IKKE, jeg gentager IKKE!!!!! en digital signatur!!! Hvornår holder I op med at misbruge koncepterne?

Selvom jeg påstod jeg var Kong Hans og fik en offentlig person til at give mig ret, ville det ikke gøre mig kongelig...

Nu må I altså snart holde op med det sludder i hver eneste artikel om NemID! Der er i stedet tale om afløseren for den nuværende digitale signatur.

  • 0
  • 0
Jesper Louis Andersen

Men svaret forholder sig ikke til kritikken. Dels er der rettighedsspørgsmålet: "Hvorfor skal applet'en have adgang til filsystemet?". Jovist, for at kunne skrive til en krypteret logfil. But why? Der er givetvis ikke nogen lokale informationer som det kunne være interessant at opbevare, går jeg ud fra. Argumentet om brugerens privacy i forbindelse med logfilen synes jeg er forkert. Hvis der er tale om privacy, så skal jeg da netop kunne se hvad der er i den logfil jeg sender til DanID - og min garanti for at der ikke sendes andre informationer over den krypterede forbindelse har jeg alligevel ikke.

Dertil kommer at ethvert angreb mod NemID formentlig starter fra klientmaskinen selv, hvorfor hele diskussionen om man-in-the-middle er ligegyldigt. Hvis argumentet have været at man ville undgå cross-site scripting og andet i den retning, så havde det været et sagligt argument. Før dokumentet afsendes eller efter modtagelse er dokumentet ukrypteret, så der kan man ændre det.

Jeg kan godt se at det er "nemmest" hvis applet'en også lige kan klare ærterne i den sag og den sag. Men jeg er ikke sikker på at jeg bryder mig om tanken.

  • 0
  • 0
Anonym

Først og fremmest, så er jeg enig med DanId i at det er nødvendigt at kunne validere den kode som kører på computeren for at forebygge man-in-the-middle på klienten. Hvordan skulle en modpart ellers kunne stole på authentikeringen? Det er ikke mit indtryk at løsningen tilvejebringer dette, men behovet er der.

Det etablerer 2 nye problemer

a. Risikoen for central misbrug som hele diskussionen drejer sig om. Jeg vil ikke kommenterer om det vil blive misbrugt, blot pointerer at der er et behov for at beskytte mod bagdøre til borgernes computere.

b. Fastlåsning af nøglebrug. Hvad der et mange, mange gange værre og i debatten overset problem er at PBS på denne måde gentager deres kommercielle magtposition som de misbruger med dankortterminalen med at dikterer hvordan man bruger sine nøgler.

En ting er at den private nøgle er kontrolleret af en fremmed part. En langt værre problemstilling er at denne fremmede part vil diktere hvordan man bruger sin nøgle og gør det på en måde som kun gavner deres kommercielle interesse (og en bureaukratisk kontrolinteresse).

Så kan vi venligst reducere debatten til a) Hvopdan forebygger vi at man centralt fra kan få en bagdør til borgernes it-systemer. b) Hvordan sikrer vi at borgerne kan bestemme over deres egen identitet og navnlig sikre at de kan få en reel kontrol over deres mange forskellige nøgler uden en centralt dikteret one-size-fits-all.

  • 0
  • 0
Jesper Kristensen

Så i bruger en signeret Java-applet for at beskytte mod malware der har inficeret Internet Explorer (BHO)?

Hvad får jer til at tro at denne malware ikke vil angribe jeres Java-applet eller for den sags skyld et hvilket som helst andet program, når den først er kommet ind?

Så vidt jeg ved dækker begrebet man-in-the-MIDDLE ikke situationen hvor malware har inficeret KLIENTEN.

Synes i selv det er en god ide at beskytte NemID mod malware på klienten ved at kræve af brugeren at de skal acceptere en sikkerhedsadvarsel der mest af alt ligner installation af malware?

Ja, dagens compuger-brugere er ikke gode til at beskytte deres computer, og det bliver ikke nemt at lære dem bedre, men de hjælper bestemt ikke at lære dem at de SKAL gøre nøjagtigt hvad de normalt IKKE MÅ gøre, nemlig ukritisk acceptere sikkerhedsadvarsler.

Sikkerhed uden usability er sikkerhed hvor det sidste led i kæden mangler fuldstændigt.

  • 0
  • 0
Niels Dybdahl

Så kan vi venligst reducere debatten til a) Hvopdan forebygger vi at man centralt fra kan få en bagdør til borgernes it-systemer. b) Hvordan sikrer vi at borgerne kan bestemme over deres egen identitet og navnlig sikre at de kan få en reel kontrol over deres mange forskellige nøgler uden en centralt dikteret one-size-fits-all.

Her er mit bud: a) Med de nuværende operativsystemer (Windows, Linux, MacOS) er det ikke muligt at sikre sig mod bagdøre. Hvergang man installerer et eller andet tilfældigt program, har dets installationsprogram mulighed for at installere hvad som helst. De nye operativsystemer til mobiltelefoner (Android, iOS) er gode skridt på vejen til sikre operativsystemer da de er opbygget med en langt højere grad af sandboxing.

b) De fleste ved alt for lidt om IT til at de kan beskytte deres identitet fuldt ud. Svindlere vil kunne få det til at se ud som om man identificerer sig et andet sted end der hvor man faktisk gør det eller godkender noget andet end man tror.

Så jeg tror ikke på at der er nogen perfekt løsning.

  • 0
  • 0
Keld Simonsen

DanID startede med at sige at brug af signeret java-applet var fordi de skulle lave deres egen cache.

Nu siger de at det også er fordi andre skal kunne få adgang til at uploade dokumenter. Upload/download af dokumenter er vel uafhængig af identificeringen?

Vi har fået at vide at det kun var appletten der kunne tilgå klientens filsystem. Nu får vi at vide at det er for at brugeren af appletten kan få filsystemsadgang?

Og vi får at vide at DanID logger transaktionerne lokalt. Hvorfor i hulens navn skal de gøre dette? Det ville jeg da tro var bedst at lave centralt. Det bør da ikke være en af hovedbegrundelserne for en dårlig sikkerhedsmodel?

Og det skal være fordi brugeren så kan indlevere den krypterede log i tilfælde af fejl. Det kan almindelige brugere da ikke finde ud af!

Jeg synes også der kunne have været brugt åbne standarder, i stedet for egenudviklet signeret lukket java-applet. Hvor er Folketingets krav om brug af åbne standarder? Der bør være en comply-or-explain redegørelse omkring B103 for hele projektet. Hvor er den?

  • 0
  • 0
Bjarne W. B. Petersen

Hvorfor lugter det her af, at en håndfuld DanID folk har været hasteindkaldt til at finde på et (bare et eller andet) svar til den frådende horde? (Som de fleste af deres svar på kritik stinker af)

Nu har jeg absolut ingen kompetencer til at vurdere hvem der har fat i den lange ende. Men da jeg læste artiklen sad jeg og tænkte præcist det samme: DanID's argumentationer lugter langt væk af efterrationaliseringer og java-applet'en får løbende påklistret flere og flere fantasifulde funktioner.

  • Bjarne
  • 0
  • 0
Log ind eller Opret konto for at kommentere