DanID: Derfor bruger vi en signeret Java-applet

Den Java-applet, NemID bruger, kan læse alt på din computer, siger IT-politisk Forening. Det afviser DanID, som her forklarer grunden til den signerede Java-applet.

»Store huller i ny digital signatur« lyder det på forsiden af avisen Børsen tirsdag, med udgangspunkt i en kritik fra IT-Politisk Forening. Brugen af signeret Java-applet, når man skal logge ind med NemID, er en fejl, mener Niels Elgaard Larsen fra foreningen, for dermed får DanID fuld adgang til folks computer, lyder kritikken.

Læs også: NemID's Java-hul: Din bank kan snage i alt på din harddisk

DanID afviser blankt, at NemID's Java-applet indeholder funktioner, der kan bruges til at snage på folks computere. Men hvorfor overhovedet bruge en signeret applet, med så omfattende rettigheder, i stedet for en almindelig, som kører i sandbox og dermed er 'lukket inde'?

Det spørgsmål har DanID's udviklerteam besvaret skriftligt. Ifølge DanID ligger årsagen til valget af den signerede applet primært i, at man ville sikre kompatibilitet med ældre versioner af Apples Mac OS og med tidligere versioner af Java. For at minimere muligheden for misforståelser, bringer Version2 her svaret uredigeret:

Ældre version af Mac OS understøtter ikke Liveconnect, som bruges til integration med brugerens browser. Liveconnect er koder, som binder browser og applet sammen og gør det muligt for DanID applet at kalde Javascript.

I ældre Mac OS versioner eksisterer Liveconnect ikke, og det er derfor nødvendigt at implementere applet-til-browser ved at applet etablerer en netværksforbindelse til service-udbyderen. Etablering af netforbindelse til serviceudbyderen kræver, at applet er signeret . Denne understøttelse er den samme som i Digital Signatur (OpenOCES).

DanID-applet benytter popups, for eksempel ved signering. Når applet laver et popup-vindue, vises en advarsel nederst i vinduet: ?Warning, applet window?. Denne advarsel vises ikke, hvis applet er signeret.

DanID-applet skal understøtte vedhæftede bilag. Disse bilag skal brugeren kunne gemme på disk. Al disktilgang fra applet til disken kræver, at applet er signeret. DanID applet's understøttelse for bilag er den samme som i Digital Signatur (OpenOCES).

DanID-applet har indbygget egen load og caching af appletkomponenter. Tests har vist, at den indbyggede caching af Java-applet i Java's egen plugin er upålidelig og inkonsistent på tværs af Java-versioner, operativsystemer og browsere. Denne loader kræver, at DanID-applet er signeret.

DanID-applet benytter samme loader-mekanisme som findes i Digital Signatur (OpenOCES).

DanID-applet gemmer en fejllog på brugerens disk, som indeholder information, som gør det muligt for DanID-support at fejlsøge og udbedre fejl i applet. Denne fejllog er krypteret, så angribere ikke får adgang til informationer i loggen. Fejlloggen indeholder ikke personfølsom information. Disktilgang fra applet kræver, at applet er signeret.

Hvad mener du? Er det gode grunde til at bruge en signeret Java-applet?

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

Så for at implementere dokument signing i denne forkvaklede løsning hives sikkerheden på alm sso ned i knæ højde.

Jeg kunne godt tænke mig at kunne vælge SSO only mode via SSL og serverside uden applet overhovedet.

  • 1
  • 0
Jesper Udby

Hvis det er nødvendigt fra en browser at tilgå (læse) filer på brugerens harddisk (uden disse sendes over linien), så skal der enten en signeret applet til, eller noget ligeså gustent (windowsspecifikt) plug-in til.

Og det er der ikke noget nyt i, sådan har (de fleste) internetbanker fungeret siden sidst i 90'erne...

  • 0
  • 0
Jesper Lund

Ifølge DanID ligger årsagen til valget af den signerede applet primært i, at man ville sikre kompatibilitet med ældre versioner af Apples Mac OS og med tidligere versioner af Java.

Hvis DanID havde valgt en løsning der ikke krævede installation af software på brugerens computer, kunne kompatibilitet med ældre versioner af java være ligegyldig.

Jeg tror at jeg vil lave en virtual machine (sandboxing) som alene bruges til netbank logon når nu det fantasiske NemID kommer til mig..

  • 4
  • 0
Jesper Udby

Glimrende pointe.

Men spørgsmålet der blev stillet var:

Hvad mener du? Er det gode grunde til at bruge en signeret Java-applet?

Og hvis man (jeg ved ikke af hvilken grund) har behov for at tilgå filer på brugerens harddisk via en java-applet, så skal den være signeret...

  • 0
  • 0
Allan Ebdrup

Ja og uden brug af Java ville nemId også virke på devices som iPad, PS3 osv. Hele argumentet om at nøglefilerne skal ligge centralt fordi det skal være nemt at logge ind overalt, går lidt fløjten når man så vælger en løsning, der ikke virker på alle devices.

De kunne altid lave en mulighed for at køre en applet, hvis der var brug for vedhæftede filer (men det må da kunne løses også uden java)

  • 2
  • 0
Jesper Lund

Men kommer vi så ikke til at lave en VM til banken, een til sundhed etc.

OCES delen bliver fravalgt når jeg bliver tvunget til at oprette NemID [1]. Min private nøgle skal kontrolleres af mig, og mig alene, og det udelukker OCES delen af NemID.

Det vil i øvrigt heller ikke hjælpe en pind med flere lokale VM'er da samkøringen mellem de forskellige logons sker på den (for dig) usikre centrale server.

[1] NemID er to helt separate løsninger: et netbank logon og noget som ITST kalder "digital signatur" (OCES delen). De har samme brugergrænseflade, baseret på OTP papkort, men så hører lighederne også op. NemID til netbanken er relativt uskyldig, selv om det ikke er så smart med et single sign-on hvis man har flere netbanker. Men OCES delen er en ubeskrivelig katastrofe, så den kommer jeg ikke til at benytte mig af.

  • 1
  • 0
Nils Bøjden

Og det må man så sige at de påstår at de har:

"DanID-applet gemmer en fejllog på brugerens disk, som indeholder information, som gør det muligt for DanID-support at fejlsøge og udbedre fejl i applet"

Hvorfor man ikke sender disse info når det er nødvendigt fra en cache kan man så spekulere på. Kun ved at have tilgang til NemID design specseller tilgang til koden, har man mulighed for at se og gennemskue de rationaler som ligger til grund for design.

For øvrigt vil vi ikke få adgang til koden, da DanID også ved tidlige lejligheder har påberåbt sig brugen af "Security by Obscurity". Her tænker jeg bla. på de processer man har til at håndtere DDOS angreb.

  • 1
  • 0
Jesper Lund

Men får man kun appletten, hvis man vælger OCES delen til ?

Nej, du undgår ikke appletten da UI er det samme for de to varianter af NemID. Men ved at fravælge OCES delen undgår du at der er en permanent "privat" nøgle uden for din (ene)kontrol. Netbank delen er, så vidt jeg har forstået teknikken, baseret på nogle temporære keys som kun eksisterer under den enkelte netbank session (altså reelt et password + OTP logon, uden at prætendere at være en "digital signatur", hvilket er fair nok).

  • 1
  • 0
Henrik Stig Jørgensen

Så længe vi ikke kan køre med en udgave vi har compiled selv, er det umuligt at være sikker på at den source vi får at se, svarer til det der rent faktisk bliver kørt.

Nej, det ville det alligevel være. En signed applet har fuld adgang til alle JFC-classes; DanID kan til enhver tid kalde Runtime.exec() eller bootstrappe nye jars gennem URLClassloader.

Men hvorfor denne fokus på privacy på lokalmaskinen når det nu forholder sig sådan, at NemID også kan bruges af DanID til at tømme din bankkonto, sælge din elektroniske patientjournal eller din straffeattest til højestbydende, eller bedrage andre med din identitet. Er dette trods alt ikke værre end den java-applet?

  • 1
  • 0
Jakob Hansen

Der burde være en måde hvorpå man kunne sandboxe plugins til browseren, fx java plugins. Det løser selvfølgelig ikke det oprindelige problem, men så kunne man nemmere styre og se hvad NemID foretog sig på ens computer. Måske findes der allerede sådan en løsning?

  • 0
  • 0
Jesper Mørch

OCES delen bliver fravalgt når jeg bliver tvunget til at oprette NemID [1]. Min private nøgle skal kontrolleres af mig, og mig alene, og det udelukker OCES delen af NemID.

Som jeg har forstået det, har DanID alligevel adgang til din private OCES-nøgle. Du har bare ikke fået adgang til den hvis du fravælger OCES.

Jeg har tænkt mig at opsige min netbank, når det nærmer sig at mit registreringsnummer skal overgå til NemID. På den måde kan jeg håbe på at DanID ikke når at få oprettet et OCES-certifikat til mig før jeg afmelder det hele.
- Indrømmet, jeg beholder min digitale OCES-signatur, som trods sine dårligdomme er klasser bedre end det hø PBS har strikket sammen. Den udløber først i maj-juni 2012, og til den tid har vi formentlig oplevet så massive problemer med NemID at de allerede har skullet forklare sig flere gange i f.eks. DRs Kontant. Den mediebevågenhed bør gøre, at man som almindelig borger her i landet ikke tvinges til at benytte NemID for at tilgå den offentlige forvaltning.

  • 0
  • 0
Niels Dybdahl

Der burde være en måde hvorpå man kunne sandboxe plugins til browseren, fx java plugins. ... Måske findes der allerede sådan en løsning?

Den findes også: Nemlig undlad at signere appletten. Så kører appletten automatisk i en sandbox og den får ikke adgang til noget på den lokale PC bortset fra skærm og tastatur.

Den løsning burde være valgt fremfor en signeret applet når der ikke er nogen tvingende grund til ikke at køre i en sandbox.

Jeg har iøvrigt lige prøvet Jyske Netbank på min Androidtelefon. Jyske Netbank har hidtil kørt med en lignende papkorts løsning og den virker fint på mobiltelefonen. Hvad er argumentet for at DanIDs løsning ikke gør det?

  • 1
  • 0
Henrik Schmidt

Det, som de har svaret på er hvorfor appletten skal være signeret. Altså signeret vs. ikke-signeret applet.

Det, der er interessant er hvorfor de overhovedet har brug for en applet. Hele idéen med NemID er at flytte mekanismen fra folks egne computere til NemID's servere.

En signeret applet var et nødvendigt onde med digital signatur fordi den private nøgle lå på brugerens computer. Det gør den ikke længere, så hvorfor skal NemID have adgang? Pga. en log-fil? Kan de ikke lave den på server siden?

Helt ærligt, NemID, kom ind i kampen.

  • 0
  • 0
Jesper Louis Andersen

Søren Hilmer rammer plet: Kildekode på applet'en så vi selv kan oversætte den. Jeg stoler mere på en kæde der ender i GCC end jeg stoler på DanID pt.

Iøvrigt er eet af de store problemer at standarden for NemID ikke mig bekendt er åben. Jeg vil kunne implementere alternative udgaver af standarden og kunne benytte dem mod DanIDs servere, tak. Det ville være i borgerens interesse med noget konkurrence på det område.

  • 0
  • 0
Kai Birger Nielsen

Jeg tror ikke at du får kildeteksten fra dem. Jeg spurgte efter orienteringsmødet i Århus og fik at vide at de ikke ville gøre det nemt for phishere at lave noget, der lignede på en prik.

Det er sikkert også derfor de ikke kan nøjes med en https form :-)

  • 0
  • 0
Stig Albjerg

Da display på mit Active Card til Danske Bank for en måned siden fejlede, fik jeg gennem banken en NemID. Det har ikke været muligt for Danske Banks og DanIDs supportere at få NemID til at fungere på min PowerPC Macintosh med Mac OS 10.4.11.
Den ældre Mac blev for nogle dage siden endelig erklæret for uegnet til NemID, og i formiddags ankom et nyt Active Card med posten.
Det sætter DanIDs erklæring om hensyn til ældre Macintosh i et noget tvetydigt lys, synes jeg.
Efter forgæves forsøg med indlogning på NemID, fandt jeg tilfældigt en fil med navnet danid.log på 80K i mit user directory på grund-niveau. Filens oprettelses- og redigerings-tidspunkter stemte med forsøg på at logge på NemID.
Efter endnu et par forsøg for nogle dage siden voksede filen til 120K.
Filen var/er ikke gjort usynlig. Den er ikke læsbar for mennesker.
Jeg blev ubehagelig tilpas, da jeg fandt den fil, som tydeligt demonstrerede hvad "Trust" til en Java applet indebærer. Den tyder også på, at programmørerne ikke har styr på (ældre) Mac maskiner.
I øvrigt kræver Active Card til Danske Bank også, at man siger "Trust" til en Java applet. Det har jeg med let ubehag gjort masser af gange de seneste år.
Jeg har aldrig forstået hvorfor det skulle være nødvendigt med den applet til Active Card - og har aldrig fået en rimelig forklaring fra Danske Banks venlige supportere. (Adgang med Active Card virker ikke, med mindre Java applet får fuld adgang).
Jeg forstår heller ikke, at en applet med fuld maskin-adgang skal være nødvendig for at kunne være med i NemID.
Hvis Big Brother ikke har skumle hensigter, er det overordentlig stupidt med det krav.

  • 0
  • 0
Slet Mig nu

Kan man ikke blot eksplicit angive i applet'en hvad man vil have adgang til (fremfor hele disken) og så ellers tilbyde folk en Java policy file som sikrer at DanID ikke kan lave andet end logge til en bestemt fil m.m?

  • 0
  • 0
Niels Dybdahl

Kan man ikke blot eksplicit angive i applet'en hvad man vil have adgang til (fremfor hele disken) og så ellers tilbyde folk en Java policy file som sikrer at DanID ikke kan lave andet end logge til en bestemt fil m.m?

Nej det synes jeg ikke er ok. Som andre har påpeget er logning ikke nødvendig på den lokale PC. Det kan gøres på serveren.

Man kan også løse problemet med de gamle Macer ved at lade "normale" brugere logge på med en usigneret applet (sandbox) og så lade gamle Macer få en alternativ login med en signeret applet.

Men så kommer spørgsmålet med mobiltelefoner som ikke kan køre javaappletter. Så vidt jeg har forstået er hovedårsagen til at der vælges en javaapplet fremfor en javascript løsning (som jyskenetbank pt har til deres lignende løsning) at det skal være sværere for phishere. Jeg synes ikke at det er betryggende hvis beskyttelsen mod phishere ligger i at det er "svært" at efterligne et design på en brugerflade.
Jeg håber at DanID i det mindste har skrevet grundreglen mod phishere på loginsiden (log aldrig ind via et tilsendt link). Hvis phisherne kopierer alt fra loginsiden, så advarer de mod sig selv, hvis ikke, så afviger de en del fra det oprindelige design.

  • 1
  • 0
Henrik Mikael Kristensen

Efter forgæves forsøg med indlogning på NemID, fandt jeg tilfældigt en fil med navnet danid.log på 80K i mit user directory på grund-niveau. Filens oprettelses- og redigerings-tidspunkter stemte med forsøg på at logge på NemID.
Efter endnu et par forsøg for nogle dage siden voksede filen til 120K.
Filen var/er ikke gjort usynlig. Den er ikke læsbar for mennesker.
Jeg blev ubehagelig tilpas, da jeg fandt den fil, som tydeligt demonstrerede hvad "Trust" til en Java applet indebærer.

Den kan jeg slå: Jeg har også en danid.log fil på 20 kb i mit homedir på min Snow Leopard Intel Macbook, dateret den 1. juli 2010. Filen er ikke menneskeligt læsbar, har 33 nummererede entries som er base 64 encodede binaries og ligger bare og flyder synligt i Finder.

Det der gør [i]mig[/i] utilpas, er at jeg har ikke forsøgt at bruge NemID overhovedet, og jeg kan ikke få datoen til at passe med aktivitet med hverken netbank eller andre ting.

Edit:

http://groups.google.com/group/dk.edb.sikkerhed/browse_thread/thread/9b8...

  • 0
  • 0
Axel Hammerschmidt

Jeg har heller ikke Nem-id pt, men jeg har brugt noget der ligner til at komme på min pensionskasses hjemmeside. Det forgik på næsten samme måde som med Nem-id: jeg loggede på over en netbank konto hos Jyske Bank.

Kan det muligvis ikke være der - eller et lignende tilfælde - din danid.log fil stammer?

Jeg vil undersøge mine computere for, om filen findes osse hos mig. Jeg kan ikke lige huske hvilken computer jeg brugte til DIP.

  • 0
  • 0
Jesper Kristensen

Kære DanID i bytter om på årsag og virkning, og så blander i fuldstændigt irrelevante ting ind i billedet.

Jeres 6 begrundelser:

1: Kommunikation mellem Java og JavaScript på Mac.
Årsag og virkning - der bruges ikke en signeret Java-applet på grund af dette problem. Dette problem eksisterer på grund af at i bruger en signeret Java-applet.

2: Popups.
Igen årsag og virkning - uden Java ville det ikke være et problem at lave popups. Desuden er en "Warning, applet window" noget mere harmløs end den store farlige "Java Security Warning" i viser nu.

3: Adgang til bilag.
irrelevant - Der skal ikke håndteres nogen som helst form for bilag ved login til en hjemmeside. Hvis en eller anden service baseret på NemID har brug for at håndtere bilag kan det implementeres uafhængigt. Det kan implementeres i en signeret Java-applet hvis i er dovne, eller det kan implementeres sikkert med lidt HTML-snilde.

4: Java load og caching.
Igen årsag og virkning - I har ikke brug for alt muligt underligt Java-load hvis i ikke bruger en signeret Java-applet.

5: Baseret på Digital Signatur / OpenOCES.
irrelevant - bare fordi andre har lavet noget klamp før jer betyder det ikke at i også skal gøre det. De forrige løsninger havde dog en legitim grund til at få adgang, nemlig for at læse den private nøgle. Alt andet de brugte adgangen til burde de heller ikke have gjort.

6: Fejllog.
Igen årsag og virkning - Hvis i ikke brugte Java og alle mulige system-specifikke ting, var der ikke så meget der kunne gå galt og ingen grund til at have en fejllog. Der er desuden masser af andre måder at lave en fejllog på, der ikke kræver adgang til disken.

Og så er problemet heller ikke (hovedsageligt) hvad i bruger adgangen til. Problemet er at i spørger efter den.

Jeres rigtige login-skærm ligner et phishing-attack så godt (med sikkerhedsadvarsler og arbitrære domænenavne), at man ikke har nogen som helst chance for at opdage, hvis man støder på et rigtigt phishing-attack mod NemID.

  • 1
  • 0
Flemming Riis

21:11:57,7495541 java.exe 1988 CreateFile C:\Users\FR\danid.log SUCCESS Desired Access: Generic Write, Read Attributes, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: Opened
21:11:57,7495960 java.exe 1988 QueryStandardInformationFile C:\Users\FR\danid.log SUCCESS AllocationSize: 221.184, EndOfFile: 217.652, NumberOfLinks: 1, DeletePending: False, Directory: False
21:11:57,7496049 java.exe 1988 WriteFile C:\Users\FR\danid.log SUCCESS Offset: 217.652, Length: 606, Priority: Normal
21:11:57,7496368 java.exe 1988 CloseFile C:\Users\FR\danid.log SUCCESS

Må da håbe at man over tid at de selv sletter loggen :) samt jar cache som de heller ikke rydder op i (ved ikke om det egentelig er jvm ansvar)

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize