Wat je niet hebt kun je ook niet afgeven - Kentekenparkeren zonder dat de Belastingdienst mee kan kijken.

November 13, 2014
8

De gemeente Rotterdam wil op een privacy vriendelijkere manier kentekenparkeren aanbieden door de kentekens slechts drie maanden opslaan. Dit in plaats van zeven jaar, opgelegd door een convenant met de Belastingdienst. Om onder dat convenant uit te komen vraagt de gemeente toestemming aan het kabinet voor deze kortere bewaartermijn. Dit is een nobel streven, maar ik vrees dat de gemeente lang kan wachten. En ze hoeft helemaal niets aan het kabinet te vragen. Door kentekenparkeren net iets anders in te richten, is de privacy prima geregeld en heeft de Belastingdienst het nakijken.

Het idee bij kentekenparkeren is dat in een database bijgehouden wordt welk kenteken is aangemeld voor parkeren, en of daar voor betaald is. De informatie in die database komt uit verschillende bronnen. Bijvoorbeeld door bij een parkeerautomaat je kenteken in te voeren en te betalen. In sommige parkeergarages wordt bij het binnenrijden je kenteken gescand, en bij het uitrijden gecontroleerd of voor dat kenteken betaald is. Er zijn ook apps voor. Parkeercontroleurs scannen het kenteken van geparkeerde voertuigen en controleren of het kenteken geregistreerd staat in de database, en of deze voldoende betaald heeft om hier nog geparkeerd te staan. Het zijn de gegevens in deze database die de Belastingdienst graag wil hebben, om te controleren of leaserijders niet oneigenlijk privé gebruik maken van hun leaseauto.

Maar het kan ook anders.

In plaats van direct het kenteken op te slaan in de database, kun je ook een zogenaamde hash van de kenteken informatie opslaan. Die hash wordt berekend door een zogenaamde hash functie, die lastig te inverteren is. Gegeven een kenteken als invoer, rekent een hashfunctie de bijbehorende hash uit. Deze is uniek voor ieder kenteken. Maar gegeven de hash is het veel werk om het oorspronkelijke kenteken dat er bij hoort terug te vinden. Je moet eigenlijk alle mogelijke kentekens proberen om de match te vinden.

Dat maakt zo'n database dus onbruikbaar voor de Belastingdienst. Maar voor het bijhouden van wie er betaald heeft om te parkeren en om dat te controleren, m.a.w. alle 'gewone' functies van een parkeer controle systeem, maakt het gebruik van zo'n hash helemaal niets uit. Bij het parkeren voert de automobilist gewoon zijn kenteken in. Die wordt meteen gehasht (het kenteken zelf wordt vergeten) en opgeslagen in de database. Voor controle voert de parkeer controleur een kenteken in van een auto die geparkeerd staat. Ook die wordt meteen gehasht, en een match wordt gezocht in de database.

Kenners zullen terecht opmerken dat het aantal mogelijke kentekens niet heel groot is, en dat de Belastingdienst dus eenvoudig één keer een (behoorlijk grote) tabel kan maken waarin voor ieder kenteken de bijbehorende hash staat. Met die tabel kunnen ze alsnog de hash gebruiken om het kenteken terug te vinden. Maar dit kan een stuk lastiger gemaakt worden door per gemeente, per bedrijf, of per dag een willekeurige salt toe te voegen voordat de hash voor een kenteken wordt uitgerekend. Die salt is dan, net als de hash functie, gewoon publiek. Maar de belastingdienst moet dan voor iedere salt een nieuwe tabel uitrekenen. Dat is een stuk meer werk.

Al met al een mooi voorbeeld van het feit dat datgene wat je niet hebt, je ook niet kunt afgeven als daar om gevraagd wordt. Een goed beschermingsmiddel tegen een steeds nieuwsgieriger overheid. In dit voorbeeld betreft het kentekens. Maar hetzelfde idee kun je gebruiken om géén contact gegevens, géén telefoonnummers, géén emails etc. op te slaan.

Update 13-11-2014: Ik werd er terecht door een lezer op gewezen dat de situatie iets gecompliceerder ligt dan ik hier schets. Zo was ik vergeten expliciet te zeggen dat het van belang om voor de hash functie een Key Derivation Function te gebruiken. Dat is een functie die (door een bepaalde hash functie een groot aantal keren te herhalen) veel tijd kost om uit te rekenen. Op die manier is het online uitproberen van alle mogelijke kentekens (224) voor een bepaalde hash waarde niet langer realistisch.

Maar zelfs dan is het zo dat de database met hashes die de parkeer systemen bijhouden nuttige informatie bevat voor de Belastingdienst. Ze kan immers nog steeds deze database opvragen en haar eigen lijst van kentekens van lease rijders hier tegen controleren. De niet-lease-rijders blijven zo echter wel buiten schot. En dat is in ieder geval iets.

In case you spot any errors on this page, please notify me!
Or, leave a comment.
Peter
, 2014-11-13 15:59:58
(reply)

Wat mij altijd enorm stoort aan dit soort voorstellen is dat het veelal op vertrouwen aankomt: vertrouwen dat de leverancier dit soort maatregelen neemt, vertrouwen dat dat ook correct en veilig geimplementeerd is, en vertrouwen dat men ook doet wat men zegt dat men doet, en niet in de toekomst toch gegevens gaat bewaren.

Als gewone burger, nee, zelfs als technisch onderlegde burger, kun je dit onmogelijk controleren. Een onveilig, privacyschendend apparaat ziet er precies hetzelfde uit als een superveilig privacybeschermend apparaat. Je voert inderdaad simpelweg je kenteken in maar je hebt geen idee wat het apparaat daar vervolgens mee doet.

Het beste systeem is een systeem wat overduidelijk geen gegevens opslaat. Zoals je zegt, als jij het systeem de gegevens niet geeft KAN deze de gegevens ook niet opslaan. De oude parkeerautomaten met kaartjes werkten eigenlijk prima. Als je je parkeertijd wil kunnen verlengen door niet terug te hoeven gaan kun je ook een kaartje met een eenmalig nummer uitprinten, waar een QR-code opstaat waarmee je met een app de parkeertijd kunt verlengen. Dat kaartje kan vervolgens achter de ruit, zoals vroeger met het ouderwetse systeem.

admin
, 2014-11-13 16:11:11
(reply)

Leuk alternatief! Zoals je terecht opmekrt is aan de buitenkant van een systeem niet te zien of die privacy vriendelijk is of niet. In dit specifieke geval kun je d.m.v. een geprint parkeerkaartje (in feite een soort analoge stap) inderaad fysiek uitsluiten dat het parkeer systeem kentekens verwerkt. Door die analoge stap is dat voor iedereen direct controleerbaar. Veel systemen hebben niet zo’n voor de hand liggende analoge stap. Daar zullen we op een andere manier ervoor moeten zorgen dat mensen er wel op kunnen vertrouwen (en dat ook kunnen controleren!) dat hun privacy gewaarborgd blijt.

Rob Meerwijk
, 2014-11-18 14:09:24
(reply)

Beste Peter,

Wij hebben onze processen en systemen extern laten auditen tegen de 5 voorwaarden van het CBP voor anonieme verwerking. Wij kunnen onszelf daarom positioneren als een Trusted Third Party.

Daarmee borgen wij anonieme verwerking.

Mvgr.

Rob Meerwijk

Jeroen
, 2014-11-14 08:49:05
(reply)

Het lijkt me ook belangrijk om een salt toe te voegen, zodat elke kenteken database unieke resultaten heeft. Anders kan de belastingdienst een keer veel moeite steken in een rainbowtabel en daarna vrolijk door matchen.

Jeroen
, 2014-11-14 08:54:51
(reply)

(Dat zit natuurlijk in de KDF, maar handig om wel duidelijk te maken)

Rob Meerwijk
, 2014-11-18 13:53:27
(reply)

De hierboven beschreven oplossing heb ik op de ochtend van de publicatie van dit artikel aan Jaap Henk Hoepman toegelicht op het Deloitte evenement Privacy with a view. Wij hebben deze oplossing werkend en klaar voor productie. Een bronvermelding was aardig geweest. Bij deze: www.pseudonimiseer.nl

admin
, 2014-11-18 14:09:05
(reply)

Voor de duidelijkheid. Ik had dit verhaal al in de trein op weg naar het Privacy with a view event geschreven. Inderdaad vertelde Rob tijdens de lunch van dat event over hun systeem. Een mooi voorbeeld van een bizar toeval. Vandaar dat ik niet de bron vermeldt heb; het was namelijk niet mijn bron.

Rob Meerwijk
, 2014-11-18 14:14:35
(reply)

Dan is het misschien niet eens zo’n bizar toeval. De belastingdienst en de kentekens zijn tamelijk hot op dit moment. Was in ieder geval een leuk gesprek vond ik!