Her er redegørelsen fra Nets om NemID-adgang

Læs redegørelsen fra Nets til Digitaliseringsstyrelsen om 'tys-tys-kildens' adgang til NemID-systemet.

Digitaliseringsstyrelsen har nu modtaget og offentliggjort en redegørelse fra Nets om muligheden for læk af data fra NemID-systemet. Læs redegørelsen herunder:

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (14)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Pelle Söderling

Jeg synes reelt det største problem her er at man kan konkludere så skråsikkert at NemID systemet ikke har været kompromiteret af denne systemadministrator, som trodsalt har haft ret omfattende adgang til systemet.

Jeg synes der er flere åbne spørgsmål:

  • Hvis vedkommende har en backup-rolle for NemID, hvordan har man så sikret sig at han ikke har hevet data ud af backup'en? Dette vil næppe blive logget nogen steder.
  • Access logning sker oftest i form af adgang til et ovenliggende system, men har han kunnet tilgå databaserne / databasefilerne direkte?
  • Har han som administrator haft mulighed for at manipulere logfilerne og dermed skjule sine spor?
  • Hvor meget kan man stole på den pågældende access-logning - hvor dækkende er den reelt? Og har den nogen relevans for administratorer der jo har langt større muligheder for at tilgå dataene direkte end alm. brugere som oftest vil gå via et interface (hvori logningen somregel er implementeret).
Peter Makholm Blogger

Hvis vedkommende har en backup-rolle for NemID, hvordan har man så sikret sig at han ikke har hevet data ud af backup'en?

Efter min læsning har medarbejderens rolle ikke været at håndtere backup af systemer tilknyttet NemID. Der er tale om at medarbejderen har været backup for de medarbejdere der i det daglige har haft fukntioner tilknyttet NemID – det vil sige at han har skulle overtaget arbejdet i tilfælde af kritisk fravær. Ligeledes virker den beskrevne administrator-rolle heller ikke til at være en systemadministrator-rolle, men nærmere bare en superkundeserviceperson.

Hvis man ønsker at kommentere på redegørelsen tror jeg at man skal læse den et par gange (både indenad og mellem linjerne) og tænke over hvad der rent faktisk står.

Selv har jeg kun skimmet den igennem, så derfor vil jeg ikke udtale mig om indholdet af selve redegørelsen.

Pelle Söderling

Peter: Er det muligt at varetage en backup rolle for andre medarbejdere som en del af et overvågningsteam uden at have de nødvendige system rettigheder også ?

Det er ret nemt at læse redegørelsen som fanden læser biblen, det kan vi godt blive enige om - men det er sgu også nemt at skrive den når man er sin egen auditor. Jeg har svært ved at se denne redegørelse som en garanti for at misbrug ikke har fundet sted eller at det skulle have været umuligt at udføre i den pågældende rolle.

Vi har ikke de fornødne forudsætninger til at kunne validere alle postulaterne, så i sidste ende er vi nød til at tage Nets ord for pålydende.

Michael Hansen

Min bekymring er nu mest følgende citat:

"Opsummerende gælder det at:

der har aldrig været, og er fortsat ikke en risiko for kompromittering af borgernes private nøgler."

Jeg vil nødig være den borger der får kompromitteret sin private nøgle, man vil jo ikke have en kinamands chance for at forsvare sig selv, når de så "sikkert" kan sige der 100% ingen risiko har været, og ikke vil være det fremover.

Jeg kan helt ærligt ikke se hvordan de kan være så sikre på det. De siger de bruger "hardware" (som kører software...) HSMs, men det alene, gør det jo ikke per definition sikkert, det kan være fejl konfigureret (vil jo ikke overraske hvis det skulle være tilfældet med de vi har hørt indtil videre), der kan være exploits etc.

Søren Larsen

"Den eksterne statsautoriserede systemrevisor afgiver én gang årligt systemrevisionserklæring til Digitaliseringsstyrelsen om, hvorvidt Nets DanID overholder kravene i Certifikatpolitikken. Nets DanID følger op på alle observationer fra den årlige systemrevisionserklæring"

Revisiorer, både interne og eksterne, har ikke nødvendigvis resourcer til at selv at undersøge alle forhold i detaljer, og må derfor nogle gange stole på det de får at vide af dem der skal undersøges. Det er en kendt sag (der hvor jeg kommer fra) at revisionen delvist bygger på tillid mellem parterne. Det er selvfølgelig rart at kunne sige at man overholder alle krav til ekstern revision, men værdien af denne er ikke en kendt størrelse.

Loke Dupont

Jeg vil nødig være den borger der får kompromitteret sin private nøgle, man vil jo ikke have en kinamands chance for at forsvare sig selv, når de så "sikkert" kan sige der 100% ingen risiko har været, og ikke vil være det fremover.


Nej, den undrede jeg mig også over. Selv hvis vi antager at denne hardware virker 100% korrekt, så er det vel stadig muligt at kompromittere, om ikke andet som Man in the Middle, med mindre hardwareenheden selv terminerer SSL kontakten med brugerens browser.

Jeg finder det dog langt mere sandsynligt, at HSM'en ikke engang validerer fx nøglekortet eller brugerens kodeord, men dette valideres at et andet system, som så instruerer HSM'en i at signe.

Jeg tror man skal læse det som at "nøglerne kan ikke tilgås direkte", men det er for så vidt også ligegyldigt, hvis de kan bruges til at signere med ville jeg mene. Det betyder dog at den pågældende medarbejder ikke længere ville kunne bruge dem. Så de har nok med vilje valgt "kompromittering" istedet for "misbrug".

Christoffer Kelm Kjeldgaard

Dog sendes kodeordrt ikke - den kommer ikke ud at bruges pc'er, da den bruges at danne de nøgler, som bruges til bl.a. at åbne den private nøgle.

Det er ihvertfald i bedste fald løgn. Koden sendes som challenge-response i JAVA-appletten.

Det du tror der sker, ville kræve at alle brugere hentede alle passwords når de kørte appletten, og det er der ikke nogen der gør, heller ikke Nets.

Christoffer Kelm Kjeldgaard

Dog sendes kodeordrt ikke - den kommer ikke ud at bruges pc'er, da den bruges at danne de nøgler, som bruges til bl.a. at åbne den private nøgle.

Det er ihvertfald i bedste fald løgn. Koden sendes som challenge-response i JAVA-appletten.

Det du tror der sker, ville kræve at alle brugere hentede alle passwords når de kørte appletten, og det er der ikke nogen der gør, heller ikke Nets.

Christoffer Kelm Kjeldgaard

Dog sendes kodeordrt ikke - den kommer ikke ud at bruges pc'er, da den bruges at danne de nøgler, som bruges til bl.a. at åbne den private nøgle.

Det er ihvertfald i bedste fald løgn. Koden sendes som challenge-response i JAVA-appletten.

Det du tror der sker, ville kræve at alle brugere hentede alle passwords når de kørte appletten, og det er der ikke nogen der gør, heller ikke Nets.

Peter Mogensen

Det er ihvertfald i bedste fald løgn. Koden sendes som challenge-response i JAVA-appletten.

Det er vel ikke i konflikt med udsagnet om at "koden" ikke sendes.
Challenge-response har jo netop til formål ikke at transmittere selve koden, men blot et bevis på at man kender den.
Til gengæld betyder det så (*) at modtagere et eller andet sted er nød til at kende koden.

*: Vi ser bort fra asymmetrisk kryptografi og zero-knowledge proofs. Indtil jeg ser virkemåden dokumenteret vil jeg ihvertfald antage at de små korte koder ikke bruges til det. ... men den algoritme er jo nok hemmelig af "sikkerhedsmæssige grunde".

Log ind eller Opret konto for at kommentere