[Openstandaarden] verslag meeting eID 2005-02-26 Brussel

Wed Mar 2 11:36:52 CET 2005

On Wednesday 02 March 2005 06:14, Peter Strickx wrote:
> Bart,
>
> Vandaag laat de API dit niet toe. Bij FEDICT zijn we ons zeker bewust
> dat we sommige informatie op de kaart beter moeten beschermen 
:-)

> maar we willen ook de kaart niet zo sterk beveiligen dat ze 'onbruikbaar'
> wordt 

'niet zo sterk beveiligen dat ze onbruikbaar wordt' en 'totaal geen 
bescherming van de data' zijn naar mijn mening toch wel heel verschillende 
dingen. Momenteel is de eid wat mij betreft 'te slecht beveiligt zodat het 
onbruikbaar wordt'

> (bvb soms willen we wel dat toepassingen de kaart gebruken om 
> voor-invulling van identiteitsinformatie te doen - bvb bij aanvragen
> van attesten, opstellen van proces-verbaal, etc...) . De vraag wordt
> dan "hoe kunnen we op een pragmatische manier toegang geven tot de
> identiteitsgegevens aan 'goede' toepassingen ?"

de eerste vraag die je je bij dit soort toepassingen moet stellen is:
  'Hoe kan dit misbruikt worden?'  
als ik naar de huidige toestand kijk is mijn reactie 'Veel te 
makkelijk' (aangezien er blijkbaar  geen enkele technische bescherming 
ingebouwd is) en dat maakt het ding wat mij betreft een no-go (politie, 
gemeentehuis zijn wat mij betreft dus het enige waar dat ding voor gebruikt 
zal worden, en dan nog alleen als het ook echt moet)

> Een md5 (of beter nog SHA-1 of SHA-256) hash heeft maar zin bij
> verficatie van gegevens indien je de hash kan vergelijken.
is er een bepaalde reden waarom de vergelijking niet door de smart-card 
gedaan kan worden?

> Ander probleem dat dan opduikt is de aanwezigheid van het
> Rijksregisternummer in het certificaat. Hieruit kan persoonlijke
> informatie worden afgeleid (geboortedatum, geslacht). Het zou
> misschien beter zijn op termijn hier het rijksregisternummer te
> vervangen door een hash zodat er geen persoonlijke informatie uit het
> 'unieke' nummer kan afgeleid worden. 

> De 'echte' uitdaging bestaat erin 
> om bedrijven te verbieden informatie op te slaan op basis van dat
> unieke nummer (en zo eventueel later informatie uit te wisselen rond
> personen om 'profielen' aan te maken die kunnen gebrukt worden bij
> verkoop/marketing).

Dat kun je bedrijven in België (mogelijk Europa) wel verbieden maar hoe ga 
je (zonder een technische bescherming) voorkomen dat bijvoorbeeld de US al 
die gegevens overneemt, als je daar van het vliegtuig afstapt? Dit wordt al 
helemaal wankel als er ooit biometrische data op zou komen staan (goed 
momenteel niet het geval). 

Afgezien daarvan is het probleem dat eens er 1 rotte appel met data aan de 
haal gaat, je de controle over de data ook voor goed kwijt bent. Gegeven de 
regelmatige nieuwsartikelen over bedrijven wiens database gekraakt wordt 
(ondanks op z'n minst sommige, soms uitgebreide veiligheidsmaatregelen) om 
aan data te komen. Kun je er denk ik van verzekert zijn dat misbruik zeker 
zal optreden als er geen inherente beveiliging is om dit te voorkomen

> Maar wat doe je dan met documenten die je ondertekend hebt met een
> digitale handtekening ? Dan moet je het 'handtekening'-certificaat
> opslaan (waarin zich hetzelfde unieke nummer bevindt).
Da's dus een duidelijke reden waarom de eid IMHO in de huidige toestand niet 
voldoet. Dat uit een certifikaat geen persoonlijke gegevens afgeleid kunnen 
worden is IMO een basisvereiste. Dat een certifikaat het 
rijksregisternummer bevat is bijgevolg niet-aanvaardbaar.

> De e-ID is nog geen perfecte oplossing maar ik betwijfel dat deze
> vandaag bestaat en op dezelfde grote schaal is geimplementeerd. 
het is net de grote schaal van een oplossing zonder data-protectie waar ik 
mij zorgen om maak. deze grote schaal maakt namelijk dat je potentieel veel 
winst uit misbruik haalt. Waardoor misbruik dus meer waarschijnlijk wordt.

> Laat ons het gebruik stimuleren en terwijl kijken naar oplossingen om de
> privacy nog te verbeteren zonder het gebruik te bemoeilijken.
zoals ik boven al zei eens je de controle over je persoonsgegevens verliest 
kun je deze onmogelijk weer terug krijgen. Gegeven dat moet je beginnen met 
een oplossing die je data beschermt, de beveiliging achteraf toevoegen is 
"de put dichten als het kalf verdronken is".

als er technisch nog geen oplossing is de bescherming bied van je 
persoonsgegevens dan is het eenvoudig weg te vroeg om een eid uit te 
rollen.
-- 
Cheers, cobaco (aka Bart Cornelis)

1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
    format mails to a low priority folder (they're mainly spam)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://openstandaarden.be/pipermail/openstandaarden/attachments/20050302/11521c9a/attachment-0003.pgp