NemID med Java på vej ud? Styrelse tester løsning i Javascript

Et Proof of Concept viser vejen for en ny front-end for NemID baseret på Javascript. De foreløbige resultater er lovende, siger Digitaliseringsstyrelsen.

Det kan måske snart være slut med at se den velkendte Java-applet, når du fremover skal logge på netbanken og offentlige selvbetjeningsløsninger med dit NemID.

Java-appletten, der ind til videre er blevet vist mere end 900 millioner gange for danske NemID-brugere Illustration: Morten K. Thomsen

Et nyt proof of concept (PoC) udarbejdet for Digitaliseringsstyrelsen og bankerne ser nemlig på muligheden for at udskifte Java-appletten i brugerens frontend med en ny løsning baseret på Javascript.

»Den nuværende løsning med Java-appletten bliver udfordret på flere fronter. Blandt andet er det et problem, at den ikke virker på mobile platforme,« siger lederen af Center for digital signatur hos Digitaliseringsstyrelsen, chefkonsulent Charlotte Jacoby, til Version2.

Version2 har ikke haft adgang til at se den Javascript-løsning, der er testet, men ifølge Charlotte Jacoby ser den foreløbige konklusion 'lovende' ud.

»Selve PoC er afsluttet, men det er kun første skridt. Vi har en række tekniske, sikkerhedsmæssige, økonomiske og beslutningsmæssige forhold, vi skal have afklaret i den nærmeste tid, og herefter vil så komme en foranalyse, der kan munde ud i et egentlig projekt, hvor Java-appletten bliver skiftet ud med Javascript,« siger Charlotte Jacoby til Version2.

Hun forklarer videre, at PoC'et er blevet udarbejdet, fordi Digitaliseringsstyrelsen og bankerne har mærket et konkret behov.

»Der er ingen tvivl om, at behovet er der. Vi ville meget gerne have haft løsningen i går. Alle skriger på en løsning, der også fungerer på mobile enheder, men vi har stadig til gode at se en ordentlig business case,« siger Charlotte Jacoby til Version2.

Så vidt Version2 erfarer, er det klientsiden i form af den velkendte Java-applet, der tænkes udskiftet med en løsning i Javascript. Resten af NemID-infrastrukturen skal med ganske få tilpasninger bevares.

Da NemID blev lanceret i 2010, var der store protester over Java-løsningen fra it-folk med forstand på den slags. For at køre NemID-appletten skal borgeren nemlig give softwaren fuld adgang til hele computeren, hvilket potentielt kan misbruges, mener blandt andet IT-Politisk Forening.

Senere har den hastige udbredelse af tablets og smartphones gjort Java-løsningen endnu mere upopulær, da hverken Apples iOS, Googles Android eller Microsofts nye mobile platforme, Windows RT og Windows Phone 8, tillader Java.

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

Det bliver bare så godt. Nu skal jeg have net-bank (og det er ikke en flame-war jeg taler om :-)

Tænk sig at bruge software man har tillid til, til sin netbank. Det bliver som i de gode gamle dage før NemID. Jeg tror jeg vil prøve med Firefox på min Androide, når det er klar.

  • 17
  • 0
Oleksandr Shturmov

Ja! Det bliver endnu nemmere at hacke!

Sikkerheden bliver nu afhængig af browserleverandørens kvalitetssikring af javascript fortolkeren.

Jeg undrer mig. Hvorfor konstrueres der i stedet ikke bare en platformuafhængig offentlig/netbank browser? Bygget af dataloger, sikker fra bunden, med åben kildekode og bevist korrekt i twelf?

  • 5
  • 36
Jakob Ottesen

»Der er ingen tvivl om, at behovet er der. Vi ville meget gerne have haft løsningen i går. Alle skriger på en løsning, der også fungerer på mobile enheder, men vi har stadig til gode at se en ordentlig business case,«

Citatet udtrykker vel meget klart hvordan sikkerhed/brugervenlighed bliver underordnede aspekter i forhold til at skabe en "business case", altså en model der genererer profit. En helt igennem logisk tilgang set fra DanIds synspunkt. Men hvorfor var det igen at staten syntes at sådan en konstruktion var en god ide?

Eller tolker jeg udtrykket "business case" alt for snævert?

  • 21
  • 0
Peter Müller

Det var godt nok længe ventet.

Hvor er linket til det offentlige repository som vi kan se kildekoden i?

Eftersom det bliver implementeret med javascript kan intet på klienten jo alligevel holdes hemmeligt, så jeg går ud fra at man har valgt en fuldstændig åben model for at få så meget feedback og få rettet så mange fejl som muligt på kortest mulig tid.

  • 24
  • 3
Casper Bang

Mon ikke 60-70% af kritikken DanID har fået, netop omhandler Java delen (de resterende 30-40% omhandler lukketheden og selve nøgle-aspektet). Det glæder mig, at det ser ud til at have båret frugt, at stille disse kritiske spørgsmål.

  • 18
  • 1
Morten Hattesen

Jeg undrer mig. Hvorfor konstrueres der i stedet ikke bare en platformuafhængig offentlig/netbank browser? Bygget af dataloger, sikker fra bunden, med åben kildekode og bevist korrekt i twelf?

Det tog mig et øjeblik at indse, at det ikke var alvorlig ment, men var en sarkastisk bemærkning til NIH syndromet. God værkstedshumor!

For det var da ikke alvorligt ment, vel?

  • 27
  • 0
David Rechnagel Udsen

Ja! Det bliver endnu nemmere at hacke!

Gisp! Fordi Java er så meget mere sikkert! De hedder jo begge noget med Java! Sikke en forbedring!

Sikkerheden bliver nu afhængig af browserleverandørens kvalitetssikring af javascript fortolkeren.

Du har ret, vi burde alle sammen bruge Dart i stedet. Eller VBScript.

Jeg undrer mig. Hvorfor konstrueres der i stedet ikke bare en platformuafhængig offentlig/netbank browser? Bygget af dataloger, sikker fra bunden, med åben kildekode og bevist korrekt i twelf?

Dataloger laver ikke længere programmer. De er blevet filosofer alle sammen. De kan kun finde ud af Haskell og andre ubrugelige men interessante sprog.

Laver I nogensinde noget brugbart derude på DIKU?

  • 18
  • 9
Jacob Christian Munch-Andersen

Sikkerheden bliver nu afhængig af browserleverandørens kvalitetssikring af javascript fortolkeren.


JavaScript fortolkerne i de populære browsere er jo også kun verdens mest gennemtestede sandkasser, som består på trods af at være jordens mest eftertragtede hackermål. Det vil da være for galt at tro at det er godt nok til NemID. Specielt når nu vi har Java hvor der kun findes en ny kritisk sårbarhed sådan ca. en gang om måneden.

  • 19
  • 0
Peter Mogensen

Guderne skal vide at jeg hilser en løsning baseret på åbne standarder og u-priviligeret kode i browseren velkommen, men der er nu alligevel stadig et skær af farce over det.
... blev vi ikke i starten spist af med at Java var pine-død nødvendig?

Har noget ændret sig, eller var det blot et forsøg på at tie kritikken ihjel?

  • 18
  • 1
Peter Müller

At vi kan på nemid via javascript er naturligvis en forbedring fremfor java.

Men hvilken funtionalitet i nemid kræver overhovedet scripting?

Burde de to inputfelter og en submitknap ikke kunne laves i ren html uden javascript?

  • 14
  • 1
Jes Andersen

jeg gætter på noget til at checke op på at certificatet fra banken kommer fra den rigtige udbyder, eller lava kryptering over normal HTTP. (At du så har tabt alligevel hvis du modtager koden til at checke om koden er rigtig fra en ukontroleret kilde er jo så en hel anden sag :P)

  • 3
  • 1
Casper Bang

Burde de to inputfelter og en submitknap ikke kunne laves i ren html uden javascript?


Af ukendte årsager (auditing?), har DanID ønsket en løsning med skrivning af data på klient siden incl. fingerprinting via noget suspect JNI. Java er øjensynligt alene brugt som bootstrapper og bindeled imellem browser og nativ kode.

Man kan håbe de er blevet klar over, hvor lidt de egentlig får ud af dette, i forhold til ulemperne og spørgsmålene.

  • 20
  • 0
Tore Green

Eller tolker jeg udtrykket "business case" alt for snævert?

Business case betyder formentlig bare en beskrivelse af fordele og omkostninger udtrykt i forretningssprog såsom kroner og øre.
Det kan sagtens være andre faktorer end indtjening og omkostninger der afgør om et projekt bliver gennemført. (Sådan er det i hvert fald der hvor jeg færdes, mon ikke det samme gælder i staten.)

  • 1
  • 0
Jakob Damkjær

Jyske Banks nye App virker ? Den presenter en NemID nøglekort Challenge ved beskræftigelse på ordre... Og der er ikke noget java i den.

Er det bare en smart proxy trick fra jyske Banks side eller en alternativ implementering af NemID ?

  • 1
  • 0
Henrik Pedersen

Kald mig bare en idiot - Men det første som jeg skriver bliver sgu en "bot" til min egen private netbank, så jeg kan grafe mit forbrug via Mastercardet og hive data om nye overførsler ud.

At overføre penge kræver jo alligevel nøglekortet, og sandsynligheden for at nogle gider stjæle programmet og decompile det for passwordet er jo forsvindende lille (så kunne de lige så godt sætte en keylogger af).

Det er i hvert fald den mulighed jeg har ventet længst på.

  • 0
  • 0
Anders Brander

Min mobilbank har virket uden Java i månedsvis med pinkode-logon. Faktisk virker den så godt, at jeg tager mig selv i at hente mobiltelefonenen fremfor at hente nøglekortet.

(Man skal dog stadig bruge nøglekortet for at BRUGE penge, men ikke for at se status)

  • 1
  • 0
Thue Kristensen

Eftersom det bliver implementeret med javascript kan intet på klienten jo alligevel holdes hemmeligt, så jeg går ud fra at man har valgt en fuldstændig åben model for at få så meget feedback og få rettet så mange fejl som muligt på kortest mulig tid.

Hvordan skulle det være forskelligt fra kildekoden til NemID Java-appletten? Den kunne man jo også bare decompile. Og den kunne vel heller ikke betragtes som hemmelig.

Den decompilede java-kildekode var vel lige så læselig som den obfuskerede JavaScript som nets sikkert vil bruge i den nye udgave.

  • 1
  • 1
Nicolai Hansen

Jes Andersen: Hvis du kan skaffe et valid cert fra en anden udbyder, kan man bare strippe JavaScript koden i et Man-in-the-Middle attack. (Og JavaScript kan slet ikke tjekke certifikatet på nogen måde).

Sidste nævnte 'løsning' ("JS kryptering over HTTP") er endnu nemmmere at Man-in-the-Middle, så det hjælper intet.

  • 1
  • 2
Oleksandr Shturmov

Det tog mig et øjeblik at indse, at det ikke var alvorlig ment, men var en sarkastisk bemærkning til NIH syndromet. God værkstedshumor!

For det var da ikke alvorligt ment, vel?

Halvseriøst er det (og halvsarkastisk). Nej, Danmark har (vel?) ikke en god historie af edb projekter ude i det offentlige siden.. tja.. folkeregistret? Men overvej fordelene ved at have fuld (offentlig) kontrol over implenteringen af sikkerhedsforanstaltningerne, istedet for at stole på en lukket (udenlandsk) implementering af et underliggende teknologi. Især når det har betydning for nationalsikkerheden.

  • 3
  • 2
Hans Schou

Nicolai Hansen

Jes Andersen: Hvis du kan skaffe et valid cert fra en anden udbyder, kan man bare strippe JavaScript koden i et Man-in-the-Middle attack. (Og JavaScript kan slet ikke tjekke certifikatet på nogen måde).


Jeg antager at du har knækket https/SSL på dette tidspunkt, eller at klienten kommunikere med en falsk URL eller noget?

Sidste nævnte 'løsning' ("JS kryptering over HTTP") er endnu nemmmere at Man-in-the-Middle, så det hjælper intet.


Jyske banks løsning fungerede ved at man fik en JS-stump tilsendt. Så tastede man sin nøglekort nummer og password ind. De 2 dele blev så hash'ed og krypteret med DES og sendt retur. Hvis klienten ser en korrekt https-forbindelse i sin URL-adresselinje, hvordan er det så du vil gå imellem?

  • 2
  • 1
Nicolai Hansen

Prøv at læse hvad det er et svar til :-)

1: Jeg skriver at hvis det var teknisk muligt (hvilket det ikke er), så ville JavaScript ikke løse "forkerte/'fake' certifikat" problemet, da det tidspunkt javascripten kræder i kræft, har angriberen allerede haft adgang til at ændre i den. En løsning kunne være fx 'HTTPS pinning', men jeg prøver ikke at løse problemet, jeg siger bare at JavaScript ALDRIG kommer til at løse problemet.
2: Jyske Banks løsning har intet med det jeg skriver at gøre. Jeg svare på Jes' spekulationer til hvad JavaScript dog kunne bruges til (når en simpel HTML form burde være nok). Der er ingen grund til at kryptere det 2 gange (javascript + ssl), hvis HTTPS bliver brudt, kan angriberen bare bytte JavaScript koden ud med sin egen og lave et "live Man-in-the-Middle".
  • 2
  • 1
Morten Hattesen

Halvseriøst er det (og halvsarkastisk). Nej, Danmark har (vel?) ikke en god historie af edb projekter ude i det offentlige siden.. tja.. folkeregistret? Men overvej fordelene ved at have fuld (offentlig) kontrol over implenteringen af sikkerhedsforanstaltningerne, istedet for at stole på en lukket (udenlandsk) implementering af et underliggende teknologi. Især når det har betydning for nationalsikkerheden.

Det SIDSTE jeg ønsker, at det offentlige skulle involvere sig I, er da at skrive en cross-platform (Windows, OSX, iOS, android, Linux, you name it) browser. og kræve at denne browser bruges for at benytte NemID. Det var hvad du foreslog i din første post, ikke?

Der skal IKKE stoles på nogen implementering, men på åbne og transparente standarder som PKI, TLS og HTML, ECMA-/JavaScript (om nødvendigt).

NemID implementeringen skal ikke gøres mere kompleks med flere afhængigheder af særlige browser plugins (eller browsere), men tværtimod mindre kompleks, med færre afhængigheder og hvilende på åbne og transparente sikkerhedsstandarder.

  • 10
  • 0
Baldur Norddahl

Men hvilken funtionalitet i nemid kræver overhovedet scripting?

Du tænker at NemID kunne konstrueres ligesom OpenID-standarten. Det ville unægteligt gøre det meget mere simpelt for alle parter.

Men nu kom man for skade at kalde NemID for en digital signatur. Og udviklerne gjorde hvad de kunne for at bevare signatur-delen af projektet. Så det er faktisk sådan, at de websites der accepterer NemID-login får en digital signatur levereret direkte fra brugerens computer.

Brugeren har som bekendt ikke signaturen liggende. Så NemID "programmet" skal hente signaturen fra DanID, lave en login-besked, signere den og sende den signerede besked til websitet. Jeg er ikke 100% på om signering af login-beskeden sker på brugerens computer eller hos DanID men pointen er den samme: Java- eller JavaScript-koden har samme formål, nemlig at kommunikere med DanID først, derefter lave nogle beregninger og så sende en signeret besked videre til det website man er ved at logge ind på.

Java-koden har så også til formål at spionere på brugerne og det må de glemme hvis de skifter til JavaScript. Det er simpelthen ikke muligt at studere indholdet af din harddisk fra JavaScript. Personligt tvivler jeg også på at de nogensinde fik andet end badwill ud af det stunt.

  • 5
  • 0
Peter Jensen

Nu må det være nok med at aflæsse det hele på clienterne - bare beregn det serverside - ja det kræver måske lidt stærkere serverven, men det er det nok værd i det lange løb.

  • 0
  • 0
Henrik Pedersen

Det er selvfølgelig sandt. Men så igen, jeg vil vove den påstand at det er lettere at læse sig igennem Javascript - selvom det er obfuskeret.

Men nu er det selvfølgelig også blot en personlig holdning. Jeg er ikke just en Java guru.

  • 0
  • 0
Morten Saxov

Hvordan skulle det være forskelling fra kildekoden til NemID Java-appletten? Den kunne man jo også bare decompile. Og den kunne vel heller ikke betragtes som hemmelig.

Den decompilede java-kildekode var vel lige så læselig som den obfuskerede JavaScript som nets sikkert vil bruge i den nye udgave.


Jeg kan sige at det ikke er specielt svært at decompile nemid's javakode, og deobfuscate den - MEN, det giver bare ikke en ret meget indsigt i hvad der sker, da den blot kalder videre til de binære "gif-filer", som ikke er Java kode.

Det eneste NemID skal bruge java til, er at downloade og eksekvere binær kode som admin på din pc.

EDIT: jo, der er også lidt load af tekst felter, og fejlbeskeds ting, o.l. i java koden, men ikke rigtigt noget funktionelt spændende.

  • 2
  • 2
Kim Hansen

Senere har den hastige udbredelse af tablets og smartphones gjort Java-løsningen endnu mere upopulær, da hverken Apples iOS, Googles Android eller Microsofts nye mobile platforme, Windows RT og Windows Phone 8, tillader Java.

Det kan godt være Java er blevet upopulær i browsere. Egentligt noget jeg godt kan støtte op omkring da det vil gøre det hele meget nemmere hvis alle bare overholdt standarderne for web-udvikling.

Jeg vil dog godt pointere at al denne snak om at Java er dårlig KUN er ifm. browsere og applets (ligesom NemID), men at Java på desktops (fx. Microsoft Windows 8, Linux, Mac OS X osv.) er rigtig godt da det muliggør cross-platform udvikling for tungere applikationer end mobile "apps".

Derudover så lyder det lidt til at nogle folk blander JavaScript og Java sammen... det er to vidt forskellige sprog som dog på nogle punkter minder om hinanden.

  • 4
  • 0
Thue Kristensen

Jeg kan sige at det ikke er specielt svært at decompile nemid's javakode, og deobfuscate den - MEN, det giver bare ikke en ret meget indsigt i hvad der sker, da den blot kalder videre til de binære "gif-filer", som ikke er Java kode.

Så dekompiler gif-filerne. Som nogle DIKU-fyre allerede har gjort, så det er fuldt ud muligt.

Der er ikke nogen grundlæggende forskel på at læse obfuskeret javascript og på at dekompilere og læse den nuværende applet.

  • 2
  • 0
Michael Nielsen

Problemet at skiftet til denne teknologi, ændre ikke på de underliggende sikkerhedsproblemer, bla MITM angreb m.v.

De Eneste to ting dette giver, er at man kan bruge det på enheder der ikke har java

Samt muligheden for at gennemse din computer bliver mindre - men ikke umuligt, da med HTML5 kan javascript gøre meget mere end før, inklusiv at få adgang til local storage.. Forhåbenligt virker sandboxen, så local storage kun er data der kan gemmes i browseren - men det vil tiden vise.

Men hovedet problemet med at NemID er enormt usikker er ikke ændred, og jeg tilråder stor forsigtighed.

  • 3
  • 2
Jonathan Jørgensen

Hvis vi så også kunne få en anden form for two factor authentication, så ville det jo være skønt. Nøglekort og nøglevisere det er simpelthen for træls.

Send mig en SMS med en kode eller lad mig installere en app på min telefon. Google og Facebook kan finde ud af det. Det kan da umuligt betyde at sikkerheden bliver SÅ meget værre - den største trussel er vel folks nuværende computer, fyldt med malware og andre godter.

Som en bonus kunne man også kigge på udbredelsen til det private erhvervsliv. F.eks. ved at sætte nogle fornuftige priser eller helt fjerne dem. Lad os sige at de første 1 mio. logins per måned per virksomhed er gratis. Det ligner monopol på sikker identitet og det er ikke til danskernes fordel.

  • 0
  • 0
Michael Nielsen

Denne løsning er den største sikkerheds løsning der kan fortages, hvis det designes rigtig.. Fordel - stiller ingen krav til din computer, eller hvor mange viruser du har (hvis det er implementeret rigtig), kan ikke nemt hackes (i forhold til NemID - som er triviel at hacke).. og Chiptan virker med standard browsere, og tablets, da der ikke er nogen krav om at kunne køre andet end standard html/javascript.

Danmark er ikke en forgangsland, men et baggangsland, den løsning som NemID er baseret på, var jeg med til at smide ud i 1994 i Australien, pga det ikke løste nogen af de standard problemer (ud over replay).

  • 2
  • 2
Niklas Pedersen

Nu er det efterhånden en gammel nyhed, men jeg håber da de vælger noget SSO, der kræver man er på https://login.danid.eu eller deslige. Et af de store problemer med NemID idag er at brugeren ikke har nogen mulighed for at se om det er banken, staten, russeren der vil have dine penge, der beder om en kode lige nu.

  • 0
  • 0
Joseph Kiniry

I am surprised that you say it isn't particularly hard to deobfuscate the NemID applet. We have found that they did not use any mainstream public or commercial obfuscater, so deep automated obfuscation is not trivial. Did you really do the obfuscation, or just have a peek at the decompiled binaries to speculate about such?

Best,
Joe Kiniry

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