NemID uden Java nærmer sig

29. april 2013 kl. 15:1118
NemID uden Java nærmer sig
Illustration: Privatfoto.
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.
person
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.
person

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.

Artiklen fortsætter efter annoncen

»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.

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.

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.

Emner
18 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Køb abonnementFå prøveabonnement

Jobs

Dine job
Vis alle

Fortsæt din læsning

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
13
Anders Jenbo
30. april 2013 kl. 11:27

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?

  • more_vert
    • insert_linkKopier link
10
Anders Jenbo
30. april 2013 kl. 02:34

Sæt login siden op med HSTS (altid HTTPS) og sørg for den kommer med i de indbyggede browser lister. Det burde løse problemet med sikkerhed langt hed ad vejen.

  • more_vert
    • insert_linkKopier link
6
Nils Bøjden
29. april 2013 kl. 18:41

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.

  • more_vert
    • insert_linkKopier link
3
Pascal d'Hermilly
29. april 2013 kl. 17:00

Det er enormt vigtigt at vide hvor man må taste sin nemid kode. Derfor skal det altid være på samme side man logger ind - f.eks. nemid.nu. Det gøres via en redirect og at serverne aftaler at nogen skal logge ind. Se mere detaljeret: http://dhermilly.dk/pascal/nemid/#title2

  • more_vert
    • insert_linkKopier link
11
Jonas Finnemann Jensen
30. april 2013 kl. 10:05

Downvotes!?

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.

Man kunne evt. skrive på NemID kortet at koderne kun må bruges på en given HTTPS addresse. Jeg ser ikke andre løsninger, kryptering i JS giver da ikke mening.

  • more_vert
    • insert_linkKopier link
12
Jesper Lund
30. april 2013 kl. 11:00

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 :-)

  • more_vert
    • insert_linkKopier link
15
Hans Schou
30. april 2013 kl. 21:37

Nemlig. Måske dette skulle være en anledning til at minde om denne meget foruroligende talk fra DEFCON 17:</p>
<p><a href="http://www.youtube.com/watch?v=ibF36Yyeehw">http://www.youtube.com/watc…;

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 tilwww.danskebank.dk\0.skurk.dk

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

  • more_vert
    • insert_linkKopier link
16
Peter Mogensen
30. april 2013 kl. 23:02

Det undrer mig lidt at det intet sted blev nævnt (eller tænkt over hos SSL-implementører) at \0 ikke er gyldig i et FQDN hvis man udsteder et x509 cert til host-navne. Det burde da være det mindste check uanset alle de andre bugs.

  • more_vert
    • insert_linkKopier link
1
Jens Christian Hillerup
29. april 2013 kl. 16:19

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.

  • more_vert
    • insert_linkKopier link
17
Hans Schou
30. april 2013 kl. 23:52

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.

  • more_vert
    • insert_linkKopier link
18
Frithiof Andreas Jensen
1. maj 2013 kl. 09:50

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".

  • more_vert
    • insert_linkKopier link
2
Peter Reinhold
29. april 2013 kl. 16:59

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.

  • more_vert
    • insert_linkKopier link
4
Jens Christian Hillerup
29. april 2013 kl. 17:13

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.

  • more_vert
    • insert_linkKopier link
9
Bjarke Walling
29. april 2013 kl. 21:01
  • more_vert
    • insert_linkKopier link
5
Jeppe Boelsmand
29. april 2013 kl. 18:05

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?

  • more_vert
    • insert_linkKopier link