DanID retter ny fejl i NemID

Hubert (50) skrev:

#48

Jeg har intet problem med at du mener min påstand er useriøs. Det gør du bare det flytter intet...

Jeg hverken må eller vil tale om den specifikke løsning. Jeg kan blot igen henvise til svaret fra DanID der viser at der er mulighed for at omgå sikkerheden. Hvorvidt det er let eller ej er ikke så vigtigt. Det vigtige vil altid være at det er muligt med den løsning man har valgt særligt når der er rig mulighed for løsninger der ikke har denne svaghed.

Et designvalg der offentligt er beskrevet og følger normal praksis for lignende institutioner har jeg svært ved at kalde 'en bagdør'.

Men, lad mig høre om de rige muligheder. Givet vi forbrugere selv skal generere og opbevare vores private nøgler (en løsning jeg selv ville foretrække; men jeg er efter dig pga dine tendentiøse påstande).

Et alternativ er en device (f.eks et chip-kort) der kan generere et rsa-nøglepar og signere data. Der skal stadig være trust til hardwaren og embeddet software. Dernæst skal nøgleparret certificeres, så der skal genereres et request - af trusted software selvfølgelig, som skal behandles af en CA, hvis nøgler - og her bliver det rigtig sjovt - med stor sandsynlighed beskyttes af HSM'er på samme måde, som du kalder 'med en bagdør'. Ville VeriSign kunne holde til at skulle sige: "Ups, vores HSM er slidt op og vi har ingen mulighed for at oprette en matchende master-nøgle på nyt udstyr, sååååå, drop lige al PKI indtil alle rod-certifikater er skiftet ud..."?

Derudover, så er der problemet med kommunikation mellem en webside og sådan et device. Hvilke OS'er ryger først pga. bøvl med drivere mons tro?

Anyways, jeg siger ikke, at alternativet ikke er muligt (for det er det: https://www.luxtrust.lu/homepublic/none/homepublic... eller at alternativet ikke er ønskeligt (for det er det IMO); men jeg tror ikke Hr og Fru Jensen kan kaperere det. Jeg ser den nuværende løsning som sikkerhedsmæssig 'god nok' men langt vigtigere simpel nok til at den bliver meget udbredt og dermed får en oplærende effekt.

Pally (51) skrev:

Et designvalg der offentligt er beskrevet og følger normal praksis for lignende institutioner har jeg svært ved at kalde 'en bagdør'.

Offentlig gjort da man blev spurgt... Jeg kan ikke finde den selv samme information på deres hjemmeside.

Men, lad mig høre om de rige muligheder. Givet vi forbrugere selv skal generere og opbevare vores private nøgler (en løsning jeg selv ville foretrække; men jeg er efter dig pga dine tendentiøse påstande).

Grunden til at jeg skrev at hele side 3 var spændende læsning var at der var beskrevet en anden løsning der ikke giver samme muligheder for misbrug af vores private nøgler.

Et alternativ er en device (f.eks et chip-kort) der kan generere et rsa-nøglepar og signere data. Der skal stadig være trust til hardwaren og embeddet software. Dernæst skal nøgleparret certificeres, så der skal genereres et request - af trusted software selvfølgelig, som skal behandles af en CA, hvis nøgler - og her bliver det rigtig sjovt - med stor sandsynlighed beskyttes af HSM'er på samme måde, som du kalder 'med en bagdør'. Ville VeriSign kunne holde til at skulle sige: "Ups, vores HSM er slidt op og vi har ingen mulighed for at oprette en matchende master-nøgle på nyt udstyr, sååååå, drop lige al PKI indtil alle rod-certifikater er skiftet ud..."?

Jeg ser intet problem i at min offentlige nøgle er gemt i HSM. Men du vil måske fortælle hvordan du mener det giver samme misbrugs muligheder?
Hele halløjet med at HSM'en bliver slidt ned er vel lidt fjollet at bringe op som argument for den nuværende løsning når den også benytter sig af HSM?

Derudover, så er der problemet med kommunikation mellem en webside og sådan et device. Hvilke OS'er ryger først pga. bøvl med drivere mons tro?

Det bliver os der bruger ikke 'mainstream' OS' der mærker problemerne først. Men jeg har så ikke testet nemid på mine bsd maskiner så jeg ved faktisk ikke om det fungerer uden problemer der.

Anyways, jeg siger ikke, at alternativet ikke er muligt (for det er det: https://www.luxtrust.lu/homepublic/none/homepublic... eller at alternativet ikke er ønskeligt (for det er det IMO); men jeg tror ikke Hr og Fru Jensen kan kaperere det. Jeg ser den nuværende løsning som sikkerhedsmæssig 'god nok' men langt vigtigere simpel nok til at den bliver meget udbredt og dermed får en oplærende effekt.

Hvis hr og fru frikadelle skal sætte standarden kommer vi sgu nok aldrig videre. Vi bliver nok ikke enige om hvorvidt den nuværende løsning er god nok sikkerhedsmæssigt så fred være med det.

Hubert (52) skrev:

Et alternativ er en device (f.eks et chip-kort) der kan generere et rsa-nøglepar og signere data. Der skal stadig være trust til hardwaren og embeddet software. Dernæst skal nøgleparret certificeres, så der skal genereres et request - af trusted software selvfølgelig, som skal behandles af en CA, hvis nøgler - og her bliver det rigtig sjovt - med stor sandsynlighed beskyttes af HSM'er på samme måde, som du kalder 'med en bagdør'. Ville VeriSign kunne holde til at skulle sige: "Ups, vores HSM er slidt op og vi har ingen mulighed for at oprette en matchende master-nøgle på nyt udstyr, sååååå, drop lige al PKI indtil alle rod-certifikater er skiftet ud..."?

Jeg ser intet problem i at min offentlige nøgle er gemt i HSM. Men du vil måske fortælle hvordan du mener det giver samme misbrugs muligheder?
Hele halløjet med at HSM'en bliver slidt ned er vel lidt fjollet at bringe op som argument for den nuværende løsning når den også benytter sig af HSM?

Jeg tror du har misforstået mig (og indrømmet, jeg fik det skrevet meget indforstået): den offentlige nøgle er ... offentlig og skal derfor ikke gemmes i en HSM - det er spild af plads.
Men i et PKI system er der ikke megen idé i, at du sikrer din private nøgle, hvis ikke CA'en som certificerer din nøgle sikrer deres private nøgler mindst lige så godt. CA'en i dette tilfælde vil være DanID. Så SELV OM du selv genererer og opbevarer din private nøgle, så skal du STADIG have trust til din CA.

Problematikken omkring nedslidte HSM'er er yderst relevant i og med, der skal tages stilling i løsningens sikkerhedsdesign om et crash medfører tabt af alle nøgler (unrecoverable) eller etablering af en ny HSM med samme master nøgle (recoverable). Det adskiller sig ikke fra beskyttelse af pin-koder: vil det virke professionelt hvis ALLE danskere skulle have udstedt nye dankort pga en hardware-fejl? Og inden der svares, skal det erindres at ingen gamle dankort ville virke i perioden fra crash til nye kort er bestilt, produceret, regisreret og leveret til 3 mio danskere.

Pally (53) skrev:

Jeg tror du har misforstået mig (og indrømmet, jeg fik det skrevet meget indforstået): den offentlige nøgle er ... offentlig og skal derfor ikke gemmes i en HSM - det er spild af plads.
Men i et PKI system er der ikke megen idé i, at du sikrer din private nøgle, hvis ikke CA'en som certificerer din nøgle sikrer deres private nøgler mindst lige så godt. CA'en i dette tilfælde vil være DanID. Så SELV OM du selv genererer og opbevarer din private nøgle, så skal du STADIG have trust til din CA.

Jamen så giver det også mere mening. Jeg kunne ikke lige forstå hvorfor det skulle være nødvendigt med et så højt niveau af sikkerhed omkring den offentlige nøgle.

Problematikken omkring nedslidte HSM'er er yderst relevant i og med, der skal tages stilling i løsningens sikkerhedsdesign om et crash medfører tabt af alle nøgler (unrecoverable) eller etablering af en ny HSM med samme master nøgle (recoverable). Det adskiller sig ikke fra beskyttelse af pin-koder: vil det virke professionelt hvis ALLE danskere skulle have udstedt nye dankort pga en hardware-fejl? Og inden der svares, skal det erindres at ingen gamle dankort ville virke i perioden fra crash til nye kort er bestilt, produceret, regisreret og leveret til 3 mio danskere.

Nej selvfølgelig er det ikke heldigt hvis alle skal have nyt dankort. Men jeg synes du igen overser at vi har samme problem stilling med nemid. Her er det bare vores private nøgler der er tale om så fordi det kan ske uden vores viden er det ikke noget problem? :)