[Openstandaarden] [OT] e-id (nog eens)

[Sven Putteneers]

On Fri, 17 Jun 2005 at 12:33:00 +0200, cobaco (aka Bart Cornelis)(cobaco at linux.be) wrote:
> On Friday 17 June 2005 12:09, Sven Putteneers wrote:
> > On Fri, 17 Jun 2005 at 11:42:53 +0200, cobaco (aka Bart Cornelis)
> (cobaco at linux.be) wrote:
> >
> > De overheid (of eigelijk Zetes) geeft de kaart een commando "maak een
> > keypair aan" 
> Wat houdt Zetes (of een werknemer ervan) tegen om dit commando te draaien op 
> een JVM niet op de kaart, een kopie te maken, en pas vervolgens de private 
> key op de kaart te zetten? Lijkt me in eerste instantie perfect mogelijk.

Nope, aangezien je op geen enkele manier aan het stuk geheugen op de
kaart kunt waar je private keys zijn opgeslagen. Er bestaat geen
commando "write private key" of zo om naar de kaart te sturen (en dit
kan nagegaan worden door de software die op de kaart komt te auditen).

> Waarom is het Zetes die de private key aanmaakt? Waarom wordt dit niet aan 
> de burger overgelaten _als_ deze die nodig heeft, waarna hij die kan laten 
> ondertekenen op het gemeentehuis? 

1 grote reden: digitale ongeletterdheid. De mensen op deze mailinglijst
en een aantal anderen kennen de implicaties van public en private keys
en weten hoe hier (op een correcte manier) mee om te springen, maar hoe
ga je een grootmoeder die niet eens haar video zelf kan programmeren de
basisbeginselen uitleggen van PKI?

De manier waarop de kaart geïmplementeerd is, is sowieso een afweging
tussen gebruiksgemak en privacy-aspecten.
Ik denk dat de meeste abonnees van deze lijst de weegschaal het liefst
zien doorslaan naar de privacy-kant (waaronder ikzelf), maar er moet ook
rekening gehouden worden met het overgrote deel van de bevolking
waarvoor het gebruikersgemak primeert.

Om een afweging te maken tussen die twee gaan er altijd opofferingen
gemaakt moeten worden (en wat mij betreft liever aan de kant van
gebruiksgemak dan aan de kant van bescherming van privacy).

Het enige doenbare voorstel dat ik hier heb zien passeren, is dat van
Kristof Bonne. Voor elke categorie informatie info die men van je kaart
wil query'en, moet je expliciet toestemming geven.
Beter zou nog zijn dat dit optioneel gemaakt wordt, zodat mensen met een
gezond wantrouwen voor elke transactie toestemming moeten geven, maar
mensen die eerder gebruiksgemak willen, voor bijvoorbeeld het opvragen
van hun naam en geslacht dit zonder expliciete handeling (buiten hun
kaart in de lezer te steken) kunnen laten gebeuren.

Ook een logboekje (zoals bij Proton), een ander voorstel dat ik hier heb
gelezen, zou kunnen helpen met het nagaan van hoe men met je gegevens
omspringt (eigelijk: welke gegevens men juist heeft opgevraagd).
Als deze log eventueel gecombineerd wordt met een centraal meldpunt voor
misbruiken (als een discotheek bijv. niet alleen je leeftijd checkt,
maar ook je adres en rijksregisternummer), kan dit alleen nog maar
helpen om (vooral prive-zaken) aan te sporen zich te gedragen.

> > De private key valt op geen enkele manier van de kaart af te krijgen,
> > die zit namelijk in een stukje geheugen dat niet aan te spreken valt van
> > 'buitenaf'.
> dat is dan goed _eens_ de key op de kaart staat.

Nogmaals, de private key kan op geen enkele manier aangesproken worden
van buiten de kaart (zowel om te lezen als om te schrijven).
Het is de kaart _zelf_ die de sleutelparen genereert, zonder enige hulp van
buitenaf (nuja, de spanning om de chip te laten werken komt van een
externe bron ;) ).

> > Mja, als het wettelijk verplicht is, denk ik niet dat je de keuze hebt
> > om je digitale handtekening niet te gebruiken...
> maar het is wettelijk niet verplicht, je kunt de certificaten laten 
> uitschakelen (opt-out i.p.v. opt-in op zich al fout IMO)

Dit is weer gebruiksgemak. De privacy-bezorgden kunnen dit laten
uitschakelen, terwijl het grote publiek gewoon wordt aan het idee van
handtekeningen zetten met een chipkaart.
En om iets te ondertekenen met je eID, moet je sowieso je pincode
ingeven. Dus er zit een beveiligingslaag bovenop de keypairs die op je
kaart staan.

> probleem is dat iedereen die mijn private key heeft dingen in mijn naam kan 
> ondertekenen

Dan moeten ze eerst je private key bemachtigen (maar zie ook hieronder).

> aangezien zo'n handtekening cryptografisch veilig is wordt daar een hoge 
> waarde aan toegekend.

Dit slaagt op niet veel... Een manuele handtekening is niet
cryptografisch veilig (ik denk dat we daar van uit mogen gaan), maar
daar wordt ook een hoge waarde aan toegekend. Miljoenendeals worden
bezegeld met een krabbeltje op papier :)

> -> Als ik niet kan garanderen dat ik de enige ben die de private key heeft
> is het potentieel voor misbruik _veel_ te groot (en dat kan mijns inziens 
> enkel als ik diegene ben die de private key aanmaak) 

Ik denk dat je redenering hier niet klopt... Als NIEMAND (ook jijzelf
niet), op geen _enkele_ manier aan je private key kan en enkel jijzelf
er dingen mee kan ondertekenen (dat enkel jijzelf dit kan, wordt
gewaarborgd door je PIN), dan heb je die garantie dat je de enige bent
die je private key kan gebruiken.

En of voldaan is aan de voorwaarde "niemand kan op geen enkele manier
aan je private key", is een kwestie van het auditen van het
productieproces van de eID...

Weet jij wie er allemaal toegang heeft tot je analoge handtekening? Je
bank, je kredietkaart-maatschappij, de kassajuffrouw die je
gehandtekende cheque in ontvangst genomen heeft, het bedrijf waar je
werkt (ondertekend contract), de overheid, ... (deze lijst gaat nog lang
voort).

Voor je private key is het enige mogelijke "gat" de overheid en Zetes,
bij het aanmaken van je kaart en dit wordt ontkracht door de audits die
zijn uitgevoerd (als een audit zou uitwijzen dat er een mogelijkheid is
om met de private keys op je kaart te knoeien, zou de kaart gewoon niet
in productie zijn gegaan).

Groeten,
Sven


-- 
Encrypted mail preferred. As of Jan 27th 2005, all outgoing mail is signed.
GPG keyID: 0x66A13305
GPG key fingerprint: 5B8C 97A2 20C4 E578 CDEB  71C9 23CA 0681 66A1 3305
GPG key URL: http://fenix.cmi.ua.ac.be/~p005742/gpg_pubkey.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://openstandaarden.be/pipermail/openstandaarden/attachments/20050617/7aa8314e/attachment-0003.pgp