NemID uden Java nærmer sig

En Java-fri løsning for NemID er nu tæt på at blive godkendt. Tirsdag skal Digitaliseringsstyrelsen vurdere et tilbud på NemID baseret på Javascript.

Først var det galt nok, at NemID ikke kunne bruges på mobile platforme som Android og iOS. Men på det seneste er kravet om Java på computeren blevet en sikkerhedsrisiko i sig selv.

Derfor har Digitaliseringsstyrelsen længe kigget på muligheden for at få en NemID-løsning, der kunne køre på Javascript, som findes i enhver browser på markedet. Og nu er der snart hul igennem, skriver MX.dk.

Styrelsen har opstillet kravene til en NemID-løsning med Javascript og venter nu på at få et tilbud fra leverandøren, før den endelige beslutning bliver taget.

»Vi forventer at have det endelige tilbud på udvikling af en ny løsning klar i morgen, og derefter skal vi tage stilling til, om aftalen kan indgås. Det tegner positivt,« siger kontorchef i Digitaliseringstyrelsen, Cecile Christensen, til MX.dk.

Læs også: NemID med Java på vej ud? Styrelse tester løsning i Javascript

Da Digitaliseringsstyrelsen begyndte arbejdet med et alternativ til den nuværende NemID-Java-applet, blev der sat otte millioner kroner af til opgaven. Men en analyse af de forskellige muligheder, og et prisoverslag for dem, afslørede, at det ikke var nok. Prisen ville ende på mellem 15 og 30 millioner kroner. Derfor kunne styrelsen ikke leve op til den først udmeldte deadline om NemID på mobile enheder inden udgangen af 2012.

Læs også: 8 millioner kroner til NemID på mobilen var ikke nok

Læs også: Her er statens bedste bud på mobil NemID-løsning

Senere har Digitaliseringsstyrelsen nævnt udgangen af 2013 eller første kvartal af 2014 som nye, mulige deadlines. Det afhænger meget af, om opgaven med den Javascript-baserede NemID kan udformes som en tillægskontrakt til den nuværende leverandør Nets DanID, eller om opgaven skal i et udbud, som typisk tager mindst et halvt år ekstra.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (18)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Jens Christian Hillerup

Krypto implementeret i Javascript er ikke en god ide endnu. Problemet her er at man bruger noget der er "svagt" sikkert til at implementere noget, der ellers skulle være "stærkt" sikkert.

Sagen er, at klienten er tvunget til at stole på den server, som serverer scriptet, og det kan man ikke rigtigt med gældende web-teknologier. For en angriber med adgang til et rogue certifikat for NemID vil man kunne anvende et man-in-the-middle-angreb til at serve ondsindet JavaScript, som brugeren uden at ane uråd kommer til at køre.

Med det ondsindede JS vil angriberen kunne "modellere virkeligheden" hvad angår NemID-implementeringen, og fx lave endnu et man-in-the-middle-angreb hvor brugeren tror den autenticerer adgang til borger.dk, men hvor det faktisk er angriberen, der forsøger at komme ind på vedkommendes netbank.

NemIDs afhængighed af Java er ikke dets største problem; det er broken på arkitekturniveau.

  • 13
  • 4
#2 Peter Reinhold

Det adskiller sig jo ikke fra hvordan virkeligheden ser ud idag, der har været massevis af impersonation angreb på den indeværende NemID løsning, så alene det ar man kan få taget Java ud af det, så alle Danmarks borgere ikke er åbne for angreb fra den front, vil da være et sikkerhedsmæssigt kæmpe skridt i den rigtige retning.

  • 3
  • 0
#4 Jens Christian Hillerup

Ja, men den slags angreb kommer jo an på en kompromitteret klient og/eller server? "Mit" angreb kræver bare at angriberen kontrollerer en router mellem brugeren og NemID. (Og det kan man ARP spoofe sig til at være.)

Anyway, der er også andre problemer ved at køre sit krypto i JavaScript. Fx bliver XSS-huller meget mere effektive fordi nøglemateriale uafværgeligt ligger i en variabel et sted. Private members er muligt at lave, men det er overloading af vilkårlige JavaScript-funktioner også, så jeg spår det bliver svært at holde XSS-baserede angreb fra døren.

Særligt grælt bliver det hvis disse XSS-exploits er residente i en database (stored XSS); så vil man-in-the-middle-angreb kunne ske på stor skala.

  • 0
  • 4
#5 Jeppe Boelsmand

Hvis det er nok at kompromitere infrastruktur imellem parterne er det du har lavet ikke kryptering. Din plan er at forge et nemid ssl-certifikat og få brugeren til at acceptere det. Du vil så servere en loginside for ham som han skal bruge så du kan svare den challenge hans netbank sætter op for dig(du gætter bare hvilken bank han). Det er en piv-fin ide og den er 100% teknologiuafhængig. Du kan gøre det samme når de laver det i silverlight om 3 uger :P Hvad persistent cross site scripting angreb har med det at gøre forstår jeg slet ikke. Vil du poste user generated content et sted og håbe at det dukker op på samme side som et nemidlogin, f.eks. på borger.dk?

  • 5
  • 0
#6 Nils Bøjden

Man må da så håbe at:

  1. En kontrakt om levering af en JS baseret NemID gives til en konkurrent til Nets
  2. At bankerne tvinges til at acceptere leverance fra en konkurrent til deres egen leverandør.

Hvis ikke 2 opfyldes kommer en JS platorm til at lide samme død som den digitale signatur.

  • 3
  • 1
#9 Bjarke Walling
  • 1
  • 0
#12 Jesper Lund

Ja, det kan også undre mig. Hvis nogen ved hvorfor redirects ikke er løsningen synes jeg det kunne være meget interessant at vide.

Redirect er bedre end iframe, men er det godt nok? Det vil ikke virke mod en passende kombination af DNS spoofing og falske SSL certfikater.

Det er ikke engang sikkert at en angriber behøver et falsk SSL cert. Måske kan du lokke tilpas mange til at ignorere en SSL advarsel. Der er løbende historier om offentlige websites hvor SSL certifikatet er udløbet, fordi nogle har glemt at forny det, og beskeden til borgerne plejer at være at "du skal bare klikke videre...".

Bottom line: jeg mener ikke at sikkerheden kan baseres på SSL alene. Vi bør snarere kigge på token løsninger ala NemID på hardware, i hvert fald til de mest kritiske anvendelser af OCES signaturen. Til mindre kritiske anvendelser fra tablet/smartphone (hvor USB token løsninger er lidt tricky) kan man bruge OTP koder.

Problemet med Java er først og fremmest at borgerne er nødt til at have Java installeret på deres computer, og det er i sig selv en sikkerhedsrisiko. Der er mig bekendt ingen grund til at tro at DanID's Java applet i sig selv skulle udgøre en sikkehedsrisiko, i hvert fald ikke større end andre webbrowser-only teknologier.

Jeg har selvfølgelig ikke givet Pascal downvotes :-)

  • 2
  • 0
#13 Anders Jenbo

Men beskytter den nuværrende løsning på nogen måde kunden imod DNS-spoofing? Hvis ikke hvorfor skulle det så være en stop klods for at den kan blive udskiftet med noget andet der heller ikke gør det?

  • 4
  • 0
#15 Hans Schou

Nemlig. Måske dette skulle være en anledning til at minde om denne meget foruroligende talk fra DEFCON 17:

http://www.youtube.com/watch?v=ibF36Yyeehw

Indrømmet, jeg har ikke set den før, men jeg bliver igen imponeret over hvor fantasifulde sådan nogle karle er. Det er flot!

Måske jeg skulle købe et certifikat til www.danskebank.dk\0.skurk.dk

Og så tilbyde gratis Wifi-net et sted hvor der er mange mennesker. Flink er jeg jo.

  • 1
  • 0
#17 Hans Schou

Sagen er, at klienten er tvunget til at stole på den server, som serverer scriptet, og det kan man ikke rigtigt med gældende web-teknologier.

Hvis det er rigtigt, så er der ingen web-sider jeg kan indtaste mine Dnakort oplysninger på.

Det oprindelige emne handler om NemID + Java. Og her er SSL også en væsentlig del.

Der er flere måder man kan implementere et login på:

  1. Banken præsentere sin egen bank.dk og redirector til danid.dk/nemid.jar og retur

  2. Banken iframer til danid.dk/nemid.jar

  3. Banken modtager request på /danid/nemid.jar og den fil hentes så lokalt, eller måske fra danid.dk via en proxy hos banken.

I min optik er det kun pkt 3 der reelt er brugbart.

Pkt 2 har jeg set anvendt hos Nordea, og det gav det problem at malware kunne rette i /etc/hosts (eller C:\windows/system/hosts.txt) filen, og DanID advarerde ikke om at der var noget galt, når jar-filen blev kørt. Altså www.nordea.dk var rigtig nok, men de linkede videre til jar-filen på danid.dk og den var spoofed i /etc/hosts (sikke en fantasi, jeg tænker ikke selv i de baner).

Så hvis ikke jeg kan skrive https://jyskenetbank.dk/ i min browser, og min browser bliver på den side banken nu har oplyst, så kan jeg ikke stole på noget. Hverken Java eller Ecmascript, for det kommer ud på et.

Jeg må nok indrømme ud fra at have set ovenstående DEFCON-video, er jeg egentlig ikke kan være sikker på ret meget. Der er huller der er kendt i dag, men sikkert endnu flere der ikke er det.

Java er ikke løsningen. Java er det problem vi pt står med, og Ecmascript (javascript) er en bedre løsning end java, selv om den muligvis er ringe.

  • 0
  • 0
#18 Frithiof Andreas Jensen

Svenskerne bruger, sandsynligvis belært af erfaringen*, en hardware enhed med et chipkort. Der er ingen central login, man logger direkte ind hos den man nu skal betjenes af.

Hvis man får et ID-kort også (udstedes af Skatteverket mod 700 SEK og personligt fremmøde i Malmö med pas) kan man få et ekstra certifikat tilføjet til sit chipkort som derefter også kan anvendes hos det offentlige. Ellers er offentlig betjening "analog" per post.

Det burde være rimeligt tilgængeligt at anvende den "Svenske model" i Danmark, forudsat politikerne opgiver lidt af deres drøm om at kunne overvåge og kontrollere alt.

*) Der er overraskende meget svindel og korruption i Sverige. Ingen her er derfor sindssyge nok til at lave en centraliseret løsning fordi det kun kræver at een korrupt aktør får købt sig adgang een gang før det er "Game Over".

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