Een nuttige bescherming voor persoonsgegevens door systemen in de publieke sector is pseudonimisatie. Specifiek hebben we het over het bewaren van persoonsgegevens onder unieke codes in plaats van onder rijksregisternummers. Deze unieke codes – de pseudoniemen – zijn slechts met een sleutel terug om te zetten naar het rijksregisternummer. Om de veiligheid en het vertrouwen te maximaliseren is deze sleutel best enkel gekend door een partij die onafhankelijk is van het backend (opslag) systeem. Uiteenlopende backend systemen kunnen dus voor de bescherming van persoonsgegevens op eenzelfde pseudonimiseringsdienst beroep doen. 

Dit artikel bespreekt op hoog niveau zowel de interacties als de veiligheidseigenschappen van een dergelijke pseudonimiseringsdienst met een bijzonder hoog niveau van veiligheid. Het werd uitgedacht door Smals Research en gaat binnenkort live als eHealth dienst. 

Disclaimer: Omdat rijksregisternummers als term beter gekend zijn dan de ruimere categorie van INSZ-nummers, spreken we in dit artikel uitsluitend over rijksregisternummers, al vormt het type identifier geen enkele beperking.

Rollen en operaties

In een setting zonder pseudonimisering zijn er twee rollen: de owner die persoonsgegevens bewaart en de clients die requests naar de owner sturen. Hieronder staan drie eenvoudige voorbeelden die dit illustreren:

• Scenario 1: Een huisarts (client) vraagt aan de voorschriften-backend (owner) om een elektronisch voorschrift te registreren.
• Scenario 2: Een apotheker (client) vraagt voor een specifieke burger een voorschrift op aan de voorschriften-backend (owner).
• Scenario 3: Een arts (client) vraagt aan de voorschriften-backend (owner) om de elektronische voorschriften te bekijken die ze de dag ervoor uitgegeven heeft.

De derde rol is de pseudonimiseringsdienst die instaat voor de vertaling van het rijksregisternummer van de patiënt naar het overeenkomstige pseudoniem (pseudonymize operatie), of omgekeerd, van het pseudoniem naar het rijksregisternummer (identify operatie). Ook het rijksregisternummer of RIZIV-nummer van de arts kan op een gelijkaardige manier gepseudonimiseerd worden.

Bovendien zullen verschillende diensten ook met elkaar moeten kunnen communiceren. Een dienst op het eHealth platform zou bijvoorbeeld kunnen vragen aan de TherLink service of een patient een therapeutische relatie heeft met een bepaalde arts. Indien TherLink ook met pseudoniemen werkt, zal een pseudoniem van de ene dienst/owner omgezet moeten worden naar het pseudoniem van de andere dienst/owner (convert operatie). Om het identificatierisico zo klein mogelijk te houden is het immers aangewezen om pseudoniemen niet over meerdere diensten te hergebruiken.

De drie operaties die die pseudonimiseringsdienst moet ondersteunen zijn dus pseudonymize, identify en convert.

Interacties

Op hoog niveau moet alvast een keuze gemaakt worden tussen ofwel de relay modus ofwel de reply modus, die geïllustreerd worden in onderstaande figuur.

• De relay modus is de meest courante. Ze wordt toegepast zowel door healthdata.be, wat onderdeel uitmaakt van Sciensano, als in het pseudonimiseringssysteem bedacht door de Nederlande professor Verheul. In deze modus fungeert de pseudonimiseringsdienst als doorgeefluik: het ontvangt persoonsgegevens van de ene partij, doet er operaties op (bijvoorbeeld pseudonymize) en geeft het resultaat door aan de ontvangende partij.
• In de reply modus ontvangt de pseudonimiseringsdienst een request en stuurt het antwoord naar dezelfde partij terug. De aanvragende partij (requestor) kan bijvoorbeeld vragen om een pseudoniem om te zetten naar een rijksregisternummer (identify).

Reply modus en relay modus

Beide aanpakken hebben hun eigen uitdagingen en voordelen. Niettemin komt de reply modus beter tegemoet aan aan de noden van onze klanten:

• Het vermijdt een zware belasting van de pseudonimiseringsdienst wanneer grote hoeveelheden data betrokken zijn. In de reply modus ontvangt en verstuurt de pseudonimiseringsdienst immers enkel pseudoniemen en identifiers, niet de bijhorende eigenlijke persoonsgegevens, al dan niet in geëncrypteerde vorm.
• De reply modus heeft een minder intrusieve impact op bestaande interacties: zoals hieronder geillustreerd communiceren client en owner (of owner en owner) nog steeds rechtstreeks met elkaar en hoeven ze niet te vertrouwen op een intermediaire partij om de juiste data door te sturen naar de juiste partij over een veilig communicatiekanaal. De low-level interacties liggen dus dichter bij de business interacties.

De flows in de eerder geschetste scenario’s zien er dan uit zoals weergegeven in de drie onderstaande basisscenario’s, waarbij de dunne pijl geen rijksregisternummers of pseudoniemen van burgers bevat maar de dikke pijl wel. We hanteren hierbij een zeer eenvoudige regel: de partij die de interactie initieert is ook diegene die de pseudonimiseringsdienst contacteert.

Basisscenario 1: Een arts (client) vraagt aan de voorschriften-backend (owner) om een elektronisch voorschrift te registreren.

Basisscenario 2: Een apotheker (client) vraagt voor een specifieke burger een voorschrift op aan de voorschriften-backend (owner)

Basisscenario 3: Een arts (client) vraagt aan een de voorschriften-backend (owner) om de elektronische voorschriften te bekijken die ze de dag ervoor uitgegeven heeft.

Hoge veiligheidsgaranties

Om het veiligheidsniveau van de pseudonimiseringsdienst te verhogen stellen we hieronder een aantal veiligheidsverhogende maatregelen voor. Wanneer deze toegepast worden op de eerder getoonde basisscenario’s, krijgen we de drie figuren hieronder, waar we dadelijk dieper op in zullen gaan. Een sleutel naast een operatie betekent dat een geheime of private sleutel vereist is, een dobbelsteen dat de operatie probabilistisch is; het resultaat is telkens anders, ook bij dezelfde input.

High-security scenario 1: Een arts (client) vraagt aan de voorschriften-backend (owner) om een elektronisch voorschrift te registreren.

High-security scenario 2: Een apotheker (client) vraagt voor een specifieke burger een voorschrift op aan de voorschriften-backend (owner)

High-security scenario 3: Een arts (client) vraagt aan een de voorschriften-backend (owner) om de elektronische voorschriften te bekijken die ze de dag ervoor uitgegeven heeft.

Blinde pseudonimiseringsdienst

Een eerste maatregel is de blinde pseudonimiseringsdienst, die gerealiseerd wordt door de twee paarse operaties (blind en unblind). Het zorgt ervoor dat de pseudonimiseringsdienst niet langer de binnenkomende en uitgaande pseudoniemen en identifiers kan zien, waardoor een nieuwsgierige pseudonimiseringsdienst veel minder informatie kan verzamelen en dus minder vertrouwd hoeft te worden. Bemerk dat de eigenlijke voorschriftdata niet naar de pseudonimiseringsdienst verstuurd worden.

Confidentiële pseudoniemen

In de drie basisscenario’s is het telkens een zorgverstrekker (arts of apotheker) die een aanvraag stuurt naar de pseudonimiseringsdienst. Die zorgverstrekker (client) – of een eventuele hacker – krijgt dus ook telkens, na de unblind operatie, het pseudoniem te zien en kan dit dus koppelen aan een rijksregisternummer. Dit veiligheidsrisico wordt gemitigeerd dankzij confidentiële pseudoniemen (oranje), waarbij een extra encryptielaag garandeert dat dat zorgverstrekker nooit het pseudoniem te weten komt, gezien ze de decryptiesleutel niet kent.

In de voorgestelde flows kan een owner (backend) sowieso enkel haar pseudoniemen zien. In combinatie met de eigenschap van confidentiële pseudoniemen uit de vorige paragraaf krijgen we een situatie waarin noch de client noch de owner in staat zijn om rijksregisternummers te koppelen aan pseudoniemen of vice versa. We kunnen stellen dat de client en backend verziend, respectievelijk bijziend zijn; de eerste ziet enkel globale identifers (rijksregisternummers), de tweede enkel de lokale identifiers (dus de pseudoniemen). Op die manier worden de gevolgen bij ongeautorizeerde toegang tot een client of backend systeem beperkt.

Expliciete autorizatie

We dienen uiteraard te vermijden dat de – mogelijks gehackte – zorgverstrekker pseudoniemvercijferingen die ze ontvangt van ofwel de pseudonimiseringsdienst (scenario 1 & 2) of van de backend (scenario 3) later kan misbruiken voor ongeautoriseerde doeleinden. Een pseudoniemvercijfering die gecreëerd werd in het kader van de uitgifte van een nieuw voorschrift mag later bijvoorbeeld niet gebruikt worden – door vb. een hacker – voor het opvragen van alle voorschriften die ooit aan deze persoon uitgegeven zijn.

Dit is exact wat expliciete autorizatie verhindert. In de figuren wordt dit gerealiseerd met behulp van de blauwe operaties; in scenario’s 1 en 2 hecht de pseudonimiseringsdienst autorizatieregels (vb. expiration time) aan het pseudoniem voor het vercijfert wordt. Bij ontvangst verifieert de backend a.d.h.v. contextinformatie (vb. current time) of aan deze regels voldaan is. In scenario 3 is het de backend die de autorizatieregels aan het pseudoniem toevoegt en de pseudonimiseringsdienst die a.d.h.v context informatie verifieert. In ons voorbeeld wordt de geldigheidsduur van pseudoniemvercijferingen dus beperkt. Geavanceerdere regels zijn uiteraard mogelijk.

Dubbele pseudonimisatie

Ondanks de eerder besproken veiligheidsmaatregelen is het nog steeds mogelijk dat de pseudonimiseringsdienst op zijn eentje de volgende aanval uitvoert:

1. Het maakt een lijst van alle strings die de structuur van een rijksregisternummer hebben. Dat zijn er een paar tiental miljoen en kan dus vrij snel.
2. Voor elk van die strings doet het een pseudonymize operatie

De pseudonimiseringsdienst heeft nu een tabel bestaande uit een paar tiental miljoen koppels. Ongeveer 12 miljoen van die koppels bevatten een rijksregisternummer dat effectief toegekend is aan een in leven zijnde burger. Dat die dienst de koppeling kent tussen rijksregisternummer en pseudoniem is een risico. We kunnen beslissen om dit risico te aanvaarden en er dus op te vertrouwen dat de pseudonimiseringsdienst hier geen misbruik van zal maken.

Anderzijds kan dit risico ook gemitigeerd worden met behulp van dubbele pseudonimisatie (rood). Om een rijksregisternummer om te zetten in het finale pseudoniem, of, omgekeerd, om een pseudoniem terug om te zetten in een rijksregisternummer, zijn dan twee sleutels vereist: De ene is enkel gekend door de pseudonimiseringsdienst, de andere enkel door de owner. Dankzij deze eigenschap daalt het vereiste vertrouwen in de pseudonimiseringsdienst dus verder. De keerzijde is dat de owner (backend) nu een sleutel moet beveiligen en meer cryptografische operaties moet uitvoeren.

Samengevat

Door de eigenschappen blinde pseudonimiseringsdienst, confidentiele pseudoniemen, expliciete autorisatie en dubbele pseudonimisatie te combineren kunnen we garanderen dat de owner (backend) de enige entiteit is die de pseudoniemen te weten komt, terwijl de client (zorgverstrekker) de enige entiteit is die de rijksregisternummers te weten komt.

Bemerk dat de client van de zorgverstrekker geen long-term keys hoeft te beheren en telkens de dezelfde operaties doet: een blind en unblind met tussenin een call naar de pseudonimiseringsdienst. De complexiteit aan de kant van de zorgverstrekkers blijft dus beperkt.

Samengevat bieden deze vier eigenschappen ons de mogelijkheid om een zeer veilig, generiek toepasbaar systeem te bouwen voor pseudonimisatie van persoonsgegevens in rust, in transit en – in beperktere mate – in use.

Perspectieven

In deze sectie bespreken we twee – momenteel nog theoretische – scenario’s die kunnen inspireren voor de toekomst: 1) Het gebruik van de pseudonimiseringsdienst voor het kruisen van persoonsgegevens en 2) Een universum met meerdere pseudonimiseringsdiensten.

Kruisen van persoonsgegevens

In sommige use cases moeten persoonsgegevens afkomstig van verschillende databronnen gekruist en  gepseudonimiseerd worden. In een klassieke benadering gebeuren beide operaties door één en dezelfde entiteit, die dus een dubbele taak heeft: Eerst kruist het de ontvangen geïdentificeerde persoonsgegevens op basis van rijksregisternummers om vervolgens het resultaat te pseudonimiseren.

Ons voorstel realiseert een functiesplitsing (separation of duties) van deze taken: de pseudonimiseringsdienst is verantwoordelijk voor de pseudonimisering, een andere entiteit, die we de collector dopen, enkel voor het kruisen. Dat kruisen gebeurt niet langer op basis van rijksregisternummers, maar op basis van pseudoniemen. Rijksregisternummers blijven zo verborgen voor de collector, wat risico’s reduceert en dus de veiligheid verbetert. Bovendien maakt deze functiesplitsing het werk van de collector eenvoudiger.

Dit alles wordt geïlllustreerd in onderstaande figuur, waarbij er twee databronnen (clients) zijn, al kunnen dat er gerust meer zijn. In de figuur beschikken databron A en databron B respectievelijk over gegevens DataA en DataB over eenzelfde persoon met rijksregisternummer Identifier. Op basis van het pseudoniem is de collector (owner) in staat die data aan elkaar te koppelen, zonder ooit dit rijksregisternummer te weten te komen. De databronnen versturen zo de gegevens over heel wat burgers, samen met de vercijferde pseudoniemen, naar de collector, die instaat voor het kruisen.

Een aantal veiligheidseigenschappen van deze benadering zijn:

• De databronnen, de collector en de pseudonimiseringsdienst zijn respectievelijk verziend (ziet enkel rijksregisternummers), bijziend (ziet enkel pseudoniemen) en blind (ziet rijksregisternummers noch pseudoniemen). De pseudonimiseringsdienst is zelfs niet in staat verschllende blinderingen van hetzelfde rijksregisternummer aan elkaar te koppelen (onlinkbaarheid).
• De vercijfering (oranje) is probabilistisch, wat wil zeggen dat twee vercijferingen van hetzelfde pseudoniem – dus ook na de unblind operatie – niet aan elkaar te koppelen zijn zonder de decryptiesleutel die enkel de collector en pseudonimiseringsdienst kennen (onlinkbaarheid). Dit is relevant wanneer een aanvaller in staat is data in transit afkomstig van meerdere databronnen te onderscheppen.
• Er worden weliswaar geblindeerde identifiers naar de pseudonimiseringsdienst gestuurd, maar nooit de data zelf. Databronnen sturen hun data, over een beveiligd kanaal, rechtstreeks naar de collector, zonder intermediaire partij (de oranje pijl). De pseudonimiseringsdienst wordt bijgevolg niet geïmpacteerd door afspraken over de structuur van de uitgewisselde data (functiescheiding).
• Voor elke kruisingproject kan de pseudonimiseringsdienst een andere sleutel gebruiken, wat resulteert in onlinkbaarheid op basis van pseudoniemen bij de collector; deze is niet in staat om pseudoniemen van eenzelfde burger, maar uit verschillende projecten, aan elkaar te linken.  
• Mocht dit nodig zijn is een heridentificatie mogelijk, maar enkel mits medewerking van de pseudonimiseringsdienst, wat willekeur en misbruik tegengaat. De pseudonimiseringsdienst of de collector kan – mocht dit vereist zijn – de pseudonimiseringssleutel op een afgesproken moment verwijderen, waardoor heridentificatie langs deze weg onmogelijk wordt.

Dergelijke kruisingsprojecten zijn typisch batch-opdrachten die niet binnen seconden verwerkt moeten zijn, terwijl de eerder geschetste voorschriftscenario’s real-time uitgevoerd moeten worden. Om te vermijden dat extra capaciteit vereist is, zouden de kruisingsprojecten dus ‘s nachts gescheduled kunnen worden, wanneer er minder voorschriften verwerkt worden. De real-time opdrachten krijgen daarbij steeds een hogere prioriteit dan de batch opdrachten.

Bemerk wel dat deze aanpak enkel nuttig is indien alle databronnen autonoom kunnen bepalen welke records relevant zijn en welke niet. Dit is niet steeds het geval, zoals bijvoorbeeld in het datakruisingsproject dat goedgekeurd werd met beraadslaging 20/002 van 14 januari 2020, waarbij de Stichting Kankerregister enkel data mag aanleveren over burgers met Multiple sclerose (MS), maar zelf niet te weten mag komen wie MS heeft. Ook daarvoor heeft Smals Research een efficiënte en flexibele oplossing bedacht. Die oplossing is bovendien gedistribueerd, waardoor niet langer een pseudonimiseringsdienst nodig is om veilig te pseudonimiseren. Dit valt echter buiten de scope van dit artikel.

Een universum met meerdere pseudonimiseringsdiensten

In een ideale wereld maakt iedereen gebruik van één en dezelfde pseudonimiseringsdienst. Dit is helaas een onrealistische veronderstelling; in de praktijk zullen verschillende landen, regio’s, sectoren, … gebruik maken van een eigen pseudonimiseringsdienst.

Wanneer enkel identify en pseudonymize operaties vereist zijn, stelt zich geen enkel probleem. Evenmin stelt zich een probleem wanneer convert operaties gebeuren van pseudoniemen tussen owners die van dezelfde pseudonimiseringsdienst gebruik maken. Het kan echter voorkomen dat pseudoniemen geconverteerd moeten worden tussen owners aangesloten bij verschillende pseudonimiseringsdiensten.

Ook dit is mogelijk – mits bepaalde cryptografische parameters afgesproken worden – en wordt geïllustreerd in onderstaande figuur. Daarbij komt geen enkele pseudonimiseringsdienst informatie te weten over de identifiers of pseudoniemen. Onze security eigenschappen blijven dus behouden. Het mooie van de oplossing is dat er voor geen van beide owners iets verandert. Enkel de pseudonimiseringsdiensten interageren met elkaar.

Conversie van een pseudoniem m.b.v. twee pseudonimiseringsdiensten

Conclusies

De voorgestelde oplossing is een pseudonimiseringssysteem met extreem hoge veiligheidsgaranties, terwijl de complexiteit ervan beheersbaar blijft. In het bijzonder aan de kant van de clients blijft die zeer beperkt, wat een integratie van de oplossing in de bestaande client software, die door vele tienduizenden zorgverstrekkers in ons land gebruikt wordt, vergemakkelijkt. Bovendien worden bestaande interacties gerespecteerd, waardoor re-engineering van bestaande processen beperkt blijft.

De oplossing vermijdt heridentificatie van persoonsgegevens op basis van rijksregisternummers. Bemerk dat heridentificatie ook mogelijk kan zijn op basis van de data zelf, ook al zijn die enkel gekend onder een pseudoniem. In dat geval kunnen bijkomende veiligheidsmaatrgelen, zoals encryptie, zich opdringen.

Een initieel voorstel door Smals Research tot generieke pseudonimiseringsdienst werd in nauwe samenwerking met andere diensten binnen Smals verder verfijnd en uitgebreid en is daarmee afgestemd op de business noden. Smals research ontwikkelde zowel het concept als de Proof of Concept in Java; die laatste werd door eHealth gebruikt als inspiratie voor het bouwen van een eHealth service die in de komende maanden live zal gaan.

Het concept biedt bovendien perspectief voor zinvolle uitbreidingen, die toelaten om in de toekomst nog meer scenario’s te ondersteunen.

Ten slotte geven we mee dat Smals Research ook werkt aan een ander type pseudonimisatie, gericht op een andere set van use cases; structuurbehoudende pseudonimisatie heeft het voordeel dat pseudoniemen dezelfde structuur hebben als de identifiers, maar kan helaas niet dezelfde hoge security eigenschappen bieden.

Aarzel niet ons te contacteren bij interesse in deze of één van onze andere oplossingen voor het pseudonimiseren (en kruisen) van van persoonsgegevens.

---

Dit is een ingezonden bijdrage van Kristof Verslype, cryptograaf bij Smals Research. Het werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Bron featured image: Youngsang Hwang