Selv om der jo ikke endnu er præsenteret nogen grund til faktisk at bruge appletten, når det alligevel bare er en single-sign-on løsning man har præsteret, så er det da et skridt på vejen at man tør stå ved sin kode.

Nu mangler det bare, at man fra DanIDs side tør stå ved det overfor samtlige sine brugere. Når man insisterer på at bruge en teknologi, der beder brugeren stole på en - så kan man vel også stole på sine brugere?

Men vi vil heller ikke hjælpe it-kriminelle bare en lille smule, så vi lægger ikke koden ud i det fri

Der er kun en måde man kan have tillid til den og det er at man selv kan verificere at den kode I har "lagt frem" også er den, der kører i ens browser.
Alt andet er et PR-stunt Jette.

Det er ærgerligt, at Børsen ikke også spurgte en anden it-ekspert. Java-appletten er samme teknologi, som netbankerne har brugt i mange år

Jette, du har ikke forstået kritikken.
For det første er det ikke nødvendigt at bruge en Java-applet til dette - det har Jyske Bank vist i praksis i mange år (og nej, jeg køber ikke argumentet om MacOS). Man klarer sig fint med JavaScript.
For det andet, så er problemet i forhold til de banker, der tidligere har brugt en signeret Java-applet at dengang HAVDE MAN ET VALG!!

En "IT-ekspert", der ville give dig ret uden at forholde sig til de 2 argumenter ville være direkte uhæderlig. En IT-ekspert, der benægtede de 2 argumenter som fakta ville være direkte inkompetent.
Så jeg kan ikke se hvad det skulle hjælpe at Børsen havde spurgt andre.

...burde man kunne nå langt med almindelig krypteret webadgang, men her henviser hun til kravene til NemID om at kunne overføre filer som en del af en NemID-beskyttet transaktion.

Det er da ganske givet at der er krav til NemID, der ligger ud over det, som et alm. logon løsning (som f.eks. Jyske Banks) gør, som kræver egentlig java, men så må man tage konsekvensen og offentliggøre kilde-teksten komplet, så der er mulighed for at verificere ikke bare HVEM koden kommer fra, men også at det er den kode, som man er blevet lovet.

Som borger kan jeg ikke se argumentet for at undskylde elendige sikkerhedsbeslutninger med et endnu mere elendigt designvalg.

Jeg tror heller ikke, at DanID har fremstillet kode, der bevidst er bygget til at være en bagdør. Når IT-Politisk Forening har sagt, at det er muligt at misbruge DanIDs Java applet, har foreningen jo ikke dermed sagt, at det er det, DanID gør i dag.

Men kode kan have fejl, der kan sætte andre i stand til at udnytte den - buffer overflows i kode, SQL injections i databaser, osv. Jeg har ikke tilstrækkelig indsigt i Java applets til at vurdere, om f.eks. et buffer overflow vil sætte andre i stand til at eksekvere kode.

Kode kan også skrives om og videreudvikles. Det betyder, at selv om DanID i dag sikkert har en stump kode, der har gennemgået rimelige sikkerhedstests, så forhindrer dette på ingen måde, at den dataansvarlige - staten - forlanger, at DanID reviderer koden, så f.eks. politiet kan kigge med.

At ville skjule kildekoden for ikke at hjælpe hackere er et tegn på, at der er potentielle svagheder, man vil skjule. God sikkerhedssoftware skal være sikkert, selv om alle detaljer om den er kendt. [i]Security by obscurity[/i] er en misforståelse.

Endvidere er JVM passende højniveau til, at man nemt kan rekonstruere læselig kildekode. Derfor er der ikke den store ekstra sikkerhed ved at tilbageholde kildekoden.

Man kan f.eks. sammenligne sikkerheden i IE og Firefox. Kildekoden for IE er hemmelig, mens den er offentlig i Firefox. Men der bliver lige så ofte (eller oftere) lavet angreb gennem sikkerhedshuller i IE som i Firefox. Det har altså ikke hjulpet et døjt at skjule kildekoden.

Hvis DanID har skævet til sikkerhedsstandarden DS484, er der ligefrem KRAV om, at de holder kildekoden skjult. Der står nemlig (af årsager, som jeg mener lugter lidt af lobbyisme) eksplicit i standarden, at det er en sikkerhedsbrist at lade andre læse koden.

Jeg ved desværre ikke, om DanID er certificeret efter DS484 eller ISO27001. Jeg sendte en mail med spørgsmålet i går, men har (rimeligvis) ikke fået svar endnu.

Kære DanID

Problemet med at bruge en java-applet som har fuld adgang til brugerens filer er ikke, at vi mistænker jer for at have listet bagdøre ind i systemet. Jeg tror ikke der er nogen der seriøst mistænker DanID for dette (selvom man kunne påpege at en ondsindet ansat hos jer ville have mulighed for at lave en sådan, det er dog heller ikke det centrale problem).

Problemet er, at NemID skal kunne benyttes af en hel masse forskellige login-sites. Hvis man er vant til at godkende, at NemID skal have fuld adgang til ens filer, er det en snild sag at lave en forfalskning, som giver en ondsindet person fuld adgang til ens computer.

Dette er selvfølgelig ikke et problem for kritiske brugere, men så snart man får lullet personer ind i den tro, at de ukritisk skal acceptere disse pop-ups fra java applets som ligner noget fra NemID, så er det et stort problem.

Ja - det er også et problem. Man skal ikke svine med den slags sikkerhedsadvarsler steder hvor de ikke er nødvendige. Det får kun brugere til at opgive at tage stilling til dem.

Men det konkrete problem er nu mest at man ikke kan have tillid til noget blot ved at tage deres ord for det, hvis man ikke har noget valg.

NemId kan slet ikke fungere uden kørende kode på computeren til at håndtere opgaver som interface til serveren og styre hvad NemId serveren skal signere eller (de)kryptere.

I så tilfælde ville vi have en ren Microsoft Passport / Citrix model hvor du logger ind på serveren som derefter logger dig videre ind uden at have nogen form for sikring af og mod serveren og dem som kontrollerer serveren.

Men faktum er at det er præcis det som vi kender som en Serverside Single SignOn model. Det er den samme sikkerhedsfejl som NemLogin og Borger.dk bygger på via misbrug af SAML og som betyder at ethvert brud og navnlig centrale misbrug skalerer helt ud af kontrol for identifikation et sted kan misbruges til at tilgå alle andre funktioner i borgerens navn.

Men samtidig tjener signeringen til at eliminere borgerens sikkerhed af kommercielle og bureaukratiske styringsinteresser. De vil sikre sig at du ikke kan lave nye nøgler eller styre hvad du bruger DERES nøgle (dvs. borgerens private) til.

Formålet er på den ene side at sikre at du kun kan bruge NemId til transaktioner som DanId har kontrol med og dermed kan både profitere af og undgå udvikler sig i en retning som ikke passer bankkartellet. Det er en anti-innovationsstrategi. På den anden side at sikre at Bureaukratiet kan kontrollere og detailstyre alt, dvs. en overvågningsstrategi med bagdøre til alle private nøgler.

Fokus på debatten i øjeblikket er om Appleten snager unødvendigt eller gør anden skade på computeren. Men man overser at det er det mindste problem. Det store problem er at du ikke har kontrol med hvad Appletten gør og navnlig hvordan sikkerheden skulle fungere for at sikre at NemId blev koblet helt ud af transaktionen og MS Passport modellen blev elimineret.

Hvordan burde det være gjort/hvad er vi nødt til at gøre nu?

Den første handling som enhver borger og retssamfund skulle gøre ville være at generere en Digital Signatur og afvise at den centrale nøgle har nogen suverænitetsværdi overfor 3. part. Dvs. på den ene side afvise at NemId MÅ bruge deres "private" nøgle til at tilgå noget som helst.

Gentager - ingen statslig myndighed som vil påberåbe sig retstatus MÅ acceptere NemId i den nuværende form.

Man betragter den nøgle som NemId har som en "borgerspecifick CA-nøgle" til at certificere borgerens klient-side generede og kontrollerede Digital Signatur.

Det afviser VTU med den begrundelse at det gør borgeren selv til en CA - nej. Det betyder at borgeren kan generere EGNE afledte nøgler som modparten vil vide IKKE er lavet af en CA. Den faktiske årsag til VTUs afvisning er at det vil flytte kontrollen til borgeren.

Her skal vi skelne mellem 3 former for afledte nøgler.

1) Den første type er en algoritmisk afledt nøgle, dvs. at den NemId kontrollerede "private" nøgle bruge til at signere den offentlige nøgle af et klient-side genereret nøglepar. Dermed er vi tættere på det som ville kunne accepteres som en Digital Signatur eller et forsøg på at omgøre de fejl som NemId repræsenterer.

Alle algoritmisk afledte nøgler skal publiceres før brug og borgeren bør starte med at generere et nøglepar som NemId IKKE har adgang til som skal autorisere enhver nøgle som Digital Signatur. Dette vil i praksis eliminere NemIds adgang til at begå identitetstyveri uopdaget.

2) Den anden type er en logisk afledt nøgle, dvs. at borgeren genererer et PGP-nøglepar og signerer den offentlige PGP-nøgledel med den private PGP-nøgledel. Ingen andre end borgerne selv kan i udgangspunktet henføre PGP-nøglen til borgeren.

Men borgeren kan derefter f.eks. bruge en algoritmisk afledte nøgle til at genere et certifikat som sendes modpartsspecifikt krypteret, f.eks. din læge så KUN lægen kan koble den logisk afledte nøgle til den algoritmisk afledte nøgle (bemærk at NemId IKKE må indgå fordi NemId må antages at logge certificeringen).

Den logisk afledte nøgle kan bruges til formålsspecifik authentikering online så services kan fungere uden nogen server kan henføre transaktionen til borgeren.

Det er selve forudsætningen f.eks. for at services kan lægges i cloud. Man får intet ud af at hacke serveren, data kan ikke misbruges uden for kontekst - men alligevel vil lægen vide at brugen af den logisk afledte nøgle er direkte forbundet med den pågældende borger.

Simple transaktioner såsom ren læseadgang og basal kommunikation kræver kun den afledte nøgle, vigtigere transaktioner kræver en algoritmisk afledte nøgle eller digitale signatur igen bl.a. hvis der er usikkerhed om de private nøgler kan være kompromiteret.

3) Den tredje form for afledte nøgle er hvad vi kan kalde semantisk afledte nøgler. Disse kan komme i mange former fordi der er mange forskellige sikkerhedsbehov som hele tiden ændrer sig.

Et eksempel er en Escrow, hvor en algoritmisk afledt nøgle bruges til at etablere Ansvarlighed eller "Betinget Identifikation" istedet for en simpel Logisk afledt nøgle.

I en simpel form kan Escrow-etableres ved at kryptere certifikatet til lægen med en dommers offentlige nøgle. Lægen kan finde ud, hvem Borgeren med den Semantisk Afledte nøgle er, ved at sende det krypterede certifikat til dommeren. Dommeren kan efter at have valideret at betingelsen er opfyldt, etablere den selvsignerede sporbare kobling mellem den Semantisk Afledte Nøgle og en Algoritmisk afledte nøgle. Dvs. en nøgle kan sagtens etablere Ansvarlighed uden at identificere.

Men Semantisk Afledte nøgler kan antage mange former som ikke nødvendigvis forudsætter at borgeren KAN identificeres. F.eks. kan de nyeste former for Blinded Certifikates bruges til overføre validerede data mellem 2 offentlige myndigheder uden at sammenkøre registre. Oplagt til f.eks. validering af straffeattester i forbindelse med anonyme jobansøgninger. Det kan etablere Digital Cash eller sikre betalingsformer etc. etc.

Med de Semantisk afledte nøgler etableres muligheden for at løse applikationernes sikkerhedsproblemer i åbne og interoperable former uden at flytte kontrollen fra Borgeren og dermed svække både serversikkerheden og markedsdannelsen.

For at opsummere: DanIds tilgang giver fuld mening hvis agendaen er at undgå sikkerhed og garantere både den kommercielle og bureaukratiske agenda. Den kræver uendelig tillid til at Nemid ikke misbruger magten, men tilliden er allerede brudt for så vidt angår brugsfunktionen af DanId.

DanId / VTUs agenda kan ses som at fastlåse alle interfaces til DanId INDEN man kan få borgerkontrollerede nøgler indført. Derefter vil legacy i form af de mange millarder som er spildt på fejlimplementeringer forhindre fremadrettede løsninger baseret på afledte nøgler og sikrede services.

Det er åbenlys samfundsskadelig virksomhed, men forudsætter på ingen måde ondsindet Applet-kode eller at DanId misbruger de centralt kontrollerede "private" nøgler førend Bureaukraterne finder det nødvendigt. Det forudsætter kun at kun DanIds autoriserede kode kan køre og styre nøglerne. Det betyder mindre om man kan se indholdet.

Husk på at PBS kender denne strategi til perfektion - det er den samme måde bankerne skovler penge ind ved at eje indløsninsaftalerne på basis af at man blokerer for konkurrence og navnlig innovation såsom at åbne betalingskanalerne.

Kære Philip Munksgaard

"er det en snild sag at lave en forfalskning, som giver en ondsindet person fuld adgang til ens computer."

Nej det er det ikke.

Godt nok har NemID vores certifikat, men vi har ikke deres. Det bliver derfor lidt svært at modificere koden.

I værste tilfælde har NemID tilføjet en angrebsvektor mere - java, men det kunne ligeså godt være din browser som exploites (herunder phishing osv, i en rent html/js løsning).

Nu er jeg ikke DanID - men jeg frister mig til et svar alligevel.

Det at NemID anvendes på flere forskellige sider, giver ikke folk en vane med at skulle godkende adgange i tide og utide.
Set i forhold til den gamle løsning (digital signatur), hvor man skulle acceptere hver eneste udbyder hver gang man besøgte et nyt site, så skal man nu kun acceptere én udbyder ÉN gang.
Det må da være en forbedring ?

At lave en forfalskning, der ligner NemID er nok teknisk muligt, men udfordringen med at signere med den DanIDs certifikat, og derfor udgive sig for at være fra DanID, er næsten umuligt.
Det certifikat er nemlig ikke tilgængeligt.

Så jeg håber du kan forstå - hvorfor jeg ikke kan se DET, som et stort problem.

Hvorfor er der ikke nogen af jer kloge mennesker, der blot henter JAR-filen og analyserer den?

Linket findes i kildekoden :-)

Jeg er altså ikke overbevist om at en signering af applet'en forbedrer sikkerheden, f.eks. teksten: "publisher: DanID A/S" ikke entydig, vha. kyriliske bogstaver kan jeg også skrive "publisher: DаnID А/S".

Det vil ikke umiddelbart være muligt for en bruger at se forskel på de to tekststrenge. Min browser kommer standard med ca. 50 forud godkendte certifikater, mon ikke jeg kunne anskaffe et kode signerings certifikat, som kunne bruges til at signere en vilkårlig applet.

Nu skal du jo lige have et lovligt certifikat - det er normalt ikke noget man bare får ved at smide en email...

Du skal jo typisk bevise hvem du er osv.

Self-signed applets er nok lette at spotte - ikke at det skal holde folk tilbage for acceptere dem ...

Nu har jeg kun een gang fået et certifikat til signering af kode, dengang var det "kun" et spørgsmål om en e-mail, lidt registrering på en web-side og en en bunke dollars. Jeg kan ikke huske hvormange dollars, men dengang syntes jeg at det var en pebret affære.

Hvilke undersøgelser de gjorde i den anden side kan jeg ikke vide, men det kan ikke have været alverden, når man tænker på hvor kort tid der gik fra bestilling til levering.

De fleste har over 100 trusted CA'er i deres browser, og det vil sikkert være muligt at få et certifikat fra en af dem, der kunne forveksles med DanID navnet.

Desværre skal man kunne bevise hvem man er, for at få sådan et certifikat. Chain-of-trust skal jo holdes intakt.

Den enkelte bruger kunne måske snydes med et self-signed certifikat, til at tro at der var tale om en applet fra DanID.

Begge tilfælde er bare en bekræftelse af at phishing er en angrebs vektor, og ikke meget mere end det.
Begge tilfælde er iøvrigt også svære at gennemføre end et tilsvarende angreb mod alternative teknologier, der fungere på tværs af flere platforme). Ikke mindst løsninger helt uden signering.

Hvorfor skulle vi ikke tro at DanID har placeret en bagdør? Det er jo før set at efterretningsvæsner har krævet at der er bagdøre i styresystemer og krypteringer.
Et system der bygger på at vi skal stole på en offentlig myndighed som ikke vil udlevere kildekoden, er ikke et system man bør stole på. Forsigtighedsprincippet siger stol ikke på nogen, heller ikke offentlige myndigheder. Terrorpakke og lømmelpakke tyder jo ikke på at de danske myndigheder har noget problemer med at overskride borgernes retssikkerhed.

Jeg er seriøst ude på dybt vand her, men med hvad jeg ser af reaktioner på facebook.
Hr og Fru Jensen er jo rimelig meget på facebook nu om dage, og ret mange spiller farming mig village what ever jeg spilder min tid. Og de er efterhånden vant til på facebook, bare at ukritisk trykke ok hver gang der kommer en pop up, halvdelen aner jo ikke engang hvad de siger ok til. den anden halvdel er ligeglad.

Jeg kan forestille mig det samme mønster på nettet generalt, altså der kommer en pop up, ok og wupti så har de yahoo, google, messenger, stop my virus scanner tool bars, men den "slukker man jo bare for og aner egentlig ikke hvor de kommer fra, bare se ActiveX, det er jo alle mands ejer, stort set alle der kommer forbi og skal på nettet bliver totalt forvirret fordi den hele tiden siger blurp (Jeg har ikke bare tilladt flash at køre medmindre jeg giver den lov).

Nu er det applets, men hip som haps. Folk vil fremad i systemet og videre, de klikker da bare ok til whatever der måtte dukke op, så phishing er da en risiko der vil noget. Hvis det bare ligner noget offentligt nok så bare have login'en til at "fejle", stalle og samle papkoder, resten har de jo trykket.

Det bliver da rigtig smart når den bliver frigivet til at Dansk tips/lotto og diverse andre "forretninger" kan stoppe løsningen på deres sider.

Tænker bare lav en side med et eller andet der på en overbevisende måde diregere brugen til at skulle bruge NemID, men istedet så smaske sit eget efter dem også eller phise dem ad den vinkel.

Men det er jo bare en angrebsvinkel, jeg er da sikker på at der er nogle bremser for at det er muligt, ellers ville man vel allerede nu have set de første "sjove" identitets tømninger. Hvad skrev de 145.000 bruger har nemID nu?

Jeg kan sagtens følge din bekymring, om at folk ukritisk klikker OK til hvad som helst på nettet.
Studier fra blandt andet DTU, viser da også at folk ganske vist ved hvad de bør gøre, men opfører sig ganske anderledes.

Hvis en ondsindet programmør vil misbruge dette til at aflure folks NemID, skal han samtidig kunne generere en gyldig OTP-challenge.

For mig at se kan det kun ske gennem et helt ufatteligt held eller et realtime angreb, som vi ikke rigtigt har set noget til endnu. I det mindste ikke på den måde, som også indeholder en hel del begrænsninger.

På https://www.nemid.nu/borger/fordele_med_nemid/ fremgår det:

Du kan også tage NemID med dig og bruge den på andre computere. Så længe du bare husker dit personlige bruger-id, din adgangskode og dit nøglekort, så kan du bruge NemID fra de fleste computere med internetforbindelse. For eksempel kan du bruge NemID på din pc på arbejde om dagen, på din mac derhjemme om aftenen eller på en internet-café når du er ude at rejse.

Altså burde jeg trygt kunne benytte mit nem-id fra en hvilken som helst pc.

Men hvis jeg skal acceptere at nem-id skriver på harddisken er jeg ikke tryg ved at benytte den "på en internet-café når du er ude at rejse" og dermed få efterladt et fingerprint måske/måske-ikke indeholdende komprimenterende data..

DanID bør lave en løsning der ikke kræver adgang til harddisken medmindre man benytter en upload funktion eller lign. I forbindelse med upload kan man så præsenteres for en accept af de tilgår harddisken...

Jeg har kigget lidt rundt og ledt flere steder, men jeg har ikke kunnet finde svar på, hvorfor DanID har valgt at bruge en java-applet, når de i princippet kunne vælge at lave en https-løsning istedet.

Nogen der kender svaret?

Jeg kan ikke svare på hvorfor DanId ikke har valgt en HTTPS løsning (altså en HTML og Javascript løsning i en TLS krypteret forbindelse)

HTTPS løsninger kan ikke signeres, sikre ikke WYSIWYS (What you see is what you sign) i samme grad, kan ikke lave klientside validering af certifikater, kan ikke have samme grad af tamper-sikring og kan derfor også manipuleres og forfalskes med større lethed.

@Thomas

Jeg ved ikke helt hvor jeg skal starte, men samtlige af dine bemærkninger om HTTPS er forkerte!

HTTPS er HTTP wrappet i SSL/TLS. Med SSL kan lave klientside validering af certifikater og man kan sikre data-integriteten af data sendt over SSL. Der gælder dermed også, at forbindelsen er tamper-resistent. I public key kryptografi gælder desuden, at krypterede data implicit er signerede.

Til orienteringsmødet i Århus forstod jeg det sådan at "obfuscation" var et af nøglekriterierne under udvikling af NemID applet'en.

Derfor giver det ikke meget mening at decompile class-filerne.

Jeg bruger MacOS, og her skriver applet'en en fil ~/danid.log, der opdateres hver gang man logger ind. Jeg må indrømme at jeg er noget overrasket over at DanID mener at det skulle være nødvendigt at skrive i mit home-dir på min computer for at jeg kan logge ind på en hjemmeside. Jeg synes det kræver ansvarlighed fra deres side når de beder om skriveadgang til hele computeren, men at skrive i folks home-dir virker ikke som en fornuftig måde at forvalte den på.

Filen indeholder dato og tidspunkt for hvornår der logges ind klar tekst plus en masse andet der ikke er direkte læseligt. Man kan undgå at der skrives i filen ved at fjerne skriverettighederne, og det er stadig muligt at logge ind med NemID.

Jeg vil klart opfordre til at der udvikles en alm HTML baseret login løsning på samme måde som f.eks. Jyske Bank. Folk der har brug for at uploade filer krypteret kan så installere applet'en, men der er bestemt ikke noget jeg har lyst til - hvis jeg kunne blive fri.

Det er nok mig, der er lidt tungnem, men hvorfor skulle upload af filer kræve brug af en applet?

Kunne det ikke ske på "ordinær" vis, på en krypteret https (ssl/tls) forbindelse, og en [Browse...] knap.
Er det ikke kun hvis man ønsker at give udvidede upload muligheder (med valg af mange filer e.lign) at det kan blive nødvendigt med en applet? og selv i de tilfælde kan lidt dhtml løse meget (som fx GMail gør det i dag).

@Stephan

Jeg tror ikke der længere er nogen af Version2's læsere der er i tvivl om, at du er en indædt modstander af nemid's arkitektur, og potentielle sikkerhedsbrister. Men er der nogen grund til at bruge enhver artikel der vedrører NemID til at gentage den samme modstand igen og igen? Selv når artiklen vedrører en specifik detalje om implementationen (i dette tilfælde brug af en applet). Det afsporer, efter min mening, ofte diskussionen fra artiklens primære emne.

Morten

Rammer du ikke lidt ved siden af?

Jeg er kommet med et indlæg omkring hvor jeg faktisk argumenter mod kritikken af NemId. Appletten flytter kontrol ud mod borgeren som ellers ville skulle ligge på serveren og forværre modellen.

Men siger samtidig at Appletten misbruges til at fastlåse uanset om den "snager" på harddisken. Dvs. reelt er jeg ret uenig i den fremførte kritik i denne artikel og mener nærmest at den rammer ved siden af og langt under målet.

Samtidig fremfører jeg detaljer i den nøglehåndtering om en klient skal kunne håndtere og som ikke kan klares serverside.

Ellers har jeg en gang pointeret at der ikke er nogen grund til at vente på en passwordgenerater som "nøglekortet" er reduceret til.

Jeg ved ikke hvad du synes jeg gentager. Bortset fra selvfølgelig at man skal følge pengene og magtens samt fokusere på hvordan det skader samfundet.

Desværre skal man kunne bevise hvem man er, for at få sådan et certifikat. Chain-of-trust skal jo holdes intakt.

Eh, nej man skal (oftest) ikke. Kun hvis man skal bruge et extended validation (EV) certifikat.

danid.dk bruger ikke en EV certifikat, men det gør nemid.dk, der forwarder til sikker-adgang.dk.

• Men i praksis er det ligegyldigt, så længe at der ikke advares imod non-EV certifikater.

Jeg kan forstå din tolkning, når nu jeg læser hvad jeg selv skrev.

Det jeg mente var at der ikke findes et clientside certifikat, som der kan valideres af serveren. Altså en validering af begge ender er hvem de siger de er.

Indhold sendt over en HTTPS kan i PKC betragtes som signeret, det bliver svært at være uenig i det. Men det er ikke en signering af indholdet, som kan bruges til at validere at der ikke er blevet ændret i data, sådan som det f.eks er sket for en række banker de sidste par år.
Derfor er https forbindelse da absolut tamper-resistent, men ikke i samme grad som løsningen med en applet.

Og der er derfor stadig udfordringen omkring at sikre at vi rent faktisk ser det som service udbyderen tror de har vist os, når vi skal signere.

@Thomas

Dine bemærkninger om HTTPS (HTTP i SSL) er stadig helt forkerte.

SSL understøtter public key- eller to-vejs -kryptering hvor serveren sender et certifikat til klienten, og klienten sender et certifikat til serveren, og begge sider kan afgøre om de ønsker at truste modpartens certifikat. Det hedder Mutual Authentication eller Client-authenticated SSL-handshake og er understøttet i alle SSL-implementeringer på både server og klient-side.

Det er i øvrigt også SSL der bliver brugt i kommunikationen mellem appletten og serveren. Indholdet i en SSL-transmission, f.eks. HTTP, har ingen betydning for sikkerheden af transmissionen.

Min største anke mod NemID er netop at de ikke benytter klient-side certifikater i løsningen, da det er den eneste måde at sikre identitet, autencitet, integritet og fortrolighed i hele transmissionen mellem borger og myndighed eller fra borger til borger - såfremt privatnøglen er under borgerens fulde kontrol, som anført i Lov om elektroniske signaturer.