An Assessment of a Privacy Impact Assessment: Idensys under review

We krijgen in Nederland een nieuw systeem om online in te loggen, als opvolger en uitbreiding van DigiD. Hiervoor is de oostbloknaam Idensys gekozen. Met Idensys moet je niet alleen bij de overheid, maar ook bij private partijen — zoals webwinkels, banken, sociale media, zorgverleners etc. — kunnen inloggen. De juiste term voor dit inloggen is overigens authenticeren: bewijzen wie je bent.

De Minister van Economische Zaken is verantwoordelijk voor Idensys. Dit is een belangrijk gegeven dat een boel verklaart. Het Ministerie van Economische Zaken (kortweg: MinEZ) is er voor de BV Nederland. Daar is op zich niks mis mee, maar de vraag dient zich aan of MinEZ bij het opzetten van Idensys wel voldoende rekening houdt met andere belangen. In onze moderne digitale samenleving bepalen de informatiestromen en de authenticatie-verplichtingen de machtsverhoudingen. Wanneer de keuze vanDde infrastructuur daarvoor in de handen ligt van een ministerie met zulke eenzijdige belangen rijzen zorgen over het algemene belang.

DigiD is een authenticatiesysteem waar in principe alle burgers gebruik van maken, en dus redelijk mee bekend zijn. Naast DigiD kent Nederland nog een ander, minder bekend systeem, namelijk eHerkenning, dat ontworpen is voor authenticatie tussen bedrijven. Begrijpelijkerwijs speelt privacy bij eHerkenning daarom geen noemenswaardige rol. Verschillende bedrijven hebben de afgelopen jaren geïnvesteerd in het opzetten van eHerkenning, maar zijn daar nooit heel rijk van geworden. MinEZ begrijpt dat het goed is voor de BV Nederland als investeringen zoveel mogelijk opbrengen, en heeft dus besloten dat eHerkenning ook voor burgers gebruikt moet worden, onder de nieuwe naam Idensys. In vele Haagse en Brusselse beleidsstukken over moderne ICT speelt het begrip privacy-by-design een grote rol. Bij Idensys is echter gekozen voor nonprivacy-by-design.

Overigens is ook het verwijt hoorbaar, bijv. van de grote webwinkel bol.com in een brief van mei 2015, dat de overheid wel heel eenzijdig heeft geluisterd naar een klein aantal aanbieders. Bol.com roept de overheid op zelf haar verantwoordelijkheid te nemen op het gebied van elektronische identiteiten en ook in het digitale domein voor de ‘publieke zaak’ te zorgen. Natuurlijk speelt hier ook mee dat bol.com bang is voor hoge transactiekosten nu de commerciële belangen van enkele partijen zo eenzijdig gediend worden.

Het is een lovenswaardige ambitie om een nationaal, of zelfs Europees, stelsel voor authenticatie op te zetten dat de verschillende partijen zekerheid en bescherming biedt. Bij gebrek aan zo’n stelsel worden we steeds vaker geconfronteerd met logins via Facebook of G-Mail, waarbij gebruikers als enige zekerheid hebben dat hun gegevens geplunderd worden. Helemaal aan het eind volgen suggesties om tot zo’n nieuw stelsel te komen.

Over Idensys

Hieronder staan, in eigen, niet-ambtelijke woorden, de belangrijkste doelstellingen van Idensys.

1.Dienstaanbieders, zoals webwinkels, ontvangen betrouwbare relevante informatie over degenen die bij hen in willen loggen.

2.Dienstaanbieders hoeven het wiel niet zelf uit te vinden (“worden ontzorgd”), maar kunnen vertrouwen op andere partijen en hun authenticatiemiddelen.

3.Het systeem is robuust: als een authenticatie-middel of -dienst uitvalt, valt niet het hele stelsel om. Dit is belangrijk in het licht van de gebleken zwakheden van DigiD (of nog erger, van DigiNotar).

4.Het systeem beschermt de privacy van gebruikers, en biedt gemak.

5.Het systeem is zowel in de publieke als in de private sector bruikbaar.

Hieronder wordt betoogd dat Idensys, afgezien van het laatste punt, deze doelstellingen niet of slechts is zeer beperkte mate realiseert.

Voor we zover zijn is het goed iets meer te weten over de feitelijke werking van Idensys. Het stelsel kent de volgende partijen.

De dienstaanbieder, zoals een webwinkel, die behoefte heeft aan enkele zekerheden over degene die inlogt en een dienst af wil nemen of iets wil kopen of regelen.

De gebruiker natuurlijk, die online iets wil doen bij een dienstaanbieder: u en ik.

De authenticatiedienst bij wie de gebruiker zich feitelijk authenticeert, via een wachtwoord, een eenmalige SMS code, een chipkaart, of mogelijk via een mobiele telefoon. Deze authenticatiedienst stuurt de dienstaanbieder na een geslaagde authenticatie van een gebruiker een pseudoniem: een willekeurig getal dat voor u gegeneerd wordt en per dienstaanbieder verschilt. Dit pseudoniem is wel steeds hetzelfde bij dezelfde dienstaanbieder, bij iedere nieuwe login. Daarmee kan de dienstaanbieder u  steeds herkennen (zelfs als dat helemaal niet nodig of zelfs ongewenst is).

De makelaar is een relikwie uit eHerkenning die de dienstaanbieder moet “ontzorgen”, door de koppeling met de verschillende authenticatiediensten te regelen en berichten door te geven.

Het BSN koppelregister is een partij die er via ingewikkelde koppelingen voor moet zorgen dat een overheidspartij na succesvolle authenticatie bij een authenticatiedienst niet een pseudoniem maar steeds het juiste Burger Service Nummer (BSN) krijgt.

Het BSN mag volgens de wet niet door private partijen gebruikt worden(enkele uitzonderingen daargelaten). De pseudoniemen die binnen Idensys voorzien zijn kunnen opgevat worden als een soort privaat-BSN, dat per dienstaanbieder verschilt. Deze diversificatie van pseudoniemen is bedoeld als privacy-vriendelijke maatregel, om te voorkomen dat verschillende dienstaanbieders hun pseudoniemen onderling vergelijken en hun administraties koppelen.

De authenticatiepooier

De authenticatiedienst heeft de belangrijke taak om deze pseudoniemen te genereren en ze te leveren aan de verschillende dienstaanbieders, eventueel samen met uw naam, geboorte-datum en -plaats. De authenticatidienst:

weet precies onder welk nummer (pseudoniem) u waar bekend bent;

weet ook in detail wanneer u, via dat nummer, bij welke dienstaanbieder inlogt;

kan een volledig profiel van u opbouwen, zeker omdat gegevens binnen Idensys zeven jaar lang bewaard worden — een termijn waar Google alleen maar van kan dromen.

Omdat de authentiedienst online alle contacten voor u regelt en alles van u weet zal hiervoor als alternatieve aanduiding authenticatiepooier gebruikt worden. Deze minder positieve framing benadrukt hoe u als gebruiker in Idensys tot volledige overgave wordt gedwongen. Binnen Idensys zijn verschillende commerciële authenticatiepooiers voorzien, waaruit u en ik er een moeten kiezen om er een abonnement te kopen, van zeg een tientje per maand. De pooier ziet vervolgens hoe vaakuD bij een slijter inlogt, of bij een verzekeraar, of bij een vruchtbaarheidskliniek, of bij een goksite, om maar wat te noemen. Concreet kunnen we er aan denken dat Google, of Baidu, of een bank de rol van authenticatiedienst binnen Idensys gaat vervullen. Dat is misschien toch minder prettig als die bank tegelijkertijd over uw hypotheekaanvraag beslist.

MinEZ zegt met Idensys wereldwijd tegen bedrijven: kom je in Nederland vestigen als authenticatiedienst; wij zetten hier een systeem op waarmee u op fantastische wijze Nederlandse burgers kunt profileren. En u kunt er deze burgers nog geld voor laten betalen ook!

Evaluatie van de Idensys doelstellingen

De eerste vier van de bovenstaande vijf eigen doelstellingen voor Idensys worden hieronder kritisch tegen het licht gehouden.

1.De dienstaanbieder krijgt zekerheden over gebruikers. Wat de dienstaanbieder krijgt zijn betekenisloze pseudoniemen. Van iedere dienstaanbieder die zich bij Idensys aansluit wordt geëist dat hij zijn klanten database reorganiseert en bij iedere klant een nieuw nummer als database sleutel toevoegt, namelijk het Idensys-pseudoniem van die klant. Als dat allemaal gereorganiseerd is, kan de dienstaanbieder op basis van een door een authenticatiedienst aangeleverd pseudoniem de bijbehorende klantgegevens opzoeken in zijn database.We bespreken verschillende moeilijkheden.

Hoe weet een dienstaanbieder eigenlijk welk pseudoniem bij welke klant hoort? Zonder die kennis kan de database immers niet aangepast worden, en kan na authenticatie een klant niet gevonden worden. Om die koppeling te maken kan de dienstaanbieder, na eerste aanlevering van het pseudoniem, de klant zelf vragen wie hij/zij is eigenlijk is, en vragend at te bewijzen. Dat lukt  alleen als de dienstaanbieder al een betrouwbaar eigen vorm van authenticatie heeft, voordat hij zich aansluit bij Idensys, en die eigen vorm kan koppelen aan een Idensys sessie. Met de aansluiting op Idensys wordt dat eigen authenticatie systeem dan overbodig.Een alternatief is dat de dienstaanbieder de eerste keer niet alleen het pseudoniem, maar ook de echte naam plus datum/plaats van geboorte, krijgt van de dienstaanbieder. Daarmee is het koppelingsprobleem opgelost, maar wordt het hele pseudoniem te niet gedaan. En als veel dienstaanbieders deze makkelijkste weg kiezen, kunnen ze met collega’s samenspannen en op basis van naam en geboorte datum/plaats klanten alsnog onderling koppelen.

Een pseudoniem is voor een dienstaanbieder helemaal niet interessant voor een transactie met een gebruiker. Daar zijn attributen (persoonlijke eigenschappen) voor nodig als: naam, adres, telefoonnummer, of iemand boven de 16 of 18 is (of onder de 16), of iemand student is, of inwoner van Nijmegen, of Nederlander etc. Stel ik wil iets op uitzendinggemist terug zien, en moet aantonen dat ik boven de 16 ben. Daarvoor is een pseudoniem nutteloos. Het pseudoniem geeft de dienstaanbieder enkel een (privacy-onvriendelijk) middel om een historie over mij op te bouwen.

Een pseudoniem is voor een gebruiker al even betekenisloos en onbegrijpelijk. De gebruiker wil zien welke gegevens (attributen) er overgedragen worden aan een dienstaanbieder voor een bepaalde transactie. Zoals gezegd, geeft een pseudoniem dienstaanbieders alleen maar mogelijkheden om gebruikers te profileren.Op eenzelfde wijze gebruikt de zogenaamd anonieme OV-chipkaart een pseudoniem, waarmee alle reizen met die kaart aan elkaar gekoppeld worden.

Geregeld wordt een eigenaar van een anonieme kaart gedwongen zichzelf bekend te maken, bijv. bij terugstorten van het overgebleven bedrag aan het eind van de levensduur van de kaart, of als er tussentijds iets fout is gegaan en restitutie nodig is. Op dat moment kan de hele reishistorie alsnog aan een individu gekoppeld worden. Met Idensys-pseudoniemen wordt dezelfde schijn-privacy- verwachting gewekt. Hier wordt burgers zand in de ogen gestrooid.

2.Dienstaanbieders worden ontzorgd. Dat lijkt een zeer eufemistische kijk op de zaak want een dienstaanbieder moet om aan Idensys mee te kunnen doen: zijn klanten database herstructureren, om een pseudoniem toe te kunnen voegen (zie hierboven); een proces verzinnen om deze nieuwe pseudoniemen te koppelen aan bestaande klanten; een abonnement bij een makelaar nemen, en via die makelaar met alle dienstaanbieders beveiligde verbindingen onderhouden. Binnen Idensys worden deze verbindingen als “end-to-end” beschreven, maar dat is onjuist, zie later onder punt 4. Hiervoor moeten dienstaanbieders zelf uitgebreid aan cryptografisch sleutelbeheer doen en in staat zijn om te ontsleutelen en elektronische handtekeningen te controleren. De makelaars mag dit niet doen, want anders wordt die een nieuwe privacy-hotspot in het systeem. (Terzijde: in IRMA, zie hieronder, kunnen dienstaanbieders hun bestaande database ongewijzigd blijven gebruiken, inclusief hun eigen klantnummers. Die originele klantnummers worden onderdeel van een attribuut dat klanten krijgen, waarmee ze zich vervolgens kunnen authenticeren. Het koppelingsprobleem bestaat overigens ook in deze opzet: aan wie moet je welk nummer in een attribuut uitreiken?)

De makelaar is de partij in Idensys die de vermeende ontzorging moet bewerkstelligen. Makelaars kunnen echter niet helpen bij de zojuist genoemde drie echte zorgen van dienstaanbieders. De enige taak die makelaars feitelijk hebben is om een authenticatiedienst-keuze-menu aan te bieden aan de gebruiker. Het is de vraag of dienstaanbieders voor zo’n menuutje gaan betalen; dat kunnen ze net zo makkelijk zelf doen, want de inspanning daarvoor valt in het niet bij de bovenstaande drie punten. Deze makelaar is een eHerkenning relikwie die de kosten alleen maar opdrijft en uit de hele Idensys architectuur verwijderd kan (moet) worden. Een basisregel in security is immers: hou het simpel.

3.Het systeem is robuust. Er is voorzien dat er verschillende authenticatiediensten zijn, en dat gebruikers bij problemen een andere dienst (mogelijk met een ander authenticatiemiddel) kunnen gaan gebruiken. Bijvoorbeeld, als je bankpas niet meer werkt om in te loggen,kun je met je overheidspas alsnog bij de bank terecht. Maar omdat authenticatiediensten niet gratis zijn, zullen er maar weinig gebruikerszDijn die er meerdere hebben. Misschien gaat het er meer om dat gebruikers pas wanneer problemen zich voordoen wel bereid zijn om extra te betalen en over te stappen. Dat zal dan zeker geen naadloze overstap zijn, omdat bij een nieuwe authenticatiedienst het hele registratieproces opnieuw doorlopen moet worden, waarbij omslachtige face-to-face authenticatie voorzien is.Maar een veel groter probleem  is dat deze verschillende authenticatiediensten voor eenzelfde gebruiker bij eenzelfde dienstaanbieder verschillende pseudoniemen genereren. Deze dingen zijn onderling niet afgestemd, waardoor een van de belangrijkste robuustheidseisen van Idensys volledig faalt. Bij gebruik van een middel van een andere authenticatiedienst wordt de gebruiker niet meer herkend door de dienstaanbieder.Mocht het in de toekomst wel tot uniforme generatie van pseudoniemen komen dan zal daar een vorm van onderlinge coordinatie voor nodig zijn die de privacy van de gebruiker ongetwijfeld niet ten goede komt.

4.De privacy van de gebruiker wordt beschermd. De belangrijkste techniek waarvan Idensys claimt dat de privacy van de gebruiker ermee beschermd wordt is het gebruik van dienstaanbieder-specifieke pseudoniemen. Zoals hierboven reeds beschreven, biedt dit schijn-privacy, omdat pseudoniemen betekenisloos zijn en alleen gebruikt kunnen worden als ze eenmaal aan personen gekoppeld zijn. Het belangrijkste, feitelijk privacy-onvriendelijke, nut van pseusoniemen is het traceren van gebruikers per aanbieder.Een tweede techniek die de privacy van de gebruiker moet beschermen is wat binnen de Idensys contekst end-to-end encryption genoemd wordt. In het algemeen wordt de term end-to-end  encryption gebruikt wanneer het hele pad tussen twee gebruikers (endpoints) versleuteld wordt en daarmee onleesbaar is voor tussenliggende partijen. Bijvoorbeeld, speciale software maakt gesprekken tussen twee mobiele telefoons end-to-end versleuteld wanneer de versleuteling op de ene telefoon plaatsvindt, en de ontsleuteling op de andere (en vice-versa); hiermee bestaat het gesprek tijdens overdracht niet in onversleutelde vorm bij de tussenliggende mobiele provider, en kan het dus ook niet afgeluisterd worden, door bijvoorbeeld politie of inlichtingendiensten.Binnen Idensys wordt de term end-to-end encryptie gebruikt voor versleuteling tussen de dienstaanbieder en de authenticatiedienst.  De dienstaanbieder is inderdaad een endpoint. Maar de authenticatiedienst is helemaal geen endpoint! De gebruiker is het endpoint. De term end-to-end encryptie wordt dus helemaal verkeerd gebruikt, en geeft een vertekend misplaatst-positief beeld. Er kan hooguit gesproken worden van mid-to-end versleuteling. Men vraagt zich af: is hier sprake van domheid of kwaadaardigheid? Hopelijk niet het laatste, maar het eerste is ook weinig geruststellend. Dit foutieve gebruik van de term end-to-end encryption komt waarschijnlijk voort uit een (naïeve of kwaadaardige) identificatie van de authenticatiedienst met de gebruiker. Maar deze twee partijen hebben volstrekt uiteenlopende belangen, hetgeen hierbovenbDenadrukt is door de authenticatiedienst aan te duiden als authenticatiepooier. Deze pooier wil geld verdienen aan zijn gebruiker, en zal hem mogelijk tegen zijn wil profileren en via aanbiedingen en uitsluitingen in zijn gedrag sturen.

Vanuit Idensys komt hierop de reactie: dan kies je toch een authenticatiedienst die je vertrouwt! Maar  als ik nu geen enkele van deze pooiers vertrouw? Je zou nog kunnen zeggen dat gebruikers ook hun internet service provider (ISP) moeten vertrouwen. Maar een gebruiker kan zich tegen zijn ISP beschermen, via TLS, VPNs, Tor, of via versleuteling van de inhoud, bijv. met PGP. Tegenover een Idensys authenticatiepooier is een gebruiker echter kansloos.

Hiermee moet geconcludeerd worden dat Idensys niet aan de eigen eisenDvoldoet. Het is een hopeloze, privacy- onvriendelijke onderneming. Commerciële belangen dicteren het problematische centralistische karakter van de architectuur, zodat de authenticatiediensten in het midden iedere transactie voorbij zien komen en: er een “tikker” op kunnen zetten en dienstaanbieders per transactie kunnen laten betalen (zie de zorgen van bol.com); bij kunnen houden wie wanneer waar naar toe gaat en waardevolle profielen van gebruikers op kunnen bouwen (zie de pooier discussie);

vooral gericht zijn op de dienstaanbieders, die immers per transactie moeten betalen, in plaats van op de gebruikers.

Er zal mogelijk sussend gezegd worden: het gaat vooralsnog enkel om een eerste versie (een ‘introductieplateau’) dat beperkt gebruikt wordt om ervaring op te doen, en op basis daarvan verbeterd kan worden. Oplappen en bijschaven heeft echter geen enkele zin, want de ontwerpfouten zitten diep in de centralistische architectuur. Het meest voor de handliggende (angst) scenario is dat we er niet meer van af komen: er wordt nu gesust, en straks wordt gezegd: er is al heel veel geïnvesteerd in deze architectuur, dus kunnen we niet meer terug.

De PIA van Mazars

Op dit moment aangekomen is de nieuwsgierigheid groot naar de Privacy Impact Assessment (PIA) die geschreven is door het adviesbureau Mazars. Deze PIA is van 31 juli 2015 en concentreert zich op een eerste versie van Idensys, genaamd introductieplateau. Zo’n privacy impact assessment is een nieuw instrument om bij grote ICT-projecten de gevolgen voor de privacy van betrokkenen in kaart te brengen. Bij een privacy by design aanpak dient zo’n PIA vroeg in het proces uitgevoerd te worden, en idealiter later nog eens herhaald te worden. De onderstaande bespreking is noodzakelijkerwijs beperkt van aard en concentreert zich op de hierboven geconstateerde problemen met Idensys. Voor een volledig beeld wordt naar het hele rapport verwezen.

Bij commerciële adviesbureaus is er altijd een spanningsveld tussen:

de opdrachtgever behagen, zodat de kans op een vervolgopdracht het grootst is; kritisch zijn om de eigen professionaliteit te tonen.

Ook in de PIA van Mazars is dit spanningsveld zichtbaar. Kritische opmerkingen komen zeker voor, maar staan minder prominent pas later in het rapport. Voorin, in de management samenvatting, staan kruiperige waarschuwingen dat de opdrachtgever vooral niet moet schrikken:

In deze rapportage, en eigenlijk inherent aan elk assessment, worden bevindingen gemaakt die wellicht kritisch kunnen overkomen. (p.11)

Toch staat er een fijne conclusie voor de opdrachtgever:

De conclusie van deze PIA is dat in de beschrijvingen vanhDet Introductieplateau eID en het Afspraken Stelsel uitdrukkelijk aandacht is besteed aan technische en procedurele maatregelen waarmee de privacybescherming van burgers en consumenten zijn bevorderd. Het programma heeft, ook op dit punt, het maximale gedaan om de privacy van gebruikers te beschermen. (p.11)

Ondanks dat volgens Mazars het maximale is gedaan, is er, enigszins in tegenspraak met deze pleasers, wel degelijk wat aan de hand volgens Mazars. Het privacy gevaar bij de authenticatiedienst wordt gezien, maar de toon is niet meteen verontrustend:

Bij de Authenticatie Diensten ontstaan onvermijdelijk cumulaties van gevoelige verzamelingen van persoonsgegevens, zogenaamde “hotspots”. Er is hier uitdrukkelijk binnen het programma aandacht aan besteed en er zijn maatregelen getroffen. Maar: het verschijnsel is wel inherent aan elk eID Stelsel en er is geen maatregelDdenkbaar die dit voor 100% mitigeert. (p.11)

Deze laatste opmerking is pertinent onjuist. In het gedecentraliseerde eID stelsel zoals IRMA (zie onderstaand naschrift)Dvoorstaat zijn geen centrale authenticatiediensten nodig, en ontbreken daarom dergelijke privacy hotspots. Ofwel Mazars kent IRMA niet — en toont zich daarmee geen expert op het gebied van identity management — ofwel Mazars wil IRMA niet noemen. Deze laatste optie is het meest waarschijnlijk, om de opdrachtgever niet te herinneren aan genegeerde alternatieven en discussie te vermijden over de problematische (commercieel gemotiveerde) centralistische architectuur van Idensys.

Mazars neemt de ongecompliceerde kijk op privacy van Idensys klakkeloos over:

Een Gebruiker wordt in staat gesteld om naar elke Dienstaanbieder een andere identiteit (pseudoniem) kenbaar te maken en kan daarmee zijn digitale privacy behouden. (p.14)

Het feit dat pseudoniemen grote problemen kennen, zoals hierboven besproken, komt in het hele rapport niet aan de orde.

Maar Mazars begrijpt wel wat de oorzaak is van alle privacy problemen:

De eerder genoemde nog bestaande en nieuwe privacy risico’s komen vooral voort uit de inzet van eHerkenningsdiensten,Ddie initieel uitsluitend voor bedrijven waren bedoeld, nu ook ingezet worden in het consumenten- en burgerdomein. De hieraan gerelateerde privacy risico’s worden verderop in deze rapportage uitgewerkt en toegelicht. (p.15)

Verder op in het rapport staat het nog duidelijker: Idensys is gewoon eHerkenning:

Belangrijkste verschil tussen eHerkenning en Idensys heeft betrekking op de doelgroep. eHerkenning is voornamelijk gericht opbDedrijven als gebruikers.

Deze problematische herkomst van Idensys wordt gekoppeld aan de hierboven geconstateerde “pooier” problematiek:

Inherent aan het ontwerp, hergebruik van de genoemde bestaande middelen, i.c bestaande   eHerkenning architectuur, is er sprake van het ontstaan van een cumulatie van gevoelige tot zeer gevoelige en hoewel in de documentatie niet duidelijk onderkent, naar verwachting ooksDtigmatiserende persoonsgegevens op het niveau van Authenticatiediensten en BSN Koppelregister. In privacy jargon worden dit “hotspots” genoemd. (p.17)

(Over kromme zinnen en d/t fouten zullen we het hier maar niet hebben.)

Mazars kent de betekenis van de term end-to-end ook niet; de foutieve Idensys interpretatie wordt letterlijk overgenomen:

In het document Beschrijving Idensys in het Introductieplateau eID zijn de volgende waarborgen ter bevordering van de privacy gedefinieerd ten opzichte van eHerkenning:

1.[…] In het Introductieplateau eID zijn aanvullende maatregelen genomen, waarbij identificerende persoonsgegevens door de authenticatiedienst zodanig worden versleuteld zodat deze alleen door de ontvangende dienstverlener zijn te lezen. Deze maatregel wordt veelal aangeduid met de term end-to-end encryptie. (p.29)

Niet alleen bij Idensys, maar dus ook bij Mazars, ontbreekt het cruciale inzicht dat de gebruiker en niet de authenticatiedienst endpoint moet zijn bij end-to-end versleuteling. Deze lacune in de kennis van zaken bij de evaluator is pijnlijk. Op zo’n manier worden serieuze privacy problemen weggedefinieerd. De PIA verliest hiermee aan waarde en gezag.

Het BSN koppelregister is in deze bespreking nog helemaal niet ter sprake gekomen. De noodzaak van deze ingewikkelde constructie komt voortuD it de centralistische architectuur van Idensys. Mazars wijst erop dat de constructie vereist dat private partijen, namelijk de authenticatiediensten, het BSN gaan verwerken. Maar Mazars legt ook een interessante koppeling met privacy, via het recht op inzage en transparantie: Gezien de data interactie tussen de BSN Koppelregister en de meerdere te onderscheiden overige eID Deelnemers in een identificatie/authenticatie/machtigings/vertegenwoordigings proces, is het voorstelbaar dat een betrokkene, wil hij zijn rechten effectueren, “door de bomen het bos niet meer ziet” en mogelijk “van het kastje naar de muur wordt gestuurd”. Dit zou het inzagerecht voor wat betreft het eID Stelsel tot een fictie kunnen maken. (p.33)

In gewoon Nederlands: het is zo complex dat het aan geen mens uit te leggen is, en dat zal waarschijnlijk ook niet gebeuren.

Mazars constateert ook, maar pas heel laat in het rapport, dat interoperabiliteit tussen authenticatiediensten helemaal niet bestaat:

Bijkomend probleem is dat Gebruikers met authenticatiemiddelen van verschillende authenticatiediensten met verschillende Pseudo-identiteiten aankomt bij een private Dienstverlener. (p.48)

De voor de opdrachtgever vernietigende, maar onvermijdelijke conclusie dat Idensys hiermee niet voldoet aan de eigen belangrijke robuustheidseisen wordt door Mazars echter niet getrokken.

Tot slot nog lijstje met losse eigenaardigheden in de PIA.

Over de rol van de makelaar:

De Makelaar laat de Gebruiker zijn Authenticatiedienst kiezen en stuurt de Gebruiker door naar deze Authenticatiedienst. Deze stap kan efficiënt ingericht worden door voorkeuren van de Gebruiker te bewaren. (p.46, 49, 50)

Hallo, hoe weet de makelaar de identiteit van de gebruiker, zodat zijn/haar voorkeuren bewaard kunnen worden? Het gaat hier toch om authenticatie! De gebruiker moet zich bij de authenticatiedienst authenticeren en pas daar wordt duidelijk wie de gebruiker eigenlijk is. Een bericht hierover gaat mid-to- end versleuteld, maar in ieder geval onzichtbaar voor de makelaar, naar de dienstaanbieder. Heeft Mazars het niet goed begrepen, of zit hier een achterdeurtje in het systeem?

Nog steeds over die merkwaardige makelaar: dienstaanbieders willen natuurlijk zo weinig mogelijk gedoe, en zullen ingewikkelde, maar ook strategische, zaken binnen Idensys zo veel mogelijk uitbesteden, net zoals ze betalingen door klanten vaak uitbesteden aan zogenaamde Payment Service Providers (PSPs). Een interessante vraag doet zich voor: kan een dienstaanbieder het hele gedoe over versleuteling en handtekeningen ook uitbesteden aan de makelaar? Over dergelijke vormen van “ontzorgen” zegt Mazars niks. Toch is dit een groot privacy risico, waarmee een nieuwe privacy hotspot geïntroduceerd wordt, namelijk de makelaar, en de zogenaamde end-to-end versleuteling nog verder ondergraven wordt en verwijderd raakt van de endpoints. Wat overblijft is dan mid-to-mid  versleuteling.

Eerst een citaat:

Indien een eID- deelnemer is gehackt, dan is slechts een beperkt aantal gegevens gecompromitteerd. Het is dan eenvoudiger om de deelnemer uit het eID Stelsel te verwijderen zonder dat dit grote gevolgen heeft voor het eID Stelsel. (p.78)

Huh, pardon? Als een authenticatiedienst gehackt wordt liggen van alle aangesloten gebruikers alle pseudoniemen en de hele historie op straat. Het is dan voor iedereen te zien welke gebruikers waar ingelogd hebben, en dienstverleners kunnen dan naar hartelust hun bestanden voor deze gebruikers onderling gaan koppelen. Een privacy ramp van de eerste orde. Misschien heeft dat geen grote gevolgen voor het eID stelsel zelf, maar voor de getroffen gebruikers wel degelijk. Dit soort citaten tonen aan dat Mazars onvoldoende distantie heeft en te veel het perspectief van de opdrachtgever overneemt.

Conclusie

In het licht van het bovenstaande concluderen we dat de Mazars met deze PIA op een aantal punten door het ijs zakt. Deze PIA van Mazars:

laat onvoldoende inhoudelijk kennis van zaken zien (bijv. over end-to-end versleuteling, alternatieve eID systemen, beperkingen van pseudoniemen);

neemt te weinig afstand van het gezichtspunt van de opdrachtgever;

geeft de eigen kritische opmerkingen onvoldoende prominentie en laat ze te weinig terugkomen in de conclusie.

Met deze PIA wordt een kans gemist om alarm te slaan en kan Idensys doormodderen tot EPD-achtige proporties. Een cruciale vereiste bij een authenticatie systeem dat breed gebruik ambieert is een zorgvuldige afweging van de belangen van de verschillende betrokkenen. Nu de overheid (i.c. MinEZ) met Idensys kiest

voor de behartiging van de belangen (mbt. kosten en gegevensverzameling) van een kleine groep commerciële partijen vraagt men om problemen: in de Tweede of Eerste Kamer, bij een (Europese) rechter, of bij webwinkels en gebruikers die uiteindelijk afhaken.

Naschrift 1: over IRMA

Je kunt er op wachten, er zal gezegd worden: ja, ja, die Jacobs zit hier alleen maar zijn eigen IRMA oplossing te pushen! Dat is echter geen inhoudelijke reactie op de bovenstaande punten. Laten we het daar eerst over hebben!

Om onduidelijkheden en vertroebeling van de discussie te voorkomen is het belangrijk het volgende expliciet op te merken.

IRMA is een onderzoekproject van de Radboud Universiteit over attribuut-gebaseerde authenticatie, waarvoor prototype implementaties gratis beschikbaar zijn. De ontwikkeling is gebaseerd op open ontwerpen en open source software. Het IRMA team heeft geen commerciële belangen bij IRMA, maar ziet het als zijn wetenschappelijke en maatschappelijke taak om te onderzoeken en te demonstreren  wat technisch mogelijk is op het gebied van security en privacy in identity management. Het staat iedereen vrij om het IRMA systeem zelf te evalueren en te gebruiken. Je kunt er bijv. mee bewijzen dat je boven de 18 of onder de 15 bent zonder iets anders van jezelf te onthullen. De techniek ondersteunt (goedkope!) self-enrolment, en op termijn ook attribuut-gebaseerde handtekeningen (waarbij je aan een electronisch handtekening kunt zien dat die bijv. gezet is door een huisarts of een notaris). Ja inderdaad, wij denken, op goede gronden, dat attributen (en niet pseudoniemen) het beste uitgangspunt vormen voor modern identity management en dat de IRMA prototype implementatie een basis kan zijn voor een deugdelijke eID oplossing die het algemene belang dient en makkelijk in een internationale contekst bruikbaar is.

IRMA is op een decentrale architectuur gebaseerd, ipv. op een centrale architectuur zoals bij Idensys: de IRMA-gebruiker communiceert rechtstreeks met de dienstaanbieder, zonder tussenkomst van andere partijen (dure privacy hotspots), en toont dan alleen die attributen die voor de transactie relevant zijn (bijv. adres en bankrekening bij een webwinkel, of het klantnummer). Omdat de uitgangspunten zo anders zijn is het zinvol een inhoudelijke vergelijking te maken tussen deze twee architecturen, zie  hieronder, en op basis daarvan eventuele keuzes te maken. Zo’n afweging heeft zover bekend nooit plaatsgevonden. (Een overzicht van verschillende oplossingen bestaat wel.) Integratie van IRMA en Idensys is vanwege de diametraal tegenovergestelde architecturen niet mogelijk, zonder verlies van de privacy-vriendelijkheid van IRMA (het grote selling point).

Het inzicht dat attributen er werkelijk toe doen (en niet psuedoniemen) is ook binnen Idensys aanwezig. Daarom wordt in latere versies voorzien dat authentiecatiediensten ook attributen over hun gebruikers (zoals: is boven de 18, of heeft dit bankrekeningnummer) aan dienstaanbieders kunnen leveren. Maar hiemee worden ze nog grotere pooiers, omdat ze niet alleen al deze eigenschappen gaan verzamelen maar ook nog kunnen volgen waar die op welk moment door wie gebruikt worden. Daarbij: deze centralistische Idensys-opzet werkt helemaal niet, zoals het volgende praktijk voorbeeld illustreert. Het UWV verlangt van burgers die ziek zijn een arts-verklaring, en het UWV wil terecht kunnen nagaan of die verklaring daadwerkelijk van een arts afkomstig is. Er bestaat hiervoor een landelijk register (het zogenaamde BIG-register),Dmaar daar mag het UWV, of een authenticatiedienst, niet in. Nu kun je natuurlijk de wet gaan veranderen en bepalen dat alle Idensys-authenticatiediensten toegang tot alle registers krijgen —waarmee je het nog aantrekkelijker maakt voor de Google’s van deze wereld. Echter, met een decentrale architectuur (zoals bij IRMA) kan een arts geheel binnen de huidige wetgeving zelf een arts-attribuut krijgen vanuit het BIG, en daarmee het UWV tevredenstellen, zelfs met een betrouwbare attribuut-gebaseerde elektronische handtekening op de afgegeven medische verklaring. Dit vereist een infrastructuur voor uitgifte van attributen, als moderne invulling van de Wet Bescherming Persoonsgegevens die burgers inzage in registers geeft. Een decentrale aanpak is daarom veel intuïtiever en natuurlijker, doet wat nodig is, past binnen de huidige wet, en geeft minder machtsconcentraties.

Mensen van het IRMA team hebben de afgelopen jaren regelmatig informeel contact gehad met leden van het Idensys team, bijv. op PIMN– en ECP-bijeenkomsten en op de open IRMA bijeenkomsten die enkele keren per jaar plaatsvinden. De kritische opmerkingen aan het begin van dit artikel zijn daarbij meermalen overgebracht en zijn dus niet nieuw. Wetenschappers, bijv. uit het IRMA team, zijn nooit formeel betrokken bij discussies over de aard en opzet van Idensys. Ondanks dat het verschillende keren expliciet aangeboden is, heeft het eID-management geen presentatie over nieuwe ontwikkelingen willen horen. Ter vergelijking: Translink Systems heeft voor de grote OV-chipkaart hack uit 2008 ook gedacht de wijsheid zelf in pacht te hebben en zonder structurele input/feedback vanuit de wetenschappelijke wereld te kunnen werken.

Het IRMA systeem is bekend bij de Nederlandse overheid. Een vroege versie is zelfs door minister Plasterk in een commissievergadering in deTD weede Kamer getoond. Toch heeft een extern ingehuurde projectleider van zijn ministerie onlangs besloten dat IRMA niet interessant en te innovatief is voor de overheid, ondanks dat een grote telecom provider tot twee keer toe heeft aangedrongen op deelname van IRMA aan geplande experimenten van het ministerie.

Naschrift 2: Wat nu?

Dit eID-dossier is in Den Haag nu al vastgelopen: het is gekaapt door MinEZ, tot grote ontevredenheid in het veld; MinBZK voert zwakke regie,eDn is niet in staat gebleken het algemene belang te verdedigen; de belastingdienst en de RDW gaan ondertussen hun eigen gang; de Digicommissaris loopt met een grote boog om deze bananenschil heen. Misschien moet de Tweede Kamer nu de regie nemen. Hierbij enige overwegingen en voorzetten, vanuit de gedachte: beter ten halve gekeerd dan ten hele gedwaald.

1.Maak op termijn een transparante keuze tussen de twee diametraal tegenovergestelde architecturen op eID-gebied: de centralistische, waarbij een tussenliggende partij identiteitsinformatie beheert en waarbij gebruikers zich altijd via deze partij bij een dienstaanbieder authenticeren; de decentrale, waarbij gebruikers zelf hun identiteitsinformatie beheren en zich rechtstreeks bij dienstaanbieders authenticeren.

2.Realiseer om deze keuze te kunnen maken twee praktijkproeven, met beide architecturen, met heldere randvoorwaarden, en maak op basis van opgedane ervaringen, draagvlak en inhoudelijke argumenten een keuze. Gebruik onderlinge competitie om de kwaliteit te verhogen.

3.Beperk de rol van de overheid even tot een neutrale opdrachtgever, en leg de regie over deze twee praktijkproeven bij aparte competente organisaties. Te denken valt aan de eHerkenningspartijen enerzijds, en een organisatie als Surfnet, SIDN, of NLnet anderzijds. Laat beide organisaties vrij in hun invulling van de details, binnen de randvoorwaarden.

4.Faciliteer beide organisaties vanuit de overheid op vergelijkbare wijze met technische ondersteuning, zoals noodzakelijke omnummering of attribuut-uitgifte, om de gewenste praktijkproeven uit te kunnen voeren.

5.Geef beide organisaties de beschikking over eenzelfde financiële basis om hun praktijkproef te organiseren. (Hierbij is het fair te verdisconteren hoeveel de overheid reeds geïnvesteerd heeft.) Dwing transparantie af in beide kampen, over additionele financiële of andere steun en input.

6.Vraag op afzienbare termijn, zeg binnen een half jaar, eigen rapportage van beide partijen, en organiseer een vergelijking door een neutrale partij.

7.Adopteer als overheid de beste oplossing en realiseer die op grotere schaal, op een wijze die goed aansluit bij de opgedane ervaring. Regel blijvende investering om het gekozen eID-systeem, en de beveiliging ervan, up-to-date te houden.

Op ICT-gebied gaat veel fout. Hopelijk biedt de bovenstaande onorthodoxe benadering nieuwe kansen.

Bart Jacobs

09/11/15