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

[Peter Vandenabeele]

On Sun, Mar 06, 2005 at 10:38:55PM +0100, Sander Devrieze wrote:
> Op zondag 6 maart 2005 21:23, schreef Peter Vandenabeele:
> <snip>
> > Multi-user chat (op chat rooms dus, niet in 1-on-1 chat met op voorhand
> > bekende personen) is IMO voor volwassenen, en a fortiori voor kids, een
> > van de toepassingen waar je in eerste instantie anonimiteit wenst te
> > gebruiken als bescherming van je privacy en soms zelfs van je fysische
...
> Ge ziet het een beetje verkeerd denk ik. 

Wel, als iedereen anders een veilige implementatie in gedachten had, en
ik de enige was die nog niet mee was, dan heb je gelijk. Maar misschien
was dat niet zo en dan heb ik reden om aan de bel te trekken.

> Die chatruimtes zouden zo werken:
> 1) kamer enkel toegankelijk voor personen jonger dan X aantal jaar.
> 2) om die kamer te betreden moet de client van de gebruiker contact opnemen 
                                      ^^^^^^^^^^^^^^^^^^^^^^^
				      referentie [A], zie verder
> met een eID-server van de overheid.
> 3) die overheidsserver stuurt dan een bericht naar de server met de 
> chatruimte. Bijvoorbeeld: "ok, deze persoon met bijnaam Z die op uw 
> chatruimte Y wilt aanmelden is idd jonger dan X jaar: laat hem/haar dus maar 
> binnen" (of niet)
> 4) maw: de identiteit voor de persoon blijft nog steeds anoniem voor de andere 
> chatters en voor diegene die de chatruimte aanbiedt.

...

> Lees eens http://mail.jabber.org/pipermail/standards-jig/2004-July/005804.html 
> voor meer voorbeelden. 

Interessante link. Gelijkaardige vraagstukken in financial trading worden daar 
professioneel besproken.  Er wordt wel uitgegaan van veilige clients, als ik het 
goed begrijp. En alleen de humans in het scenario worden als "malicious" beschouwd
(wel het zijn ook traders en analysten ;-) [joke !]

> <snip>
> > Een trusted server die mijn kaart mag benaderen is IMHO alleen:
> > * een server van de overheid
> > * een server die ik met SSL over IP benader, omdat ik via dns en whois
> >   wel weet wie dat IP adres beheert (als de lokale interface tussen
> >   de kaart en de IP verbinding veilig is ... zou de SSL link vanop de
> >   kaart zelf kunnen komen als de bandbreedte klein genoeg is ??)
> > * een server van een vriend, mijn werk, de dokter, de mutualiteit, ...
> > * elke server waarvan het helemaal geen kwaad kan dat men weet wie je
> >   bent met alle ID gegevens die zonder decryptie van je kaart zijn te
> >   lezen
> 
> Ik zou het toch houden op "enkel een server van de overheid"...
                                       ^^^^^^^^^^^^^^^^^^^^^^
				       referentie [B], zie verder


Ik zie dus 2 fundamentele requirements aan het systeem om privacy te
beschermen, en ik snap nog niet hoe die juist zullen worden ingevuld
in de scenario's van M$ en de minister:

Req. 1: "informatie maskering"
==============================

Er zijn applicaties waar je enkel partiele gegevens wil bekendmaken/bewijzen. Als je 
alle publiek zichtbare gegevens van de kaart wil bekendmaken aan de partij die de kaart 
afleest, is er geen probleem natuurlijk, ze doen maar (en eenmaal ze die gegevens hebben, 
kan je ze toch niet meer technologisch verhinderen deze verder te copieren of te 
publiceren). Ik noem die doelstelling "informatie maskering" (sommige info wil ik 
maskeren, sommige wil ik bekendmaken/bewijzen). Bijv.

* leeftijd wil ik vrijgeven en bewijzen, maar Voornaam/Achternaam wil ik maskeren 
* ZIP code wil ik bewijzen (voor toegang tot lokaal containerpark, daar heb ik ook 
  een RFID kaartje voor ...), maar de rest niet

Req. 2: "tegenpartij authenticatie"
===================================

In sommige gevallen wil ik alleen volledige of gedeeltelijke gegevens
ter beschikking stellen aan een partij nadat deze zich heeft
geauthenticeerd. Zoals in Req. 1 gesteld, kan ik een partij niet
technisch verhinderen om een gegevens te copieren, publiceren, agregeren
eenmaal ik ze heb doorgegeven, maar ik kan wel legaal maatregelen nemen
(confidentialiteit eisen), _als_ ik zeker weet aan wie ik de gegevens 
doorgeef. Voorbeeld:

* aan mijn bank wil ik gerust al mijn informatie beschikbaar stellen,
  maar ik wil wel zeker weten dat die applicatie die de gegevens komt
  vragen van mijn bank komt.

* aan de mensen van KetnetKick geef ik nu al veel gegevens door van mijn
  kids (inclusief Full Name, geboortedatum, ZIP, maar niet full address), 
  maar ik reken erop dat de VRT die 400,000 entries met het nodige respect
  voor privacy behandelt ...


Ik zie nu 3 opties om die "maskering" veilig te realizeren:

Optie A: beperkte kaart
========

De kaart (certificaat + private key signing functie) of een publiek certificaat 
(alleen data, geen elektronica) bevat alleen die subset van data die we willen
tonen/bewijzen aan de applicatie (of publiek maken) maken. In de vorm van een 
"kaart" met een private key en signing functie is dit wel relatief duur. Maar 
als dit bijvoorbeeld een certificaat is voor de associate tussen een nick 
(met een geheim paswoord op een jabber server) en de echte leeftijd, kost het
niet veel om dit te maken (als iemand trusted dit certificaat wil tekenen).

In jouw voorstel genereert de eID server van de overheid eigenlijk zo'n
tijdelijk beperkt certificaat.

Optie B: trusted client
========

Je hebt een trusted client bij je. Die client is van jezelf, interfacet
aan 1 kant met je eID kaart en aan de andere kant met de applicatie
tegen welke je wil authenticeren. Dan kan je je eigen trusted client 
vetrouwen dat die de data zal maskeren die je wil maskeren.

Optie C: trusted masking server
========

Er is een trusted server (van de overheid of privaat uitgebaat) die alleen die
data doorgeeft die je wil vrijgeven aan een applicatie. Jijzelf staat in
verbinding met die trusted server om je identiteit te bewijzen en die
server levert een token af of een tijdelijke associatie (certificaat) tussen een 
nick en een bepaald gegeven (bijv. leeftijd of ZIP of ...).

Het resultaat van zo'n trusted masking server zin o.a. tijdelijke certificaten
zoals in Optie A.


Voor Req. 2 (tegenpartij authenticatie) zie ik volgende opties:

Optie A: kaart checkt authenticatie tegenpartij
========

Als ik het geod begrijp, doet de kaart nu al authenticatie van de
gemeentelijke computer om schrijfrechten op de kaart toe te staan.
Dan reken je er ook op dat de applicatie die de private key van 
de gemeente kent ook een echte trusted application is. Nu kan dat 
nog bewaakt worden door 1 geisoleerde computer per gemeente of zo 
te nemen, maar er is wel een risico dat als die geheime sleutel lekt, 
iedereen at will op die kaart kan beginnen schrijven ...

Het is me niet duidelijk als er ook een authenticatie van de tegenpartij
nodig is om bepaalde gegevens van de kaart te lezen (adres, foto, ...) ?
(graag feedback als iemand weet hoe dat juist zit :-)

Het lijkt redelijk moeilijk om voor veel andere entiteiten ook die check 
op de kaart toe te voegen. De overheid zou een aantal applicaties 
kunnen tekenen die dan als second level op de kaart mogen schrijven,
maar dan krijg je een proliferatie van "trusted" applicaties en als
1 ervan dan breekt, kan je die niet individueel revoken.

Je zou individuele certificates op de kaart kunnen zetten van alle 
trusted applicaties, maar dan moet ofwel de kaart altijd de revocation 
list gaan checken (altijd online zijn), of fysisch teruggeroepen worden
om een on-chip revocation list up te daten wanneer zo'n applicatie 
gekraakt wordt ...

Optie B: trusted client
========

Dit is veel realistischer. Je bouwt een trusted client zodat je
tenminste zeker weet dat je echt over SSL met je bank praat, voor
je toegang geeft tot je kaart.

Optie C: trusted application authention server
========

Het zou inderdaad denkbaar zijn dat de overheid een lijst bijhoudt 
van alle applications waarop ze de nodige audit heeft uitgevoerd
en die je dus met een (relatief) gerust hart kan aanspreken. Op
die manier hoeven niet al die applicaties zelf bepaalde overheids-
keys te hebben, maar kan de overheid ze toch (tijdelijk, altijd
onmiddellijk te herroepen met een white list) te certifieren. Dit
werkt alleen online, maar is wel goed te implementeren.


Discussie:
==========

Je voorstel gebruikt optie C (trusted masking server). Ik zie nog 2
open vragen :

* er wordt ook gebruik gemaakt van een client [A]. Hoe weten we dat 
  die veilig is ? Wel als we zelf iets bouwen met Linux en jabber is
  er een redelijke kans dat dat lukt. En dat is toch een voordeel
  t.o.v. sommige andere besturingssystemen.

* is de overheid bereid om een dergelijke masking server te hosten ?
  Ik had hier nog niks van gezien (maar misschien was dat altijd al 
  het plan en heb ik hett niet gezien). Was dit altijd al het plan
  van M$ en de minister (om een door de overheid uitgebate masking
  server op te zetten) ?

  Nu ja, als de overheid het niet doet, zou je het natuurlijk ook 
  privaat kunnen doen. Gewoon met goed beheer en voldoende audit een
  trusted masking server opzetten (die publiek verifieerbare associaties 
  garandeert tussen een nick een leeftijd bijv.).
  
  Een alternatief dat ik vroeger had voorgesteld is dat iedere ouder
  voor zijn eigen kids als "trusted masking server" optreedt. Ik
  als ouder bevestig met mijn digitale handtekening dat de nick 
  cookie at hotmail.com [fictief] , geassocieerd is met een zoon/dochter 
  van mij van minder dan 12 jaar. Het voordeel hiervan is dat niemand
  een mega-database kan creeeren waar al die associaties met de 
  achterliggende full data gestockeerd zouden kunnen zijn. Als iedereen
  dit gewoon thuis doet, komt de gemaskeerde data nooit naar buiten
  en wordt nooit samen geagregeerd (de niet gemaskeerde data wel
  natuurlijk, want die moet publiek verifieerbaar zijn).


Het probleem dat blijft liggen is dat van de trusted client. Ideaal zou
je een soort dedicated device willen met:

* een interface naar eID
* toetsenbordje
* schermpje (zodat je ziet wat je tekent)
* uplink naar untrusted netwerk (USB, Eth, Bluetooth, IR)

Dit bestaat natuurlijk al vele jaren, maar is altijd te duur gebleken 
voor massa toepassingen. 

Maar, iedereen heeft een gsm. Misschien is het denkbaar om je gsm 
te gebruiken als je er een interface naar de kaart bij kan zetten ?

Maar het is me niet duidelijk hoelang we een gsm nog als een trusted
device kunnen beschouwen ... aan de andere kant ben ik meer geneigd
om mijn gsm (nadruk op _mijn_ device dat _ik_ beheer) te vertrouwen 
als client om de afscherming van mijn kaart te doen en ook verificatie
van de applicaties die met mijn kaart mogen communiceren.

Er zijn initiatieven (Xen etc.) die meerder OS'en naast elkaar mogelijk 
maken op 1 PC en dat is misschien de oplossing hiervoor. Je PC (of open
gsm op Linux) draait dan niet alleen Linux, maar ook een kleine
gecertifieerde applicatie die als trusted client dient voor dit 
soort applicaties. Met een stukje hardware bescherming kan je er
dan voor zorgen dat alleen je eigen, gecertifieerde applicatie 
door de HW interface naar de eID kaart kan (omdat alleen die 
applicatie een speciale code op outpout pinnen kan prodcuren). En 
als je ineens een FPGA gebruikt, kan die code zelfs persoonlijk
zijn en wijzigen in de tijd (gewoon de gecertifieerde applicatie
persoonlijk hercompileren). Lijkt me niet zo makkelijk te kraken
van op een afstand (als Xen zijn werk goed doet).

Over je opmerking [B] dat je alleen een server van de overheid wil
trusten. Ik zou er meer trusten als er ofwel een certificatie is
van de applicatie aan de andere kant of als ik zelf met een trusted
client de info kan maskeren die ik wil maskeren.

Some toughts ...

Peter

> <snip>
> 
> -- 
> Mvg, Sander Devrieze.
> 
> xmpp:sander at l4l.be ( http://jabber.l4l.be/ )