Yao gaf toen het volgende voorbeeld. Twee miljonairs – vandaag zouden we eerder spreken over miljardairs – willen weten wie de rijkste is, zonder hun exacte rijkdom of zelfs maar indicaties daarvan aan de andere of aan een derde partij prijs te geven. Beide partijen willen dus weten of wealth₁ < wealth₂ waar of fout is, zonder dat er voor de rest informatie lekt, dus zonder dat de ene miljonair verdere informatie over wealth₁ prijsgeeft en zonder dat de andere verdere informatie over wealth₂ prijsgeeft.

Lange tijd bleef SMC een louter academische aangelegenheid met enkel toy-examples zoals hierboven. Het was (en is) immers erg moeilijk om SMC in de praktijk te brengen, onder meer door de dramatische impact op de efficiëntie en de intensieve communicatie tussen de betrokken partijen. 

Ondertussen zijn we ongeveer 40 jaar verder en is er heel wat onderzoek verricht rond SMC – het blijft trouwens een zeer actief onderzoeksdomein -, waarbij protocollen ontwikkeld werden die efficiënter zijn, die andere veiligheidseigenschappen hebben, die drie of meer partijen toelaten, etc. Daardoor duiken hier en daar – zij het momenteel nog in beperkte mate – praktische SMC toepassingen op.  Toch blijft de generieke SMC technologie, zoals die door Yao geïntroduceerd werd, in vele gevallen weinig praktisch.

Daarom werden en worden specifiekere protocollen ontwikkeld zoals oblivious transfer, wat toelaat dat een partij een specifiek record uit een lijst opvraagt bij een andere partij, zonder dat die laatste te weten komt het welke, wat handig kan zijn voor bijvoorbeeld politiediensten die elders informatie opvragen over verdachte burgers. Een ander voorbeeld is private set intersection (PSI), waarbij een partij te weten komt over welke items (vb. burgers of ondernemingen) een andere partij eveneens een dossier heeft, waarbij er verder geen data lekt. Ook onze eigen oblivious join, om data afkomstig van meerdere bronnen voor onderzoeksdoeleinden te kruisen en te pseudonimiseren, is zo’n specifiek protocol. In de academische crypto-wereld slaat SMC doorgaans enkel op de generieke technologie, al merken we dat daarbuiten ook de meer specifieke protocollen onder de SMC vlag geplaatst worden.

In de praktijk

SMC wordt hier en daar reeds in de praktijk gebruikt, zoals blijkt uit de drie onderstaande cases.

De bekendste en misschien ook de eerste reële toepassing van (generieke) SMC wordt al sinds 2008 gebruikt en wordt geregeld ingezet voor Deense suikerveilingen. Het is een dubbele veiling, waarbij zowel kopers als verkopers bieden. De veiling, die zonder centrale partij verloopt, moest voldoen aan strikte privacy vereisten, waarbij de biedingen confidentieel blijven. De veiling wordt uitgevoerd als een 3-party SMC tussen 1) vertegenwoordigers van Danisco, de enige suikerbietenverwerker in Denemarken, 2) de boerenvereniging (DKS) en 3) de onderzoekers (SIMAP).

Ons tweede voorbeeld is Sharemind. Het wordt commercieel aangeboden en gebruikt voor analyses op gevoelige gegevens afkomstig van verschillende partijen. Die partijen kappen elk afzonderlijk hun data in stukjes die afzonderlijk geen informatie bevatten en uploaden een derde van de stukjes data naar elk van drie verschillende servers. Dit gebeurt op zo’n manier dat de data confidentieel blijft voor de individuele servers, weliswaar onder de veronderstelling dat deze niet samenspannen. Om een query uit te voeren, zullen de drie partijen en de vraagsteller (de onderzoeker) met elkaar interageren (het SMC protocol), waarbij de vraagsteller – en enkel de vraagsteller – toegang krijgt tot het uiteindelijke resultaat door de antwoorden van de drie servers te combineren. Om de efficiëntie en governance te verbeteren, wordt Sharemind ook aangeboden in één enkele appliance, waarbij gebruik gemaakt wordt van hardware (Intel SGX) om de drie zones van elkaar te scheiden. Sharemind heeft zijn eigen taal voor het doen van analyses. We geven ook nog mee dat Sharemind heel wat verschillende cryptografische bouwstenen combineert.

Unbound is ons derde voorbeeld. Het lost met SMC het probleem op van de gecompromitteerde sleutel. De veiligheid van cryptografische operaties (encryptie, decryptie, ondertekenen, …) steunt immers op de veronderstelling dat de geheime/private sleutel ook effectief geheim/privaat blijft. In de praktijk is dit niet steeds even vanzelfsprekend. Unbound reikt een oplossing aan waarbij de sleutel opgesplitst is in twee deeltjes die door verschillende partijen bewaard worden. Wanneer een deeltje gecompromitteerd is, kan de hacker daar nog steeds niets mee aanvangen. Dit verhoogt aanzienlijk de veiligheid, maar impliceert wel dat een cryptografische operatie enkel mogelijk is met medewerking van de partij die het andere deel van de sleutel heeft. De cryptografische operaties worden uitgevoerd m.b.v. SMC waarbij de twee sleuteldeeltjes nooit samenkomen. Unbound biedt in zijn producten ondersteuning voor zowel symmetrische (AES) als publieke sleutelcryptografie (vb. RSA).

Ten slotte kan SMC gebruikt worden voor veilige machine learning, maar daarover meer in een toekomstige blogpost. Dit lijkt zich nog meer in de onderzoeksfase te bevinden.

Initiatieven in overheidscontext (NL)

Recentelijk zien we hier en daar proof of concepts en piloten opduiken in overheidscontext. Nederland zet duidelijk in op SMC in zijn meer algemene definitie waarin dus ook meer specifieke protocollen vervat liggen. Uit een recent en inspirerend rapport van de Nederlandse TNO (Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek ) blijkt alvast dat ze heel wat potentieel zien binnen overheidscontext:

Er zijn ontzettend veel toepassingsmogelijkheden voor privacyverbeterende technieken zoals MPC en FL [Federated Learning]. Zo kan de effectiviteit van de zorg vergroot worden door op een privacy vriendelijke manier inzichten uit patiëntdata te verkrijgen. De groeiende financiële criminaliteit kan ingedamd worden door het veilig koppelen van gevoelige data van verschillende financiële organisaties. Daarnaast kan de overheid haar dienstverlening verbeteren door privacy respecterende samenwerkingen tussen verschillende overheidsinstanties.

We blijven even stilstaan bij een case uit de Nederlandse overheidscontext waarover we toch wat – zij het beperkt – technische informatie konden vinden. In Nederland vormt de AOW uitkering een basispensioen. Indien dit onder het bestaansminimum valt, hebben gepensioneerden recht op een aanvulling (de AIO). 34.000 (48%) tot 50.000 (56%) van de huishoudens met een inkomen onder het bestaansminimum maakt hier geen gebruik van. De SVB, de instelling verantwoordelijk voor die AOW, heeft geen toegang tot gegevens over sociale uitkeringen en pensioenen (gekend door het UWV) en kan dus niet nagaan wie er AIW-gerechtigd is. Dit tracht men in Nederland in een piloot op te lossen m.b.v. homomorfe encryptie (zie verder) om te komen tot een SMC protocol. Toch lijkt het op basis van de beschikbare informatie voor uw nederige auteur logischer om in dit geval gebruik te maken van de eerder vermeldde private set intersection (PSI).

Ook in Belgische overheidscontext schuilt er ongetwijfeld heel wat potentieel. Smals Research wil dit samen met u exploreren. Aarzel daarom niet contact met ons op te nemen.

We vermelden ook graag dat de COSIC groep aan de KU Leuven wereldwijd aan de top staat wat betreft SMC onderzoek. Dit onderzoek resulteerde in een uitgebreide, door hen ontwikkelde library die SCALE-MAMBA gedoopt werd. Een ander veelbelovend COSIC project is JANA:

Jana aims to provide practical private data as a service to protect subject privacy while retaining data utility to analysts. 

Relatie tot andere technologieën

SMC laat toe om zonder centrale partij, dus gedistribueerd berekeningen te doen. Wat is dan het verschil met blockchain-technologie? In een klassieke blockchainbenadering, wordt alle input nodig voor de berekeningen op de blockchain geplaatst en dus gedeeld met andere participanten in het blockchain netwerk. Die participanten doen vervolgens allen exact dezelfde berekeningen op die data. Gegeven dit basisprincipe is het niet altijd makkelijk om een blockchain benadering te verzoenen met strenge privacyvereisten. Bij SMC, daarentegen, staan confidentialiteit en privacy centraal. Blockchaintechnologie blinkt wel uit om informatie onweerlegbaar en zonder centrale partij te registreren. Het sleutel(werk)woord bij MPC is berekenen, het sleutelwoord bij blockchain is registreren.

Homomorfe encryptie (HE) is een cryptografische techniek om berekeningen op een veilige manier te outsourcen naar een centrale partij (vb. naar de public cloud), en is daarmee op functioneel vlak een alternatief voor SMC. HE laat toe dat een centrale partij berekeningen doet op data zonder toegang te krijgen tot die data zelf. De centrale partij doet daarbij berekeningen op de vercijferde gegevens, waarbij het resultaat opnieuw een cijfertekst is. Bijvoorbeeld enc(5) * enc (3) = enc(15). De centrale partij doet in dit geval een vermenigvuldiging, maar het komt noch de waarden 5 en 3 (input) noch de waarde 15 (output) te weten.

Homomorfe encryptie kan, net zoals SMC, dezelfde berekeningen als een klassieke computer (de Turingmachine) ondersteunen. In dat geval speken we van full homomorphic encryption (FHE), waarvoor een eerste concrete schema pas relatief recent – in 2009 – voorgesteld werd. FHE is weliswaar een pak minder efficiënt en daardoor –  veel meer nog dan SMC – een theoretisch gegeven. In het boek “A Pragmatic Introduction to Secure Multi-Party Computation” uit 2017 schrijven de auteurs:

Hoewel er recent veel belangstelling is geweest voor het implementeren van FHE-schema’s […] blijft het bouwen van veilige, inzetbare, schaalbare systemen met FHE een ongrijpbaar doel. [..] State-of-the-art FHE-implementaties zijn duizenden keren langzamer dan two-party en multi-party secure computation in typische toepassingen en instellingen die in de literatuur worden overwogen.

Toch mogen we niet vergeten dat beperktere vormen van HE onmisbaar zijn in de cryptografie ter ondersteuning van andere cryptografische bouwblokken zoals…  bepaalde SMC protocollen! 

We geven ten slotte nog mee dat sommige generieke SMC protocollen onder meer gebruik maken van vormen van het reeds aangehaalde oblivious transfer. 

Conclusie

SMC was lange tijd een eerder academisch curiosum, maar ondertussen hebben de eerste concrete toepassingen reeds het licht gezien. We bevinden ons weliswaar nog in een vroeg stadium om SMC in de praktijk te brengen.

Toch lijkt er heel wat potentieel in de technologie te zitten. Het is echter niet steeds eenvoudig om de juiste technologie te selecteren. Er zijn verschillende generieke SMC protocollen, en er zijn talrijke voorstellen voor meer specifieke SMC protocollen. COSIC biedt alvast ondersteuning bij het selecteren van een generiek SMC raamwerk.

We kijken in elk geval al uit naar uw suggesties om samen met u een concrete overheidscase uit te werken.

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.

Bronvermelding foto
20111005_Ozark Henry Quatre Mains @ Arenberg by Tom Van Ghent. Published on Flickr under creative commons.

Het spanningsveld

Er wordt regelmatig vanuit justitie onderzoek gevoerd naar specifieke burgers, bijvoorbeeld in het kader van terrorismebestrijding. Persoonsgegevens die beheerd worden door derden moeten daarbij opgevraagd kunnen worden. Denk daarbij bijvoorbeeld aan metagegevens over telefoongesprekken gekend door telecomoperatoren of aan de verschillende officiële verblijfplaatsen doorheen de tijd, wat gekend is door het Rijksregister.

In een traditionele benadering vraagt justitie aan een organisatie om gegevens x, y en z over een specifieke burger aan te leveren. Er zijn echter twee bezwaren tegen een dergelijk naïeve benadering. Ten eerste is de privacy van de burger geschaad. Elke organisatie die informatie over hem of haar moet aanleveren komt immers te weten dat er een onderzoek loopt naar deze persoon. Dit kan risico’s inhouden. Een tweede bezwaar dat daaruit voortvloeit is dat dit de confidentialiteit van het onderzoek kan schaden. Er zijn dus goede redenen voor een andere benadering.

Deze zou eruit kunnen bestaan dat justitie gegevens x, y en z vraagt, niet enkel over Kristof Verslype, maar over alle burgers geboren in 1982, of nog extremer, over alle burgers tout court. De geconsulteerde organisaties zullen op die manier inderdaad de identiteit van de betrokkene niet te weten komen, maar anderzijds is er wel mogelijks sprake van een disproportionele verwerking van persoonsgegevens door justitie en moeten we justitie vertrouwen dat het de nodige procedures in acht neemt om alle records, behalve het relevante, onmiddellijk na ontvangst te verwijderen.

Er is dus een spanningsveld tussen enerzijds de privacy van de burger en de confidentialiteit van het onderzoek ten aanzien van de geconsulteerde organisaties en anderzijds de proportionele verwerking van persoonsgegevens door justitie. Dit spanningsveld lijkt op het eerste gezicht niet op te lossen.

Wat is Oblivious Transfer (OT)?

Gelukkig biedt cryptografie een krachtig hulpmiddel genaamd oblivious transfer (OT), of, vrij vertaald, vergeetachtige verzending. Het laat toe dat een ontvanger (zoals justitie) toegang krijgt tot een zelf gekozen record uit een set van records die door de verzender (zoals de telecomoperator) gekend zijn. De ontvanger krijgt slechts toegang tot dit ene record. De zender weet niet hetwelke. De zender komt enkel te weten dat de ontvanger toegang gekregen heeft tot één record uit de vooraf bepaalde set.

Oblivious transfer werd voor het eerst – in een wat zwakkere vorm – beschreven in 1981 en er is sindsdien veel onderzoek naar gebeurd in de academische wereld. Ondertussen is het – volgens de inschatting van de auteur – voldoende rijp om ook in overheidscontext gebruikt te worden. Het bestaat in verschillende varianten, waaronder 1 uit 2 oblivious transfer, 1 uit n oblivious transfer en k uit n oblivious transfer.  In de eerste variant krijgt de ontvanger toegang tot één uit een set van twee records. In de tweede en derde categorie krijgt de ontvanger toegang tot respectievelijk 1 en k records uit een set van n records. Het idee is vrij eenvoudig; de zender vercijfert alle records in de set, verstuurt alle vercijferde records naar de ontvanger, waarbij het oblivious transfer protocol cryptografisch (wiskundig) afdwingt dat de ontvanger er maar 1 (of k) kan decrypteren.

Eerste resultaten

Smals Research heeft op basis van twee academische papers (deze en deze) een eigen 1 uit n oblvious transfer Java library geschreven, gezien er voor zover wij weten nog geen dergelijke library publiek beschikbaar is. Vervolgens hebben we de performantie getest op een standaard laptop (Lenovo Thinkpad L570, Win 10, Intel Core i5-6300 CPU @ 2,40Ghz, 16GB), waarbij de gegevens zich reeds in het intern geheugen bevinden en er 256 bit security gegarandeerd wordt.  De rekentijd bij records van ongeveer 20 en 100KB en bij setgroottes van 1000, 10 000 en 25 000 wordt weergegeven in onderstaande tabel. Bemerk dat er wellicht nog ruimte is voor efficiëntiewinsten.

Indien een ontvanger toegang wil tot één record uit een set van 1000, waarbij het gemiddelde record 20KB groot is, zal er logischerwijs 20MB verstuurd moeten worden per query. Daarnaast zal de zender zo’n 0,7 seconden rekenwerk hebben, voornamelijk om alle data te vercijferen, terwijl de ontvanger 0,15 seconden zal moeten rekenen. 

Stel dat een organisatie over elke Belg een record heeft, dan betekent dit dat er ongeveer 11 350 000 records zijn. Uit bovenstaande blijkt dat een setgrootte van een paar miljoen toch niet haalbaar is. Idealiter delen we de bevolking dus op in verschillende sets die allen ongeveer even groot zijn. Deze opdeling kan in principe vrij eenvoudig door bijvoorbeeld alle rijksregisternummers met dezelfde minst beduidende decimalen (of bits) samen te nemen. 

Indien justitie informatie nodig heeft over de burger met rijksregisternummer 83.03.20-999.68, dan kan het bijvoorbeeld aan een aanleverende organisatie exact één record vragen uit de set van alle records waarvan het rijksregisternummer eindigt op ‘968’. Die set zal bestaan uit naar schatting 11 000 à 12 000 records. De aanleverende organisatie komt enkel te weten dat justitie toegang krijgt tot exact één record uit deze set.

Alternatief scenario voor grote sets

Een alternatieve aanpak voor grote datatsets is geïllustreerd in vier stappen in onderstaande figuur. De zender vercijfert op voorhand alle records, elk met een aparte, slechts door de zender gekende, symmetrische sleutel (stap 1). Dit kan erg efficiënt. Alle 11 350 000 vercijferde records
(alsook eventueel latere updates) worden vervolgens naar de ontvanger gestuurd (stap 2). De ontvanger beschikt zo over een volledige, weliswaar vercijferde, kopie van de gegevensset. Om toegang te krijgen tot een specifiek record wordt het oblivious transfer protocol uitgevoerd, niet zoals daarnet op de records zelf, maar op de bijhorende symmetrische sleutels (stap 3). Eén zo’n sleutel is (typisch) slechts 32 bytes groot, wat maar een fractie is van de grootte van de records zelf. Daardoor wordt het mogelijk een setgrootte van 11 350 000 te nemen bij het uitvoeren van het oblivious transfer protocol. De ontvanger krijgt zo toegang tot één van de 11 350 000 sleutels, waarmee vervolgens exact één record gedecrypteerd kan worden (stap 4). Bij een dergelijke uitvoering van het oblivious transfer protocol wordt zo’n 363MB, voornamelijk vercijferde sleutels, doorgestuurd, moet de zender een kleine 80 seconden rekenen, en de ontvanger 0,24 seconden (met onze eerder vermelde Lenovo L570).

De testresultaten van beide geschetste scenario’s geven in elk geval aan dat het gebruik van oblivious transfer haalbaar is in de geschetste context, dus voor het opvragen van gegevens over burgers in het kader van een onderzoek.

Kwantumresistente Oblivious Transfer

Toch is het niet onbelangrijk te vermelden dat onze implementatie steunt op, net zoals quasi alle publieke sleutelcryptografie vandaag, assumpties uit de klassieke cryptografie. Dergelijke assumpties zullen niet langer geldig zijn eens er voldoende sterke quantumcomputers beschikbaar zijn. Bijgevolg kan vanaf dan ook het geïmplementeerde OT protocol niet langer als veilig beschouwd worden. Wetenschappers werken ondertussen gelukkig wel aan kwantumresistente OT (QOT) protocollen (zoals vb. dit werk), die helaas ook wel beduidend minder efficiënt zijn. Schattingen wanneer een dergelijke kwantumcomputer gerealiseerd zal worden lopen uiteen van 10 tot 50 jaar, wat dus toch niet genegeerd kan worden bij het verwerken van gevoelige persoonsgegevens. Vandaar dat het toch noodzakelijk blijft dat de ontvanger de vercijferde records ook verwijderd en niet een aantal decennia bewaart. Dit zou gecontroleerd kunnen worden door een toezichthoudende autoriteit. QOT is dus op termijn een elegantere en robuustere oplossing die bij voldoende interesse vanuit onze klanten dan ook door Smals Research onderzocht zal worden.

Andere toepassingsmogelijkheden en conclusies

Ten slotte geven we nog mee dat OT een bouwblok is in diverse andere cryptografische protocollen, onder meer voor het simultaan ondertekenen van contracten over het internet (zie vb. dit werk), waarbij ofwel alle betrokkenen hun akkoord geven ofwel geen enkele. OT is eveneens een bouwblok voor multi-party computation (MPC), waarbij zonder centrale vertrouwde partij berekeningen gedaan worden op invoer afkomstig van verschillende deelnemers. De invoer van de verschillende deelnemers blijft geheim, maar iedereen leert wel de uitvoer.  Een groep individuen kan met behulp van MPC bijvoorbeeld het gemiddeld loon van de individuen berekenen terwijl elk van hen hun exacte loon verborgen kan houden.

Concluderend kunnen we stellen dat oblivious transfer zeer nuttige toepassingen heeft en dat het in de praktijk inzetbaar is. Het integreren van OT in bestaande toepassingen is trouwens een voorbeeld van het in de GDPR gepromootte principe van privacy by design. Ten slotte, wat voor alle publieke-sleutel cryptografie geldt, geldt ook voor oblivious transfer: als er ooit een kwantumcomputer komt, dan zijn we beter voorbereid.

Aarzel niet ons te contacteren om mogelijke toepassingen binnen de context van de overheid in België met ons te bespreken!

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