[Openstandaarden] e-id: wishlist

[Wouter Verhelst]

On Mon, Jun 20, 2005 at 10:53:52PM +0200, Kristoff Bonne wrote:
> Uiteindelijk, men moet een beetje realistisch blijven. Veranderingen aan 
> de eid's zelf; dat is simpelweg een "no-go".

Hoezo?

Men is zelf al aan het praten over updates die er zouden doorkomen. Wat
zou dat dan niet kunnen?

> Buiten moest de overheid verplicht zou worden door -bv- een rechtbank
> denk ik niet dat er ook maar de geringste kans is dat er iets aan de
> eid-kaarten gaat veranderen.

Als er degelijke argumenten zijn waarom een bepaalde manier om iets te
doen, beter zou zijn, dan kan ik me niet voorstellen dat men dat niet
zou implementeren.

> Dan is de meest logische stap het toestel dat het dichts bij de kaart 
> staat en daar de nodige "filtering" toe-te-passen  en dat is de firmware 
> van kaartlezer.

Het lijkt me _verschrikkelijk_ onwaarschijnlijk dat je dat erdoor
krijgt. SmartCard-interfaces worden voor veel meer dan alleen de
eID-kaarten gemaakt; bepaalde functionaliteit in de firmware verplichten
is even zinvol als een wet die voertuigen met minder dan vier wielen
gaat verbieden op een autosnelweg -- sure, het is veiliger, maar er zijn
zeker ook redenen om met twee wielen op de autosnelweg te gaan.

> Die heeft uiteindelijk toch het voordeel dat die -in vergelijking met
> libraries in de computer zelf- niet te "bypassen" is en veel meer
> immuun is tegen aanvallen van buitenuit.

Denk je dat?

Wie houdt mij tegen om een smartcard-lezer met correcte firmware te
kopen, het ding open te schroeven, één en ander zelf aan te passen, en
te doen alsof er niks gebeurd is?

Of desnoods zelf een smartcard-lezer te fabriceren op zo'n manier dat je
hem niet kunt onderscheiden van een echte, maar dan uiteraard zonder die
lastige firmware?

Hardware is écht niet veiliger dan software. Het enige waar je zeker
over kunt zijn, is het kaartje zelf; alles wat daarbuiten is kan door
een kundig persoon aangepast worden.

> Het lijkt mij heel goed praktisch uitvoerbaar dat er nu een aantal 
> "eisen" gesteld worden in hoe een eid kaartlezer (en vooral voor die 
> kaartlezers die bedoeld zijn om gebruikt te worden door het grote 
> publiek) zich moeten gedragen (bv. dat die VOOR het opvragen van de 
> informatie uit de kaart aan de gebruiker moeten melden welke informatie 
> gaat uitgelezen worden;

Hoe gaat zo'n kaartlezer dat doen? Mijn kaartlezer heeft twee manieren
om met de gebruiker te communiceren: een groen ledje dat aan en uit kan
en een USB-kabel. Ik denk ook dat de meeste kaartlezers die "voor het
grote publiek" bedoeld zijn, er min of meer zo gaan uitzien. Mogelijk
(waarschijnlijk) komen er kaartlezers met geen ledje.

Vergeet ook niet dat extra firmware gelijk staat aan extra kosten, dus
hogere prijzen. Ik vrees dat "het grote publiek" daar niet echt mee kan
lachen. En vermits een gemiddelde kaartlezer niet veel meer kan dan
bytes van de PC aan de kaart doorgeven en vice versa, lijkt het me vrij
waarschijnlijk dat het implementeren van voldoende intelligentie om te
begrijpen dat het hier om een eID-kaart gaat, die dingen naar de
buitenwereld weergeeft in een PKCS#11-achtig formaat, waarvan de
adresgegevens in een bestand met een bepaalde naam staan, en waarbij jij
dus zeker wilt zijn dat de gebruiker akkoord gaat met het lezen ervan,
een serieuze hoop extra intelligentie en dus _flink_ hogere kosten
betekent.

Oh, sorry -- je had het over de certificaten. Dan gaat het dus naast
bovenstaande ook nog over PKCS#15, en moet de kaartlezer het verschil
begrijpen tussen een signature-operatie en een gewoon uitlezen van de
key. Flink wat werk.

No offense, maar ik vrees dat je dringend een reality-check nodig hebt,
en wat documentatie moet gaan lezen. De dingen die je hier voorstelt
raken kant nog wal.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond