Java ud af NemID

Alle med nogle års erfaring ved at der kommer et punkt i et programs liv, hvor forudsætningerne hvorunder det blev skrevet har forandret sig så meget at der ingen vej er uden om /dev/null.

Java går og balancerer på kanten af klinten.

Det vi løst kalder Java er faktisk tre helt forskellige ting:

  1. Et binært instruktionssæt, "The Java Bytecode"

  2. Et programmeringssprog, "The Java Language"

  3. Et bjerg af klassebiblioteker til programmeringssproget "The Java Runtime"

Den oprindelige vision var en sikker arkitekturneutral exekvering af programmer: Bytekoden skulle gøre binære hackerier uskadelig, groft sagt fordi koden er objekt-orienteret og ikke indeholder pointer-funktioner. Sproget var nødvendigt, for manglen på pointeroperationer gør at f.eks C++'s new/delete operatorer får en helt anden semantik hvis det kompileres til java-bytecode. Bibliotekerne skulle interface til resten af computeren og sikre at der ikke skete noget fy-fy, uanset hvad bytecoden måtte prøve på.

Rent juridisk er sproget frit tilgængeligt, et programmeringssprog kan ikke patenteres eller copyrightbeskyttes.

Bytekoden er i realiteten også fri, men der er nogle patenter om fortolkningen af den man skal navigere uden om. Google har vist i retten at det ikke er noget problem.

Bytekoden og sproget lever derfor i bedste velgående, ikke mindst netop i Googles Android men også med Java compilere der genererer "native" kode til computeren.

Punkt 3, runtimen, er hvor Sun, nu Oracle, skulle have haft scoret kassen.

Men runtimen er også hvor alle sikkerhedsproblemerne er koncentreret og det er også det punkt hvor Suns "Write once, run anywhere" vision var absolut mest sårbar, hvilket Microsoft udnyttede, men fik smæk for i retten.

Men længe inden det punkt, havde JavaScript, der absolut intet har at gøre med Java, overtaget det primære markedssegment: Websider og gjort en ende på Suns drøm om at blive Kalif i stedet for Kaliffen.

Som situationen er idag, er det meget svært at forestille sig at Oracle tjener penge på Java Runtime, ihvertfald slet ikke penge nok til at holde den meget omfattende og meget komplexe kodebase i live. At de kan være både halve og hele år om at reagere og fixe forholdsvist kritiske sikkerhedsfejl bærer vidne derom.

Om Oracle rent faktisk smider håndklædet i ringen, eller om de har indgået kontrakter der lænker dem til møllestenen må tiden vise, men at java til applikationer i browsere en død som en sild er klart for enhver og har været det i årevis for de mere observante i branchen.

Og så kommer vi til den obligatoriske danske IT skandale:

Allerede da det først blev annonceret at NemID skulle baseres på en Java-Applet lød der et ramaskrig, ikke mindst her på v2, men i sin sædvanlige magtfuldkommenhed og arrogance blev det afvist med "vi ved bedre".

Nu er vi i den underholdende situation at vi fredag kan høre "Bare rolig, det er ikke noget problem" og Mandag "OPDATER MED DET SAMME!!!!" I bedste Irakiske Informationsminister-stil.

Der har aldrig været fremlagt skyggen af evidens for at NemID Java-applet'en giver noget netto positivt bidrag til sikkerheden af den samlede løsning og iflg, insiders er der intet positivt bidrag: Det gør bare det hele mere kompliceret og vakkelvornt.

NemID blev søsat for at forbedre IT-sikkerheden i Danmark.

Den nemmeste og absolut billigste forbedring af IT-sikkerheden i Danmark lige nu, er at droppe NemID java-appletten og bruge en simpel HTML formular over en HTTPS forbindelse i stedet.

phk

Kommentarer (76)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Martin Kofoed

De hører ikke til dér. Uanset om det hedder Flash, Java, Silverlight eller noget fjerde.

At vælge at bygge nogle indtastningsfelter som en Java Applet, er lige så dumt som at lave sin menustruktur som flash-objekter. Det gør man bare ikke. Punktum.

NemID må laves om asap. Vi var (måske?) heldige denne gang, angiveligt er ganske få blevet ramt af denne sårbarhed. Men det er med garanti ikke den sidste sårbarhed af denne type i applet sandbox'en. Det har ganske enkelt ikke Oracles bevågenhed på samme måde som udvikling af Java EE. Og med god grund: ingen bruger applets mere. Well ...

  • 33
  • 1
#2 Ricco Førgaard

Findes der egentlig nogen officiel begrundelse for at vælge Java? Det virker som en form for de-facto standard til systemer, der kræver højere sikkerhed end ellers og bare ikke må fucke op. Jeg har på fornemmelsen, at valget faldt på Java, fordi det tilfældigvis var den teknologi, som spec-skriverne havde kendskab til i tidernes morgen.

  • 23
  • 0
#3 Jens Pedersen

En simpel html form igennem en https forbindelse?

Det lyder langt mere gennemskueligt i forbindelse med en reel sikkerhedsanalyse end mystiske gif-filer, hemmelig kode og den slags. Det kan umuligt være sikkert - sikkerhed opbygges jo netop ved at ingen kan gennemskue hvad der sker, ik'? :)... Modellen bliver i hvert fald svær at sælge til en gennemsnitspolitiker.

Det lyder også som en løsning hvor det kan være langt sværere at indbygge hemmelige smutveje og lignende.

Det vil også være en løsningsmodel som i dén grad kan svække forretningsmodellen for NemID. Tænk hvis sikkerheds-elementet som må være hjørnestenen is systemet bliver baseret på gennemprøvede standard-systemer frem for hjemmestrikkede løsninger. Og endnu værre, måske 100% baseret på en åben model...

Det er langt mere troværdigt med et applet der tager adskillige sekunder om at loade. Det vidner om sikkerhed, mystik og lignende "tillidsvækkende" ting, frem for almindelige forms som kan fremkaldes på få hundrede milisekunder.

PKH, jeg er ked af det, men dit forslag holder ikke i virklighedens verden (og du ved det også godt). Det er simpelthen alt for nemt og logisk ;)

  • 38
  • 4
#4 Flemming Sørensen
  • 27
  • 2
#5 Lars Bengtsson

Måske er den afgørende årsag til at man har valgt Java at man ville have adgang til filsystemet. Det har været fremme i debatten her på Version2 at NemID laver en identifikation af computeren og i den forbindelse har brug for at læse filer (lave system kald) der indeholder info om hardware og OS.

Denne mulighed har man så vidt jeg ved ikke med en ren browser-baseret løsning (HTML / Javascript). Hvis man kræver filadgang så må man køre et eller andet udenfor browseren og der har man nok fundet at Java var den billigste og sikreste løsning. For hvad er alternativerne?

  1. Et nyudviklet OS specifikt NemID program, med et nyudviklet browser plugin. Dyrt hvis det skal være sikkert.
  2. Flash, har historisk haft flere sikkerhedshuller end Java.
  3. ActiveX, do, samt er eksklusivt til Windows
  4. Silverlight, do, samt er døende.

Så kan man så diskutere om det er nyttigt for brugerne at NemID har adgang til vores filsystem. Måske får vi nemmere ved at dokumentere et evt. misbrug af vores bankkonto. På den anden side er ulemperne formentlig større.

Men vis politikerne har vurderet at adgang til filsystemet, som en indirekte konsekvens af et ønske om at kunne identifcere hvilken computer en given transaktion kommer fra, var der så nogen bedre alternativer?

  • 15
  • 0
#7 Peter Holm Jensen

så kan alle se hvudden det virker, og skulle man endelig have lavet en fejl så er der nok nogen (f.eks. en hel del her på blokken) der hjælper med at finde den. Hvis man nu alligevel mener at kildekoden skal være hemmelig af sikkerhedsårsager, så er man selv ude om det.

  • 5
  • 0
#9 Torben Mogensen Blogger

Virtuelle maskiner i browsere er ikke nogen grundlæggende dårlig ide. Det er først, når man giver dem tilladelse til at tilgå lokale filer (udover egenoprettede temporære filer), osv., at risikoen kommer.

Så en simpel abstrakt maskine, der kan bruges til at forbedre brugergrænsefladen i forhold til HTML, men som ikke har flere rettigheder end ren HTML har, vil være en god ide. Det var i starten også det, Java og Javascript var til tiltænkt. Men de er begge blevet udvidet med langt flere rettigheder og store eksterne (dvs. ikke afviklet i den abstrakte maskine og derfor ikke underlagt dens begrænsninger) biblioteker. Det har stort set altid været fordi, man så kunne bruge sprogene til en ny type opgaver, så det var fristende for dem, der gerne så sprogene udbredt mere. Men det er en fristelse, man skal modstå.

Af samme grund synes jeg, at HTML5 er på et vildspor: Man har valgt det alt for usikre Javascript til at tilføre "aktive elementer" på websiderne. I stedet burde man have defineret en langt simplere (og mere præcist specificeret) abstrakt maskine til formålet.

  • 16
  • 3
#10 Morten Krøyer

Det vil jo desværre ikke hjælpe, hvis selve nem-id appletten bliver gennemgået af it-sikkerheds-eksperter. Problemet er jo, i hvert fald i dette tilfælde, at brugeren har java installeret, som vil kompromitere brugerens PC, inden nem-id appletten kører. Uanset hvor sikker en applet bliver, hjælper det jo ikke noget, hvis brugeren har en key-logger installeret... eller hans session bliver hijacket pga. anden malware.

  • 4
  • 0
#12 Henrik Mikael Kristensen

Nå, jeg er ikke den eneste der har opdaget det...

Generelt er appletten lidt af en usability fælde, når den har sin egen måde at svare på, selvstændigt fra browseren, og er endnu en grund til ikke at bruge Java.

Feedback er absolut minimalt, og man aner ikke om man er igang med at logge ind, om forbindelsen er tabt eller hvad der ellers sker bag om ryggen på browseren, når den står stille midt i det hele, og det kan altså forveksles ret nemt med et MITM angreb, hvis serverforbindelsen er "dårlig".

  • 9
  • 0
#13 Carsten Jørgensen

Java bruges til, via recursive SRP-protokoller baseret på dit password og din OTP, at etablerer forbindelsen ind i DanID's HSM så privatnøgle operationerne kan laves der. Løsningen blev gennemgået af over 100 it-sikkerhedsfolk i Danmark og udlandet, hvis den skal udskiftes med en "HTML formular over HTTPS" vil jeg ikke længere have min nøgle liggende hos DanID. Men det vil da være hurtigt for dem at lave det.

Det har altid interesseret mig at mange ser ud til at tro, at bankerne ikke ved noget om it-sikkerhed, selvom det er der pengene er. Jeg ved intet om det, men jeg vil tro (og håber), at DanID allerede arbejder en ny løsning uden Java.

  • 8
  • 5
#15 Johnnie Hougaard Nielsen

Sådan set er problemet ikke virtuelle maskiner som sådan, men plugin-arkitekturen. Hvad som helst der laves som et browser plugin bliver sikkerhedskritisk, fordi det giver alt for nem adgang til de systemresourcer som en sådan lokalt installeret programpakke kan manipuleres til at tage fat i. Her er applets blot en af mange, men den store udbredelse, og den træge sikkerhedshåndtering fra Oracle, gør den jo så særligt interessant for malware-pushere.

Java er såmænd udmærket, men skal ligesom så meget andet ikke udstilles i en browser. Jeg ville være mere tryg hvis der blev lavet en ekstra sandbox, som den Google kører Flash i, for at gøre Chrome tåleligt sikker her.

  • 1
  • 0
#16 Jakob Ottesen

Det har altid interesseret mig at mange ser ud til at tro, at bankerne ikke ved noget om it-sikkerhed, selvom det er der pengene er.

Jeg tror ikke det er et spørgsmål om viden men om hvilke incitamenter bankerne har til at skabe en god løsning.

Mht. netbank-delen af Nemid så er det bankerne der bærer risikoen ved misbrug af kundens konti, og de har således et incitament til at bruge penge på sikkherhed. Og hvis de vælger ikke at gøre det, er det deres problem.

Men mht. OCES-delen så skal jeg jo ifm. oprettelse af denne give et samtykke der, som jeg har forstået det, gør det til mit problem hvis servicen er nede eller bliver kompromiteret. Jeg bærer risikoen, så Danid kan groft sagt være ligeglade.

hvis den skal udskiftes med en "HTML formular over HTTPS" vil jeg ikke længere have min nøgle liggende hos DanID."

Hvorfor ikke? (Du får nok iøvrigt ikke noget valg mht. hvor din nøgle skal opbevares).

  • 4
  • 7
#17 Poul-Henning Kamp Blogger

Det har altid interesseret mig at mange ser ud til at tro, at bankerne ikke ved noget om it-sikkerhed, selvom det er der pengene er.

Du tror til gengæld at bankerne er interesseret i at beskytte IT, det er de ikke, det er pengene de beskytter.

Bankers IT-sikkerhed er styret 100% efter hvem ansvaret tilfalder: Hvis det ikke kan koste bankerne penge, er det ikke vigtigt.

Derfor fjernede de billedet fra dankortet: Byretten dømte i en fuldskægget kundes fordel, det kostede banken penge, så billedet "forbedrede ikke sikkerheden" som bankernes spindoktorer udtrykte det.

  • 25
  • 1
#18 Per Lind

Som jeg har påstået fra 1ste dag, så er voice biometrics den bedre løsning for godkendelse af UnemID´s brugere. JAVA er en spand med så mange huller og det har alle beslutningstagerne nu måttet indse og jeg forstår ikke hvem der skal forestå som ansvarlig på dette makværk? Bare følg med her: http://www.linkedin.com/groups?gid=756687&trk=myg_ugrp_ovr

Den arrogance og følgende tab til den danske stat skal vel betales af dem som har ført alle bag lyset! There is something rotten in the state of Denmark! Og efter hundrede af år er det sgu stadig rigtigt! FØJ FOR DEN LEDE!

  • 2
  • 19
#19 Christian Panton

Java bruges til, via recursive SRP-protokoller baseret på dit password og din OTP, at etablerer forbindelsen ind i DanID's HSM så privatnøgle operationerne kan laves der. Løsningen blev gennemgået af over 100 it-sikkerhedsfolk i Danmark og udlandet, hvis den skal udskiftes med en "HTML formular over HTTPS" vil jeg ikke længere have min nøgle liggende hos DanID. Men det vil da være hurtigt for dem at lave det.

Jeg kan virkelig ikke se hvorfor det bliver mere sikkert af at bruge Java til det? Java i form af en applet er client-side kode, således hvis nogen med tilpas meget energi gad at deobfuscate deres applet, ville kunne laves tilsvarende adgang via et vilkårligt programmeringssprog.

Det eneste jeg kan regne ud at Java er godt for er 1) køre kode på min maskine (i form at GIF filer) - og 2) at lave en socket til en anden server end der hvor appletten blev kaldt fra (Same-origin policy gælder for unsigned applets, og der er nok her den virkelige årsag til at holde fast i Java ligger begravet).

  • 10
  • 0
#20 Jesper Lund

Løsningen blev gennemgået af over 100 it-sikkerhedsfolk i Danmark og udlandet, hvis den skal udskiftes med en "HTML formular over HTTPS" vil jeg ikke længere have min nøgle liggende hos DanID.

Jeg vil antage at "netbank NemID" kunne køre uden Java fordi der ikke er nogen persistent nøgle i DanID's HSM involveret her. Jyske Banks OTP løsning kørte også uden Java.

Hvis Java kravet reelt skyldes at borgernes private nøgle (til OCES NemID) er opbevaret i DanID's HSM, og at dette ikke kan administreres på sikker vis uden Java, må den logiske konsekvens være at man dropper ideen om centrale nøgler. DanID har en teknisk løsning til dette (NemID på hardware).

Måske kunne man overveje to udgaver af NemID til offentlig service. 1) OCES NemID, den fulde udgave hvor man har en privat nøgle på smartcard, og hvor borgeren kan lave en reel digital signatur. 2) NemID Light hvor borgeren kan authentificere sig over for en central server med to-faktor sikkerhed (password og OTP) på samme niveau som ved netbank, men hvor man ikke kan underskrive dokumenter med en digital signatur.

Jeg vil gætte på at en stor del af det offentlige selvbejeningsunivers reelt falder ind under punkt 2, men korriger mig hvis jeg tager fejl.

  • 16
  • 0
#21 Carsten Jørgensen

Du tror til gengæld at bankerne

Tak for at fortælle mig hvad jeg tror. Jeg tror også DanID hurtigt ville kunne lave en løsning til bankernes korttidscertifikater, men at det er jo beskyttelsen af privatnøglerne der er kritisk.

Voice biometrics den bedre løsning for godkendelse

Stumme brugere f.eks? Løsningen skal dække hele den danske befolkning.

kunne laves tilsvarende adgang via et vilkårligt programmeringssprog.

Det er ikke et spørgsmål om at deobfuscate en applet men om at beskytte vores privatenøgler. Der ligger meget arbejde i at lave en sikker løsning.

Det eneste jeg kan regne ud at Java er godt for er

Jeg vil da gerne gentage, at Java apletten bruges til at etablerer den krypterede forbindelse fra brugerens maskine ind i HSM-modulet hvor nøglen, der skal beskyttes, ligger.

-> Jesper Lund: Haha, åbenbart den eneste der har undersøgt hvad DanID er...Jeg tror ikke det gælder hvis DanID skal diskuteres på kvalificeret grundlag ;-)

To kommentarer - Jyske Banks gamle løsning brugte gengangspasswords men ville ikke beskytte imod et eneste af de nyere angreb. Løsningen ville helt sikkert ikke være nok til DanID. De to løsninger kan sagtens laves hvis man vil have det, der er ikke så længe til næste udbud. Men under det gældende udbud vil det selvfølgelig være imod loven.

  • 5
  • 9
#22 Sune Foldager

Bare se på googles V8. Her har man brugt en VM til at give javascript et løft. Det er det samme de vil med Dart.

Alle browsere bruger en VM til at afvikle Javascript. Det er det vel nærmest per definition, da der vist ikke findes en Javascript-maskine. Jeg tror også alle nyere browsere benytter JIT-oversættelse til afviklingen. I hvert fald gør udover Chrome, også Safari og Firefox og sikkert også IE.

  • 1
  • 0
#23 Ole Laursen

Løsningen blev gennemgået af over 100 it-sikkerhedsfolk i Danmark og udlandet

Har du en kilde på det? Mærkeligt at de 100 it-sikkerhedsfolk ikke så det her komme, når nu tilfældige v2-læsere kunne se det.

Det har altid interesseret mig at mange ser ud til at tro, at bankerne ikke ved noget om it-sikkerhed, selvom det er der pengene er.

Det her minder mig om en konversation jeg havde med min bank for nogle år siden, en ren internetbank. Jeg var irriteret over at de leverede totalt overflødige kontoudskrifter med nogle måneders mellemrum i min e-boks. Svaret var at der automatisk blev sendt en kontoudskrift hvis der var en lidt mistænkelig post. Der stod ikke en advarsel eller lignende på kontoudskriften. Jeg har aldrig hørt noget lignende.

Personligt er jeg ikke i tvivl om at banker generelt tænker på it-sikkerhed, de er bare hæmmet af deres leverandører. Som absolut burde have holdt sig til mainframe-platformene i stedet for at forsøge sig med web.

Hvor mange tror du ville benytte DanIDs løsning hvis de ikke havde monopol?

Jeg ved intet om det, men jeg vil tro (og håber), at DanID allerede arbejder en ny løsning uden Java.

I stedet for at gætte kunne du besøge NemID.nu og læse om en arbejdsgruppes konklusion om at en løsning uden Java til mobile enheder er mindre sikker. Det ser dog ud til at der alligevel kommer en, grundet det folkelige pres.

  • 9
  • 0
#24 Jesper Lund

De to løsninger kan sagtens laves hvis man vil have det, der er ikke så længe til næste udbud. Men under det gældende udbud vil det selvfølgelig være imod loven.

Er man ikke allerede i gang med denne "segmentering" på enkelte områder som Offentlig Digital Post? Så vidt jeg kan se på e-boks.dk (der administrerer Offentlig Digital Post) er der lavet en mobil/tablet løsning. Den bruger ikke Java, og ud fra beskrivelsen vil jeg antage at den ikke får fat i den private nøgle i HSM'et men authentificerer borgeren over for e-Boks, og herunder vel (?) Offentlig Digital Post, på anden måde end ved en formel privatnøgle operation.

Jeg bruger e-Boks så lidt som muligt, og er ikke tilmeldt Offentlig Digital Post, så der er et par gætterier her.

  • 2
  • 0
#25 Sune Foldager

JAVA er en spand med så mange huller

Jeg synes man bør skelne mellem PHK's punkt 1-3, samt den fjerde ting som Java også består af: runtimen (jeg vil ikke kalde punkt 3 for en runtime; en runtime afvilker koden og styrer memory management, etc. etc.).

Der er vel ikke noget sikkerhedsmæssigt galt med 1-3, så det er nok 4 der er problemet. Specielt, åbenbart, sandboxing-systemet som kun benyttes når Java afvikles i browsere.

Jeg kan virkelig ikke se hvorfor det bliver mere sikkert af at bruge Java til det? Java i form af en applet er client-side kode, således hvis nogen med tilpas meget energi gad at deobfuscate deres applet, ville kunne laves tilsvarende adgang via et vilkårligt programmeringssprog.

Ja, men det sprog måtte så være Javascript, da der jo ikke er andre sprog udbredt på browsere.

  • 1
  • 0
#26 Morten V. Christiansen

Om man virkelig kan opnå den samme sikkerhed med en kombination af https og javascript/html kommer nok en del an på, hvilke sikkerhedshensyn og standarder, som java-apletten er designet til at opfylde. Jeg kender ikke kravene. På den anden side har jeg for længe siden lavet login-kode til sikre systemer (Orange book), og det er typisk ikke så helt let.

Et meget almindeligt krav er f.eks. at passwordet ikke må lægges i tastaturbufferen, men skal læses direkte fra tastaturet. Det gør det meget sværere for ondsindet software at opsnappe passwordet. Og det umuliggør selvsagt cut-and-paste af passwordet, samt at det kan auto-lagres i f.eks. en browser.

Et andet klassisk krav er, at koden der bruges i login-modulet ikke må være delt med andre programmer. Ingen brug af delte biblioteker, kun statisk linkning.

En tredje ting jeg finder plausibel, er at man bruger en "hjemmerullet" krypteringsprotokol, f.eks. en Diffe-Hellman udveksling med en lille variation, for at gøre det sværere at bryde krypteringen med standard-angreb. Jeg kender en større dansk virksomhed, der rutinemæssigt bryder al SSL kommunikation fra deres netværk ved et man-in-the middle angreb fra deres maskinafdeling. Det handler om at overvåge medarbejdernes adfærd på nettet, og opfattes som en sikkerheds feature - man vil vide hvad medarbejderne laver på firmaets maskiner. En "hjemmebrygget" kryptering kræver i det mindste et stykke specialværktøj at åbne. Den vil ikke knækkes automatisk, med et standardiseret angreb på SSL.

Disse ting vil enten være svære eller umulige at lave i javascript. Og måske er de heller ikke nødvendige. Men det virker lidt hurtigt at tale om at "opgaven kan lige så godt løses i X", når man ikke ved, eller diskuterer i detaljer, præcist hvad opgaven går ud på.

  • 5
  • 0
#27 Pelle Söderling

Et meget almindeligt krav er f.eks. at passwordet ikke må lægges i tastaturbufferen, men skal læses direkte fra tastaturet. Det gør det meget sværere for ondsindet software at opsnappe passwordet. Og det umuliggør selvsagt cut-and-paste af passwordet, samt at det kan auto-lagres i f.eks. en browser.

Tvivler meget på Java applets har adgang til hardwaren på det niveau, så det virker ikke sandsynligt at NemID gør brug af dette - desuden formoder jeg at de fleste keyloggers hooker sig ind så de alligevel opsnapper alle tastetryk - jeg tvivler på der er meget sikkerhed vundet ved dette.

En tredje ting jeg finder plausibel, er at man bruger en "hjemmerullet" krypteringsprotokol, f.eks. en Diffe-Hellman udveksling med en lille variation, for at gøre det sværere at bryde krypteringen med standard-angreb.

Det finder jeg yderst tvivlsomt - det er security-through-obscurity og det er generelt en dårlig ide at fifle med krypteringsprotokoller istedetfor at anvende en gennemtestet algoritme.

eg kender en større dansk virksomhed, der rutinemæssigt bryder al SSL kommunikation fra deres netværk ved et man-in-the middle angreb fra deres maskinafdeling.

Jeg tvivler på det er krypteringsalgoritmen de bryder på denne måde, det er langt mere sandsynligt (specielt da de jo har adgang til medarbejdernes maskiner) at de fifler med SSL-certifikaterne og på den måde ligger sig imellem - en teknik der også er meget brugt i Http Debuggers.

  • 11
  • 0
#28 Jesper Louis Andersen

Java bruges til, via recursive SRP-protokoller baseret på dit password og din OTP, at etablerer forbindelsen ind i DanID's HSM så privatnøgle operationerne kan laves der. Løsningen blev gennemgået af over 100 it-sikkerhedsfolk i Danmark og udlandet, hvis den skal udskiftes med en "HTML formular over HTTPS" vil jeg ikke længere have min nøgle liggende hos DanID. Men det vil da være hurtigt for dem at lave det.

Det skyldes formentlig at de fleste opfatter NemID som en SSO-løsning og ikke som en løsning der holder en hemmelig nøgle for dig på et HSM et ikke nærmere specificeret sted i landet. For en SSO-løsning skal du bare have et OTP, et kodeord or lidt SRP. Hell, Blizzard gør det allerede i deres spil og Google gør det med deres sign-on løsning.

Det er den anden del af NemID, den med signering og privatnøgler, der skaber stort set alle problemerne. I princippet kan jeg godt se ideen med at du kan lade et HSM lave arbejdet. Problemet er jo netop at hvis du ikke kan stole på maskinen, så skal arbejdet flyttes et andet sted hen. Men der er noget ideologisk forkert i at din signatur ikke er i hænderne på dig selv.

  • 7
  • 0
#30 Kasper Henriksen

Det har været interessant at følge reaktionerne fra diverse engelsksprogede tech communities om det her, og den generelle tendens lader til at være "er der overhovedet nogen, der bruger Java applets til noget seriøst mere?!"

Det er vel blot endnu et bevis på, hvor bagudtænkende og amatøragtig hele denne NemID-fadæse har været.

  • 8
  • 1
#32 Jesper Poulsen

så er voice biometrics den bedre løsning for godkendelse af UnemID´s brugere

NEJ!

Biometriske løsninger er den største brøler der kan forekomme. Non-biometriske løsninger har den fordel at de kan revoke's i tilfælde af kompromittering. Det kan en biometrisk løsning ikke. CCC i Tyskland viste hvor nemt det var at kopiere et fingeraftryk. Mythbusters har ovenikøbet cracket en lås med fingeraftrykslæser og temperaturføler (der skal et levende menneske til at åbne låsen).

Der er andre ulemper ved biometriske løsninger. En biometrisk løsning er identificerende. Det er aldeles unødvendigt. En authenticering er rigeligt.

  • 6
  • 0
#33 Sune Marcher

Jeg synes man bør skelne mellem PHK's punkt 1-3, samt den fjerde ting som Java også består af: runtimen (jeg vil ikke kalde punkt 3 for en runtime; en runtime afvilker koden og styrer memory management, etc. etc.).

Altså, du mener at "runtime" er den specifikke VM implementation (inkl. JIT engine osv.), samt glue kode der kalder host OS'et (og eventuelt ting som visse JNI kald)? Det giver i hvert fald mening at skille dette lag fra sprogets Runtime Library, der er i Javas tilfælde for mestendels er implementeret i Java.

Der er vel ikke noget sikkerhedsmæssigt galt med 1-3, så det er nok 4 der er problemet. Specielt, åbenbart, sandboxing-systemet som kun benyttes når Java afvikles i browsere.

Så vidt jeg har forstået har der tidligere været bugs i det du (IMHO korrekt) kalder runtimen - man bør ikke kunne lave heap spraying eller stack-overwrite hvis der ikke er runtime bugs.

De nuværende Java7 bugs ser dog ud til at være i runtime library, dog i classloader / reflection kode... noget der muligvis reelt set er implementeret i RTL, men ligger lidt i et grænseland mellem RT og RTL konceptuelt set.

Et meget almindeligt krav er f.eks. at passwordet ikke må lægges i tastaturbufferen, men skal læses direkte fra tastaturet. Det gør det meget sværere for ondsindet software at opsnappe passwordet.

Gør det? Og virker det? Hvis vi snakker x86 (og ignorerer USB keyboards), så har du enten en IRQ1 handler, og så kan du ikke være sikker på at der ikke er malware der har indsat en IRQ1 handler før dig (eller har patched din handler-kode med et jump, eller...), eller også disabler du IRQ1 og står ud og poller port 0x60. Jeg synes ikke rigtigt nogen af mulighederne virker som en fornuftig løsning på et normalt bruger-OS? Eller har jeg overset noget? :)

Jeg tvivler på det er krypteringsalgoritmen de bryder på denne måde, det er langt mere sandsynligt (specielt da de jo har adgang til medarbejdernes maskiner) at de fifler med SSL-certifikaterne og på den måde ligger sig imellem - en teknik der også er meget brugt i Http Debuggers.

Præcis. NemID har dog kryptering indeni SSL kanalen, jvf. artikel i PROSA - hvilket lyder besnærende (jeg må desværre indrømme at jeg til at starte med faldt for det, hvilket gennemkig af gamle v2 posts vil afsløre) - men det er jo åbenlyst bare ikke godt nok, og security-through-obscurity delen har alle dage været latterlig. Offentlig infrastruktur? OpenSource, tak.

Det er den anden del af NemID, den med signering og privatnøgler, der skaber stort set alle problemerne.

Det har du ret i og det er derfor nogen af os fra starten bad om at der blev lavet to helt separate systemer: Et til SSO og et til signering osv.

Amen. SSO delen burde vel kunne klares med noget forms over https og et papkort (papkortet synes jeg er udmærket, men det er sjovt nok den del af NemID som "normale" folk brokker sig over >_<).

Men PHK, hvordan vil du foreslå at signatur delen løses? Jeg ville personligt ret gerne have kontrol over min private nøgle, men er det den bedste løsning for hr og fru teknologi-udfordret? Skulle man bruge client SSL certs, GPG/PGP keys, eller (the horrors!) noget hjemmebrygget? Jeg ville være ret ked af at se et eller andet hjemmebrygget skodsystem der følger den sædvanlig dansk-offentlig-IT katastrofekurs... og tanken om at skulle køre et eller andet native kode er sgu næsten værre end Java plugin.

Jeg tænker at et hardware modul er den eneste ordentligt sikre løsning, men jeg stoler på ingen måde på det, NETS er kommet med. Nogle har nævnt det Tyske ChipTan, men så vidt jeg kan forstå fungerer det kun til ting i bank-overførsels kategori?

Der ligger IMHO en stor udfordring i at lave noget der både er teknisk sikkert, og brugbart+forståeligt for de teknologiudfordrede. Er der nogle eksisterende fornuftige løsninger?

  • 3
  • 0
#34 Finn Christensen

Jeg tænker at et hardware modul er den eneste ordentligt sikre løsning, men jeg stoler på ingen måde på det, NETS er kommet med. Nogle har nævnt det Tyske ChipTan, men så vidt jeg kan forstå fungerer det kun til ting i bank-overførsels kategori?

Hardware - ex. en USB-dims, er en nem, brugbar og for H. Jensen forståelig løsning. Men en udskrivning på fx. ~2-300 kr. * 3. mio. brugere (= ~750 mio.) kvalte den løsning i fødslen, både etableringsmæssigt og økonomisk - så vi fik papkort.

Bankforretning og den offentlige digitale ID skulle aldrig være koblet til en 'fælles' NemID - kun en regnemaskine kan udtænke den løsning. Et menneske kan nemt skønne, at det med 100% sikkerhed er usikkert.

1) Banken og alle private aktører har deres 'nemme' og 'billige' løsning - det er deres naturlige verden. 2) Det offentlige har den sikre løsning til enhver tilgang i offentlig regi samt den digitale signering, drevet og sikret i statslig regi.

I øvrigt vil de to nøgler/ID'er godt kunne hentes fra en USB-dims, hvis man tænker sig lidt om. Der er ingen grund til borgerne skal rende rundt med to eller flere i lommen.

  • 2
  • 0
#35 Sune Marcher

Finn: delvist enig.

Med "brugbar" og "forståelig" vil jeg mene at man skal sigte efter noget der beviseligt sikkert og forståeligt brugbart... hvilket er en forbandet svær opgave at løfte. Man kan sagtens lave noget der ligner at det er både og, men ikke er nogle af delene. Der er stor forskel på om man vil have SSO eller signaturer eller begge dele.

Hvis vi kigger på hardwaremodul, skal det være 100% afkoblet fra den enhed der bruges til kommunikation. Det duer bare ikke at smide en USB enhed til en computer - der er for mange angrebsvektorer, og man skal understøtte flere operativsystemer. No go. Hvordan får man så en afkoblet enhed til at være både brugervenlig og sikker? ChipTan løsningen duer sjvj kun til banktransaktioner. Hvordan vil du præsentere en kompleks digital signering af et dokument på en ekstern enhed, på en sikker måde?

  • 1
  • 0
#36 Deleted User

Jeg har selv C/C++ og Java som mine foretrukne programmerings sprog, og synes at Java har mange gode kvaliteter som bla. gør at man relativt hurtigt kan udvikle programmer i Java, som det ofte vil tage længere tid tid at udvikle i C/C++, og så har Java bla. den fordel at det er struktureret, indkapslet, og funktionelt meget sikkert at kode i. Desuden, så er næsten alle IT uddannelser i Danmark primært fokuseret omkring Java, hvilket muligvis er et problem, men dog en realitet ! Derfor vil IT Danmak nok nærmest gå i 'koma' hvis man sløjfede Java ! Igen et eksempel på at Danmark ikke har været særlig smarte i forhold til at gøre sig stærke og uafhængige af amerikanske firmaer og strømninger inden for IT markedet (hvis alle lærte open source teknologi og mestrede hardcore emner som f.eks. datalogisk matematik, og kunne kode seriøst i f.eks. C/C++, så vil vi langt hurtigere kunne tilpasse os og være konkurrence dygtige i en altid skiftende IT verden, istedet for som nu at 'låse os inde' i firma teknologier som f.eks. Sun/Oracle's Java) !

Men vedr. det med NemID og Java, så er det basale problem vel egentlig 'bare' at man har lukket Java appletter ud af sandkassen (sandbox'en), og det vil vel være muligt at lave en global 'oprørs bevægelse' imod dette, og så kæmpe for at få Java appletter tilbage i sandkassen hvor den for browsere hører hjemme ! Eller måske man kan få udviklerne af f.eks. Chrome og Firefox, til som default at have en funktionalitet der tvinger Java appletter ind i en sandbox !

Selvom jeg må indrømme at jeg ikke har meget forstand på det juridiske omkring Java, så vil det vel være muligt for for en international open source sammenslutning at overtage eller parallel udvikle bla. applet JRE'en som jo er den der giver problemer ? Hvis en open source sammenslutning har ansvaret for en sådan JRE, så vil sikkerheds problemer jo blive løst nærmest øjeblikkelig, som det f.eks. ses med Linux og andre open source *nix systemer ! Og desuden, så vil Java som ren open source nok også blive meget mere kreativ og 'front-end' !

Og vedr. NenID, så kunne man jo også der gøre det smarte, nemlig at hvad man end vil lave til Netbank, så basere det på open source teknologi, som f.eks. sipML5 !

  • 0
  • 0
#37 Jesper Lund

Men vedr. det med NemID og Java, så er det basale problem vel egentlig 'bare' at man har lukket Java ud af sandkassen (sandbox'en), og det vil vel være muligt at lave en global 'oprørs bevægelse' imod dette, og så kæmpe for at få Java tilbage i sandkassen hvor den for browsere hører hjemme !

Problemet i denne sammenhæng er ikke NemID's Java kode eller Java sproget som sådan, men de Java appletter som folk med onde hensigter kan finde på at lave og placere på hjemmesider. Hvis du skal bruge NemID, skal du tillade afvikling af Java appletter i din browser (installere Java plugin til browseren), og dermed eksponerer du dig overfor Java appletter fra folk med skumle hensigter (malware).

Hvis du har en browser som du kun bruger til NemID ting (og intet andet) og deaktiverer Java plugins i dine øvrige browsere, bør der ikke være noget problem.

Det er bare lidt halvbesværligt at sætte op for den almindelige dansker, og i praksis var det nok nemmere at give familien Danmark en præ-konfigureret Virtual Machine med Linux, Firefox og Java, som de kunne køre i VirtualBox, og så fjerne Java helt fra computeren. At køre NemID ting på en separat computer vil også højne sikkerheden.

  • 3
  • 0
#38 Deleted User

@Jesper Lund

Som jeg forstår det, så er problemet at Java appletter nu har adgang til filsystemet oa. og ikke som tidligere hvor Java appletter var tvunget ind i en sandbox.

Jeg er helt enig i din idé med virtuelle maskiner og bruger selv bla. et sådant setup. Og det vil løse mange problemer hvis grupper i DK med afgang til hele befolkningen (f.eks. staten, CERT osv.), vil lave sådanne løsninger !

  • 1
  • 0
#39 Klaus Slott

Hvordan får man så en afkoblet enhed til at være både brugervenlig og sikker? ChipTan løsningen duer sjvj kun til banktransaktioner. Hvordan vil du præsentere en kompleks digital signering af et dokument på en ekstern enhed, på en sikker måde?

Det er netop hovedproblemet: Du kan ikke stole på hvad din komputer viser på skærmen. ChipTan løser det for bank transaktioner ved at have sit eget lille regnemaskine display, hvor man kan verificere konto nr. og beløb inden man taster sin accept kode ind. Det du'r bare ikke når vi snakker om mange siders juridiske dokumenter. Hvordan kan kan man lave et system hvor jeg er sikker på, at det jeg underskriver er magen til det som min sagfører har sagt god for og nogen ikke har udskiftet lidt tekst undervejs til min skærm. Og som vel og mærke også kan betjenes af min teknikforskrækkede gamle mor på Møn. Jeg har ikke svaret, men hvis alle de millioner der er brugt på NemID, i stedet var blevet brugt til at gøre den forrige Digitale signatur brugervenlig, ku' vi måske være nået et stykke af vejen.

  • 1
  • 0
#40 Deleted User

@Jesper Lund

Jeg kom lige at tænke over din kommentar 'engang til'. Grunden til at sikkerheds problemerne med applet JRE'en påvirker Java generelt, den er at på de mest udbredte OS'er der er applet JRE'en en del af std. JRE installationen (som man så 'slår til' i browserne), og jeg har læst at for f.eks. IE's vedkommende der kører Java stadig i browseren selv om man slår den fra i IE (har dog ikke selv verificeret dette). Og da mange administrative programmer i DK kører Java, så er man 'fanget' af Oracle's sikkerheds problemer, medmindre man istedet kører en open source Java JRE, men desværre så findes der ikke en 100% open source applet JRE, da IcedTea kun er delvis open source, og så vidt jeg ved den eneste Java ud over Oracle's der kan køre applets ! Og mig bekendt, så kører ingen eller få institutioner eller firmaer i DK andet end Oracle's Java, hvilket så vil sige at for MS Windows vedkommende at der er hul igennem IE (men det er jo ingen nyhed) ! Problemet er så, at fejler Oracle's Java, så fejler DK !

  • 0
  • 0
#42 Finn Christensen

Hvis vi kigger på hardwaremodul, skal det være 100% afkoblet fra den enhed der bruges til kommunikation. Det duer bare ikke at smide en USB enhed til en computer - der er for mange angrebsvektorer, og man skal understøtte flere operativsystemer. No go. Hvordan får man så en afkoblet enhed til at være både brugervenlig og sikker? ChipTan løsningen duer sjvj kun til banktransaktioner. Hvordan vil du præsentere en kompleks digital signering af et dokument på en ekstern enhed, på en sikker måde?

@Sune 1) Vi har allerede den ene løsning. Ingen grund til at vi skal gå den vanlige (tåbelige) vej og opfinde en ny BankID, da den allerede findes som ChipTan eller den HW løsning (nøgleviser) der i dag tilbydes herhjemme. 1a) Den manglende mobile del, finder handel/bankerne også ud af - når der er penge at tjene, kommer der lønsninger.

2) Som Klaus Slott tilsvarende beskriver, og der hvor jeg også får 'onde drømme om natten' - vi mangler løsningen for vores offentlige ID samt Dig.signatur uden Java og bankernes fejlskud af NemID. Den kan laves og den kan kobles sammen i een enhed med ovennævnte.

Misforstå ikke min USB-dims, som den kendte lagerenhed. Jo den ligner, og har stikket og bruges i en USB sokkel på HW. Men som ChipTan er det ikke en du har købt på tilbu' i Netto :)

Mht. fælles 'hylster' er det uproblematisk og den mest brugervenlige løsning til hovedparten af befolkningen: a) hovedparten skal alligevel bruge begge løsninger - bank + offentlig b) nok over 50% vil også fremover gerne kunne bruge en mobil bank- og handelsløsning - smartphone. De fleste har faktisk også mini-/microUSB... desværre er producenters sygelige trang til at snyde sig fra standardisering her stadig fremherskende. d) de personer, der har nok i nuværende papkort, kan roligt fortsætte der. Overgangsperioden vil pga. den store mængde enheder blive lang - det tager tid.

  • 0
  • 0
#45 Deleted User

@Finn Christensen

Og hvorfor blive ved at bruge teknologi hvor vi igen vil blive afhængig af en 3. parts udvikler, istedet for at bruge open source teknologi som f.eks. sipML5. Er det en folkesygdom at danskere bare vil være afhængige af andre eller hvad ???

  • 0
  • 0
#46 Klaus Slott

ChipTan er vidst da heller ikke specielt sikkert:

som jeg læser de beskrevne angreb, er de kun mulige fordi at tyske banker (i bekvemmelighedsøjemed) tillader brugerne at godkende mere end det er muligt at vise i det lille display. Jeg mener stadig princippet er rigtigt og samtidig bekræfter det problemet med at godkende større dokumenter, eller komplekse operationer.

  • 0
  • 0
#47 Deleted User

@Klaus Slott

Nu er det ikke fordi at jeg på nogen måde er ekspert i ChipTan, men det er ikke lige sådan jeg forstår exploit'et. Se evt. her:

http://www.h-online.com/security/news/item/Online-banking-trojan-has-des...

Desuden så har hardware løsninger det problem at hvis der er mange penge i det, så kan de kopieres og modificeres. Faktisk findes der firmaer bla. i østeuropa og asien der tilbyder reverse engineering af mindre chips, hvilket nok er hvad der sidder i ChipTan !

  • 0
  • 0
#48 Deleted User

Og igen hvorfor ikke bare lave en løsning som NemId, men i stedet for Java så med sipML5. Det vil være billigt og kunne bruges af alle, og hvis der opstår sikkerheds problemer, så kan de hurtig fikses !

  • 0
  • 0
#49 Joe Sørensen

Hvor meget skal der til for at lave en simpel løsning, som opfylder kravene.

Jeg forstillinger mig noget som: - Bruger javascript osv, der virker i alle browsere. - Beholder papirkortene med numre, der er der den simpleste og billigste måde at vi 2 faktor kryptering på. Og vi har jo lært alle at bruge det allerede. - Kontrollere CA, da det jo ikke er ligegyldig hvem der har udgivet certifikatet. - Tilbyder SSO mellem forskellige systemer som anvender NemID. - Mulighed for adgang til at bruge systemet til OpenID enabled services, så det kan bruges af uafhængige virksomheder og organisationer. ( Eller bare droppe NemID og bruge OpenID )

Jeg er i tvivl om man kan kontrollere CAen fra JavaScript, men mund ikke det kan lade sig gøre. Og det med single sign on er der nogen der har fået til at virke allerede.

  • 0
  • 1
#50 Hans Vester

Hvis du har en browser som du kun bruger til NemID ting (og intet andet) og deaktiverer Java plugins i dine øvrige browsere, bør der ikke være noget problem.

Det er nemmer at slå "Click to play" til (hedder det i Chrome men andre browsere har sikkert lignende indstilling). Så starter plugins som Java, Flash, Reader etc ikke automatisk. De erstattes af en knap du skal trykke på for at aktivere dem.

På sites som Version2 der med bruger genereret indhold er i risikogruppen for XSS og CSRF undlader man blot at starte plugins.

  • 0
  • 0
#51 Sune Marcher

Det er nemmer at slå "Click to play" til (hedder det i Chrome men andre browsere har sikkert lignende indstilling). Så starter plugins som Java, Flash, Reader etc ikke automatisk. De erstattes af en knap du skal trykke på for at aktivere dem.

Det er også hvad jeg anbefaler "normale" folk, der ikke kan overskue at launche en separat browser til flash/java.

Men har vi en garanti for det rent faktisk er sikkert nok? Det er garanteret muligt at exploite browseren til at disable click2play... spørgsmålet er kun om man så samtidig kan exploite den til at gøre mere end det, eller om det i sig selv er en god exploit vector.

  • 0
  • 0
#52 Klaus Slott

Nu er det ikke fordi at jeg på nogen måde er ekspert i ChipTan, men det er ikke lige sådan jeg forstår exploit'et. Se evt. her:

Den første link du postede til et google docs dokument var der mere kød på. Nu linker du til en beskrivelse rent bondefangeri. Folk bildes at "vi skal lige lave en prøveoverførsel..." Jeg tror selv min gamle mor ville blive mistænksom. ChipTAN har adskillige problemer (for klodset til tegnebogen, lukket hardware, begrænset feedback pga lille display, dårligt anvendelse jvf. din tidligere link). Men princippet i at flytte verifikation og accept af en transaktion ud på en beskyttet enhed er, efter min mening, det eneste der holder.

  • 1
  • 0
#53 Deleted User

@Klaus Slott

Vedr. det med at blive mistænksom, så er der så vidt jeg husker 0,3 % af danskerne der hopper på 'langt ude' phishing mails og lign. Det kan da hurtigt blive til mange penge !

Desuden så er det en illusion at tro at der findes beskyttede enheder med alm. hardware. Hvis alle har en ChipTan derhjemme, så vil IT kriminelle kunne få fat i dem og kunne modificere funktionaliteten, og f.eks. ved at følge med i en transaktion kunne lave en kopi af hardwaren (evt. som software på en PC eller som kopi hardware) der kan simulere en autentisk ChipTan med kort oma. oma. oma.

Jeg vil faktisk mene at NemID er en bedre løsning !

Og så kan jeg ikke forstå hvorfor det vil være en god idé at blive afhængig af mere udenlandsk teknologi ! Vi er allerede temmelig 'fucked' fordi diverse amerikanske firmaer ikke har sikkerheden i orden (f.eks. Oracle og Microsoft osv.) ! Derfor mener jeg at åben source må være vejen frem, da vi selv kan kontrollere og modificere den, bla. i tilfælde af fejl, hvor vores egne eksperter så hurtig kan lave en fejlrettelse) !

  • 1
  • 2
#54 Brian Mathiasen

Men har vi en garanti for det rent faktisk er sikkert nok? Det er garanteret muligt at exploite browseren til at disable click2play... spørgsmålet er kun om man så samtidig kan exploite den til at gøre mere end det, eller om det i sig selv er en god exploit vector.

Nej, der er ingen garanti for at click2play er sikkert. Ligesom Java er selve browseren også en angrebsvektor uanset om du bruger click2play eller ej, om du bruger java eller ej, eller noget tredje. Men det er dog en funktion, der giver dig bare en anelse mere kontrol over hvad der foregår i din browser.

  • 1
  • 0
#55 Klaus Slott

@Kim: Jeg ved ikke hvad dit ærinde er, men jeg har på intet tidspunkt argumenteret for at vi specifikt skal erstatte NemID med ChipTAN. Jeg har forholdt mig til princippet i at flytte verifikation og accept til en billig eksten device som er min og ikke er netværksforbundet.

En device som kunne produceres efter opensource hardware opskrift af forskellige konkurrerende hardwarefabrikanter, eller hvis man er paranoid loddes sammen hjemme på køkkenbordet.

NemID er en bedre løsning !

I rest my case.

  • 2
  • 0
#56 Baldur Norddahl

Hardware - ex. en USB-dims, er en nem, brugbar og for H. Jensen forståelig løsning. Men en udskrivning på fx. ~2-300 kr. * 3. mio. brugere (= ~750 mio.) kvalte den løsning i fødslen, både etableringsmæssigt og økonomisk - så vi fik papkort.

Mener du at en USB-nøgle koster 200-300 kroner? Så tager du fejl: https://store.yubico.com/store/catalog/index.php?cPath=2

Prisen er under 100 kroner per styk hvis du køber 50. Man kan kun gætte på hvad de koster, hvis man skal bruge 3 millioner. Et godt gæt er noget i stil med en ti'er, for Yubikey er netop lavet til at være ekstremt billig at masseproducere.

Man vil også kunne lave Yubikey med mikrousb som passer i ældre smartphones. Nyere smartphones og tablets kan bruge udgaven der har NFC.

  • 1
  • 0
#58 Baldur Norddahl

Ønskes: Kreditkortstørrelse E-Ink display uden batteri eller anden strømforsyning end NFC.

For at godkende en transaktion føres den til din tablet eller din NFC-læser på computeren, hvorefter displayet skifter til at vise transaktionsdetaljer. Hvis alt er ok, fører du kortet forbi en gang mere imens du holder på en accept-knap.

E-Ink er ganske billigt og har den egenskab at skærmbilledet bliver stående uden strømforbrug.

De fleste computere har ikke NFC men en USB-læser til NFC er ikke dyr. Alternativt kan man lave en udgave der kan sættes direkte til USB.

  • 2
  • 0
#59 Carsten Jørgensen

hvis alle de millioner der er brugt på NemID, i stedet var blevet brugt til at gøre den forrige Digitale signatur brugervenlig

Er det en god ide at have en nøglefil liggende på hvert eneste device man bruger ?

ChipTAN / flytte verifikation og accept til en billig eksten device

Der blev vurderet fire løsninger (simple nøgleviser, ekstern kortlæser, challenge-response og papkortet).

Over projektets løbetid er der ingen væsentlig prisforskel på løsningerne. Det var udelukkende pga usability testene (udført af en ekstern virksomhed), at vi har papkortene.

DanID skal bruges af hele Danmarks befolkning, unge og gamle, og der er mange der har store udfordringer med IT, men pap-kortet lærte de hurtigst. Challenge-response løsningerne (løsningen returnerer en talværdi baseret på det man har indtastet, som man derefter skal indtaste i en intern enhed) var ekstrem svær at forstå for mange.

Hardware - ex. en USB-dims, er en nem, brugbar og for H. Jensen forståelig løsning. Men en udskrivning på fx. ~2-300 kr. * 3. mio. brugere (= ~750 mio.) kvalte den løsning i fødslen, både etableringsmæssigt og økonomisk - så vi fik papkort.

Det er en urban myth. Se ovenfor.

Der er flere muligheder for eksterne dimser med display i dag end der var i 2007. Så måske i næste version? Men bare fordi der står på displayet, at man er ved at overføre 1000 kr til østeuropa, i stedet for 50 kr til moster Oda, betyder det ikke at nogle alligevel ikke vil gøre det.

  • 1
  • 0
#60 Jesper Louis Andersen

Er det en god ide at have en nøglefil liggende på hvert eneste device man bruger ?

Det er det helt centrale spørgsmål. Lige nu er der ingen nøglefil på noget device jeg bruger. Det har jeg det sådan set fint med, men jeg kan så heller ikke bruge den nøglefil til nogetsomhelst - for jeg kontrollerer den ikke. Det er også dette forhold der gør det tvivlsomt om løsningen overhovedet kan kaldes en "Digital Signatur", rent juridisk.

Det havde været 100 gange federe, hvis jeg kunne have signeret med en ægte privatnøgle også. Jeg ser ikke nogen grund til at blande 3.part ind i det her så jeg også skal stole på dem, HSM eller ej.

  • 2
  • 0
#61 Jesper Lund

Er det en god ide at have en nøglefil liggende på hvert eneste device man bruger ?

Nej, bestemt ikke. Hvis samme nøgle skal ligge flere steder, vil man ikke kunne generere nøglen i det kryptografikske modul (hvad enten det er DanIDs HSM eller et smartcard under min fysiske kontrol ala NemID på hardware).

Men det er heller ikke en god ide at have nøglerne liggende i et centralt HSM, hvis man er nødt til at bruge Java for at skabe sikker adgang til nøglerne.

  • 2
  • 0
#62 Christian Nobel

Det er også dette forhold der gør det tvivlsomt om løsningen overhovedet kan kaldes en "Digital Signatur", rent juridisk.

Den har været diskuteret mange gange før, men da den eneste lov der findes her i kongeriget er LOV nr 417 af 31/05/2000, som eksplicit skriver:

Kapitel 2 § 3. Stk 2) Avanceret elektronisk signatur: En elektronisk signatur, der

a) entydigt er knyttet til underskriveren, b) gør det muligt at identificere underskriveren, c) skabes med midler, som kun underskriveren har kontrol over, og som d) er knyttet til de data, den vedrører på en sådan måde, at enhver efterfølgende ændring af disse data kan opdages.

Kapitel 4 § 10. Stk. 3 Nøglecentre må ikke opbevare eller kopiere de personers signaturgenereringsdata, som nøglecentret gennem udstedelsen af certifikater måtte have fået kendskab til.

Læs evt. selv hele loven igennem: https://www.retsinformation.dk/forms/R0710.aspx?id=6193

Der er ingen diskussion, konstruktionen lever ikke op til gældende lov!

  • 4
  • 1
#63 Michael Friis

NemID bygger på en SRP autorisering (http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol) og er et fantastisk godt og sikkert zero knowledge system.

Der findes implementeringer i Javascript (http://srp.stanford.edu/demo/) men for at bruge det 100% i Javascript skal du ud og finde en Bigint implementering i ren javascript (http://www.leemon.com/crypto/BigInt.html) som, som linket antyder også findes.

BigInt har dog et problem i de gamle browsere. Specielt IE 8 og nedefter har begrænsninger i sin javascript motor der gør at browseren tror scriptet kører i uendligt loop hvis det laver mere end et par tusind iterationer i en løkke. Det gør BigInt og en ren javascript implementering vil derfor komme op med en grim advarsel til brugeren om at der er noget galt med javascriptet på siden samt om brugeren vil fortsætte afviklingen.

Når man alligevel er ude og skal bruge et runtime til Bigint så er det naturligt også at ligge resten i den teknologi. Det har DanID gjort.

BigInt og SRP fungerer i øvrigt helt uden problemer i moderne browsere (inklusiv IE9).

  • 2
  • 2
#65 Deleted User

@Klaus Slott

Det jeg mente med at NemID nok er bedre, det skulle forstås udfra en forestilling om at man fortsætter med de nuværende kode kort, men istedet for at være afhængig af Oracle's Java, så udvikle en tilsvarende løsning bare i HTML5 evt. med sipML5 eller lignende open source. Det vil dels have den fordel at det vil være billigt, og dels at det vil kunne køre på alle (de fleste) platforme, inkl. f.eks. Linux, Android, og iPhone osv. Og hvis der opstår sikkerheds problemer, så kan de hurtigt og billigt fikses af udviklere her i landet !

  • 0
  • 0
#66 Baldur Norddahl

Den egentlige årsag til at NemID bruger java er at det offentlige vil have et system, der er kompatibelt med det gamle OCES system fra TDC. Java kan simulere et brugercertifikat overfor en webside hos det offentlige. På den måde kunne det offentlige implementere NemID uden at ændre andet end at inkludere en stump HTML på loginsiden.

Alle løsninger uden Java vil kræve at det offentlige skal gøre noget. Det er de ikke interesseret i. Så derfor hænger vi så krampeagtigt fast i Java-løsningen.

  • 6
  • 0
#68 Thorbjørn Andersen

Jeg er ikke modstander af at få java ud af nem-id løsningen, men jeg kan ikke se hvordan de største problemer løses med det. Det er og vil være et mindre problem. Folk vil måske have Java installeret alligevel til andre programmer ...

Derudover hjælper java ud af nem-id intet, når man snakker om at kodeord bliver lokket ud af brugeren eller computeren er blevet overtaget i forbindelse med andre sikkerhedshuller ... (og det er ikke nødvendigvis java, men browseren eller installede programmer, som man ikke burde have stolet på ...)

Det, der primært er behov for er altså at man modtager en kode på sms (eller anden uafhængig kilde), hvor den (vigtige) handling, som man er ved at foretage sig også nævnes.

Alt andet end lige vil det gøre hacking noget mindre værd ...

  • 1
  • 2
#69 Rasmus Faber-Espensen

Den har været diskuteret mange gange før, men da den eneste lov der findes her i kongeriget er LOV nr 417 af 31/05/2000, som eksplicit skriver:

Kapitel 2 § 3. Stk 2) Avanceret elektronisk signatur: En elektronisk signatur, der

Jep, det har været diskuteret mange gange før. Og hver gang kommer du med samme påstand. Men Loven definerer en "avanceret elektronisk signatur", ikke en "digital signatur". NemID er således ikke en "avanceret elektronisk signatur", men der er derimod ingen der forbyder DanID i at kalde det for en "digital signatur".

  • 2
  • 3
#70 Christian Nobel

Jep, det har været diskuteret mange gange før. Og hver gang kommer du med samme påstand. Men Loven definerer en "avanceret elektronisk signatur", ikke en "digital signatur". NemID er således ikke en "avanceret elektronisk signatur", men der er derimod ingen der forbyder DanID i at kalde det for en "digital signatur".

Nu er det bare sådan at den eneste lovgivning der eksisterer på området så også har adjektivet avanceret med i sig.

Så er det muligt at du kan påstå at DanID kan gøre hvad de vil hvis de piller avanceret ud af konteksten, og det kan de muligvis godt, men så er der ingen lovhjemmel, og derfor kan den heller ikke have nogen retsgyldighed!

DanIDs af dem selv kaldte "digitale signatur" kan sådan set godt bruges mellem to private parter efter gensidig overenskomst, men da der ikke er tale om en gensidig overenskomst er vi tilbage til, at der stadig kun er en gældende lov på området, og der kan du altså ikke forplumre debatten ved at fluekneppe omkring udtrykket avanceret.

  • 2
  • 0
#71 Rasmus Faber-Espensen

Så er det muligt at du kan påstå at DanID kan gøre hvad de vil hvis de piller avanceret ud af konteksten, og det kan de muligvis godt, men så er der ingen lovhjemmel, og derfor kan den heller ikke have nogen retsgyldighed!

Almindelige fysiske underskrifter er heller ikke definerede i nogen lov. Af den grund kan man stadig godt bruge dem i en evt. retsag. Der er ingen formkrav i dansk ret, så fysiske underskrifter, "digitale signaturer" og "avancerede elektroniske signaturer" kan alle indgå som elementer i en retssag. Det eneste interessante er at der er afgivet en "viljeserklæring" og den kan så antage en lang række former. "Avancerede elektroniske signaturer" får i Lov om elektroniske signaturer en særstatus (bl.a. må man ikke kalde noget for en "Avanceret elektronisk signatur", hvis det ikke opfylder en række krav).

Alt det ovenstående ændrer ikke på, at DanID gerne må kalde NemID for en digital signatur, at det er muligt at bruge en digital signatur fra NemID i en retssag eller at det offentlige må give adgang til oplysninger på baggrund af en NemID-signatur.

  • 2
  • 3
#72 Gregers Mogensen

DanID's Applets implementerer faktisk en vigtig sikkerhedsfeature, som dit forslag om en simpel HTML formular mangler: de etablerer en krypteret tunnel helt tilbage til DanID's HSM moduler, som anvendes til at verificere brugerens credentials.

Med en simpel HTML formular beskyttet af HTTPS vil det være muligt for alle de web-sider, som skal bruge NemID, at opsnappe brugerens credentials. De bliver reelt en man-in-the-middle, fordi SSL/TLS forbindelserne terminerer ved web-serveren og ikke giver end-to-end kryptering.

Det betyder, at et vilkårligt sårbart site, som anvender NemID, kan bruges til at angribe brugerne - og dermed er angrebsfladen meget større end med det nuværende setup, hvor det svageste led er brugerens computer.

  • 1
  • 0
#73 Jesper Lund

DanID's Applets implementerer faktisk en vigtig sikkerhedsfeature, som dit forslag om en simpel HTML formular mangler: de etablerer en krypteret tunnel helt tilbage til DanID's HSM moduler, som anvendes til at verificere brugerens credentials.

Jo, men hvad hjælper det når DanIDs servere ikke kan vide om de taler med mig eller en MiTM angriber som har opsnappet mit password og laver real-time phishing af OTP koder?

Det er fint at der er end-to-end helt ind i HSM'et, men starten på denne kæde er ikke nødvendigvis mig. Det kan ligeså godt være en MiTM angriber. Og i øvrigt ville det være endnu bedre hvis den private nøgle befandt sig hos borgeren, hvor den hører hjemme. Så ville der også være en veldefineret protokol for at bruge den private nøgle så vi ikke behøvede det nuværende Java lag.

Jeg har heller ikke nogen reel mulighed for at checke om Java appletten kommunikerer med DanID eller en MiTM angriber. Det er samme problem som med 3D Secure ("verifikation" af kreditkort ved online køb).

Du er nødt til at anlægge et helhedsperspektiv på sikkerheden. Det hjælper ikke ret meget af DanID laver nogle fine server-side løsninger, hvis den valgte teknologi efterlader klienterne eksponeret over for MiTM angreb eller drive-by Java exploits på andre websider fordi man er nødt til at have Java installeret i klientbrowseren.

Det er mindst lige så vigtigt at klientsiden er "tamper proof", og det er den på ingen måde med den nuværende løsning.

  • 2
  • 2
#74 Henrik Schmidt

Det er fint at der er end-to-end helt ind i HSM'et, men starten på denne kæde er ikke nødvendigvis mig.

I øvrigt er det stadig ikke end-to-end, da appletten formentlig ikke bliver hentet fra HSM.

Jeg har svært ved at forestille mig et scenarie, hvor man får bedre sikkerhed med den nuværende løsning frem for en dum HTML side på danids server, som der bliver redirectet til.

  • 0
  • 1
#75 Baldur Norddahl

De bliver reelt en man-in-the-middle, fordi SSL/TLS forbindelserne terminerer ved web-serveren og ikke giver end-to-end kryptering.

Læs lidt op på OpenID: http://en.wikipedia.org/wiki/Openid

"As of December 2009, there are over 1 billion OpenID enabled accounts on the Internet (see below) and approximately 9 million sites have integrated OpenID consumer support".

Og nej, dit website kommer ikke til at håndtere passwords fra andre sites. Når du bruger Google som OpenID udbyder, så har du tilmed deres two-factor sikring - alt det ved klient-sitet ikke noget om. De åbner bare en popup til openid-udbyderen, og venter på at der bliver lavet en redirect tilbage med accept eller afvisning.

  • 0
  • 0
#76 Deleted User

Må man ikke gå ud fra at et af målene med NemID er at have fuld læse/skrive adgang til computeren det kører fra? Siden det er en del af specifikationen at der er det?

I så fald er det jo ikke bare at erstatte NemID med noget mere sikkert, da det jo per definition ikke kan give læse/skrive adgang til computeren der kører det gennem en browser?

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