💻 computer science

Privacy in Theory, Bugs in Practice: Grey-Box Auditing of Differential Privacy Libraries

Dit paper introduceert Re:cord-play, een nieuw gray-box auditraamwerk dat interne algoritmetoestanden inspecteert om praktische privacyfouten in differentieel-private bibliotheken te detecteren, wat resulteert in de ontdekking van 13 schendingen in 12 open-source implementaties.

Oorspronkelijke auteurs: Tudor Cebere, David Erb, Damien Desfontaines, Aurélien Bellet, Jack Fitzsimons

Gepubliceerd 2026-02-20

📖 6 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Tudor Cebere, David Erb, Damien Desfontaines, Aurélien Bellet, Jack Fitzsimons

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

De Kernboodschap: "De theorie is mooi, maar de praktijk zit vol gaten"

Stel je voor dat Differentiële Privacy (DP) een onbreekbare veiligheidskast is die je gebruikt om geheime gegevens (zoals medische dossiers of bankrekeningen) te beschermen. De wiskundige theorie zegt: "Als je deze kast gebruikt, is het onmogelijk om te achterhalen wie erin zit."

Maar in de echte wereld bouwen programmeurs deze kasten met code. En net als bij elke andere machine, zitten er soms verborgen gebreken in de constructie. Een klein lekje, een verkeerd schroefje of een slecht slotje kan betekenen dat de "onbreekbare" kast toch openbreekt.

Dit papier introduceert een nieuwe manier om deze kasten te testen, genaamd Re:cord-play.

Het Probleem: Waarom bestaande tests niet werken

Tot nu toe hadden programmeurs twee manieren om te controleren of hun veiligheidskast goed werkte:

De "Zwarte Doos" test (Black-box): Je gooit een paar gegevens in de kast, kijkt naar wat eruit komt en probeert te raden of er iets mis is.
- Het probleem: Dit is als proberen te horen of een slot goed zit door alleen naar de deur te kijken. Bij complexe kasten (met veel lagen) heb je duizenden pogingen nodig om iets te horen. Het is te duur en te traag.
De "Formele" test: Je laat een wiskundige de blauwdrukken van de kast controleren.
- Het probleem: Dit werkt alleen als de kast volledig opnieuw is gebouwd in een speciale taal. De meeste programmeurs gebruiken standaard Python of C++, dus dit is te lastig om te doen.

Het resultaat: Veel privacy-bibliotheken (software die privacy moet garanderen) hebben fouten, maar niemand ziet ze omdat de tests te moeilijk of te traag zijn.

De Oplossing: Re:cord-play (De "Twee Sporen"-test)

De auteurs van dit papier hebben een slimme, "grijze doos"-methode bedacht. Ze noemen het Re:cord-play.

Stel je voor dat je een dubbele filmset hebt. Je draait dezelfde scène twee keer, maar met een klein verschil:

Opname 1 (Record): Je draait de scène met een acteur die een rode hoed draagt.
Opname 2 (Replay): Je draait de scène opnieuw, maar nu met een acteur die een blauwe hoed draagt.

In een perfecte privacy-situatie zou de rest van de film (de camera, de belichting, de andere acteurs) exact hetzelfde moeten zijn, ongeacht de kleur van de hoed. De enige reden dat de film anders zou zijn, is als de regisseur (de privacy-mechanisme) bewust iets verandert op basis van de hoed.

Hoe werkt Re:cord-play?

De Opname (Record): De computer draait de privacy-software met Dataset A. Het houdt elke stap, elke berekening en elk getal nauwkeurig bij in een logboek.
De Wederopleving (Replay): De computer draait de software opnieuw, maar nu met Dataset B (die slechts één persoon verschilt van A).
- De truc: De computer "bevriest" de uitkomsten van de privacy-mechanismen. Als de software normaal gesproken een willekeurig getal zou genereren, gebruikt hij exact hetzelfde getal als in de eerste opname.
De Vergelijking: Nu kijkt de computer: "Zijn alle andere stappen in de software nog steeds identiek?"

Wat vinden ze?

Als de software op de tweede keer een andere route neemt (bijvoorbeeld: "Oh, de invoer is anders, dus ik doe nu iets anders"), dan is er een privacy-lek. De software heeft gekeken naar de privé-gegevens om een beslissing te nemen, wat niet mag.
Als de software zegt: "Ik gebruik een gevoeligheidsgraad van 10", maar de computer ziet dat de invoer eigenlijk 15 verschilt, dan is de berekening fout.

Het is alsof je twee identieke broers laat rennen. Als ze exact dezelfde route lopen, is alles goed. Als één broer plotseling een andere weg inslaat omdat hij een ander shirt draagt, dan is er iets mis met de instructies.

Wat vonden ze? (De "Bugs" in het wild)

De auteurs hebben 12 populaire softwarebibliotheken getest en 13 fouten gevonden. Hier zijn een paar voorbeelden, vertaald naar alledaagse taal:

De "Vergeten Clip" (SmartNoise SDK): Stel je voor dat je een meetlat gebruikt om te zien hoe hoog een persoon is, maar je vergeet de persoon eerst te "clippen" (zorgen dat niemand langer is dan 2 meter). Als er iemand van 3 meter in de dataset zit, springt de meetlat uit zijn verband. De software dacht dat ze veilig waren, maar de meting was onbeperkt groot.
De "Verkeerde Rekenmachine" (SmartNoise SQL): De software gebruikte een verkeerde formule om te berekenen hoeveel "ruis" (veiligheidsdekking) ze moesten toevoegen. Het was alsof ze dachten dat ze 1 euro nodig hadden voor beveiliging, maar in werkelijkheid hadden ze 100 euro nodig.
De "Geheime Knop" (Synthcity): De software keek naar een privé-gegeven om te beslissen welke knop ze moesten indrukken. Als de knop anders was, wist een hacker: "Ah, ze hebben een knop ingedrukt, dus die persoon zat in de dataset!" Dit is een direct lek.
De "Privé-Grootte" (Opacus): De software keek naar het totale aantal mensen in de dataset om haar instellingen te bepalen. Maar het aantal mensen is zelf ook privé-informatie! Het was alsof de slotenmaker zijn sleutel maakte op basis van hoeveel mensen er in het huis zaten, wat een lek in de beveiliging veroorzaakte.

Waarom is dit belangrijk voor jou?

Vroeger moesten programmeurs vertrouwen op de theorie: "De wiskunde zegt dat dit veilig is." Maar dit papier laat zien dat code schrijven anders is dan wiskunde maken. Zelfs de slimste programmeurs maken fouten.

Met Re:cord-play kunnen programmeurs nu:

Sneller testen: Het is net zo makkelijk als een standaard testje in hun software.
Preciezer zijn: Ze weten precies waar het lek zit (niet alleen "het werkt niet", maar "deze specifieke regel is fout").
Betrouwbare software bouwen: Door deze tests in hun dagelijkse werk te stoppen, kunnen ze voorkomen dat ze per ongeluk de privacy van mensen schenden.

Conclusie

Dit onderzoek is als een veiligheidsinspecteur die niet alleen naar de blauwdrukken kijkt, maar de machine ook echt laat draaien om te zien of er geen lekkende slangen zijn. Het laat zien dat we niet alleen moeten vertrouwen op mooie theorieën, maar ook moeten testen of de praktijk echt veilig is.

De auteurs hebben hun tool gratis openbaar gemaakt, zodat iedereen die privacy-software bouwt, deze "veiligheidsinspecteur" kan gebruiken om hun werk foutloos te maken.

Probleemstelling

Differentiële privacy (DP) is de de-facto standaard voor privacybeschermende data-analyse, maar de implementatie ervan in software is berucht om fouten. Hoewel de theoretische garanties wiskundig bewezen zijn, worden deze in de praktijk vaak ondermijnd door subtiele bugs in de code. Deze fouten ontstaan door:

Onjuiste berekening van gevoeligheid (sensitivity).
Data-afhankelijke pre- of post-processing.
Fouten in het samenstellen van privacybudgetten (composition).
Onveilige willekeurigheid (randomness) of floating-point kwetsbaarheden.

Bestaande verificatiemethoden zijn onvoldoende:

Formele verificatie: Te restrictief en vereist vaak het herschrijven van code in speciale domeinspecifieke talen (DSL's), wat een hoge drempel vormt voor bestaande Python- of C++-bibliotheken.
Zwarte-kast (Black-box) auditing: Statistische audits die alleen kijken naar input-output gedrag. Deze zijn vaak statistisch onhaalbaar voor complexe pipelines (vereisen te veel samples) en kunnen niet pinpointen waar in de code de fout zit, wat developers geen actiegericht advies geeft.

Er is een gat tussen de theoretische beloften en de praktische implementatie, en er ontbreekt een geautomatiseerd hulpmiddel dat fouten kan lokaliseren zonder de kosten van end-to-end auditing.

Methodologie: Re:cord-play en Re:cord-play-sample

Het paper introduceert een nieuw "grijze-kast" (gray-box) audit-paradigma dat de interne staat van DP-algoritmes inspecteert. De kernidee is dat DP-implementaties niet monolithisch zijn, maar bestaan uit een wisselwerking tussen data-afhankelijke privacy-primitieven en data-onafhankelijke controle-flow.

Het framework bestaat uit twee hoofdcomponenten:

1. Re:cord-play (Deterministische Verificatie)

Deze methode is gebaseerd op het principe van "record-and-replay" en neemt aan dat de onderliggende privacy-primitieven (zoals Laplace of Gaussian mechanismen) correct zijn geïmplementeerd.

Fase 1 (Record): Het instrumenteert het algoritme en voert het uit op een dataset $D$ . Het logt elke aanroep van een DP-primitief, inclusief de input, parameters, de staat van de pseudo-random number generator (PRNG) en de output.
Fase 2 (Replay): Het voert hetzelfde algoritme uit op een buurdataset $D'$ (die slechts één record verschilt). Cruciaal is dat de PRNG-staat wordt hersteld en de output van de DP-primitieven wordt "bevroren" (forced) om exact dezelfde waarde terug te geven als in Fase 1.
Verificatie:
- Invariantie: Als de controle-flow (bijv. welke if-tak wordt genomen) of data-onafhankelijke variabelen verschillen tussen $D$ en $D'$ ondanks dezelfde primitieve-outputs, is er sprake van een data-lek in de logica.
- Gevoeligheid: Het vergelijkt de empirische afstand tussen de inputs die naar de primitieven werden gestuurd met de gedeclareerde gevoeligheid. Als de afstand groter is dan toegestaan, is er een gevoeligheidsfout.

2. Re:cord-play-sample (Component-gewijze Statistische Audit)

Deze methode verwijdert de aanname dat de primitieven betrouwbaar zijn. Het isoleert elke privacy-primitief uit de pipeline en voert een statistische audit uit op dat specifieke onderdeel.

Het gebruikt de traces van Re:cord-play om de exacte inputs voor elke primitief te isoleren.
Voor elke primitief worden $N$ samples gegenereerd om de empirische outputverdeling te schatten.
Met Privacy Loss Distributions (PLD) wordt de privacyverlies voor elk component geschat en vervolgens samengesteld tot een eind-tot-eind $(\varepsilon, \delta)$ -bound.
Dit maakt audits computatie-efficiënter dan end-to-end black-box audits, omdat de dure pre-processing niet voor elke sample hoeft te worden herhaald.

Belangrijkste Bijdragen

Nieuw Audit-Paradigma: Introductie van een grijze-kast benadering die de interne staat inspecteert in plaats van alleen outputverdelingen te analyseren.
Concrete Foutdetectie: Het framework kan specifieke fouten detecteren zoals data-afhankelijke lekken in data-onafhankelijke code, verkeerde gevoeligheidsberekeningen en verkeerde noise-calibratie.
Open Source Framework: Het release van een Python-pakket dat naadloos integreert met bestaande testomgevingen (zoals pytest), waardoor privacy-testing een standaard onderdeel van de CI/CD-pijplijn kan worden.
Hybride Composities: Het ondersteunt het combineren van analytisch bekende PLD's (voor vertrouwde primitieven) en empirisch geschatte PLD's (voor onbetrouwbare componenten).

Resultaten en Evaluatie

De auteurs hebben 12 open-source DP-bibliotheken geaudit, waaronder SmartNoise SDK, Opacus, Diffprivlib, Synthcity, en MOSTLY AI. Ze ontdekten 13 privacy-overtredingen die de theoretische garanties ongeldig maakten. Enkele opvallende bevindingen:

SmartNoise SDK: Een bug in de covariantieberekening waarbij ongezuiverde data werd gebruikt in plaats van de gesanitized data, wat leidde tot een onjuiste gevoeligheidsschatting.
SmartNoise SQL: Een fout in de privacy-accountant waarbij de term $\log(1/\delta)$ ontbrak in de samenstellingsformule, wat resulteerde in veel te optimistische (en onveilige) privacygaranties.
Synthcity:
- Een invariantie-overtreding waarbij de output van een Exponentieel Mechanisme werd gebruikt om een data-afhankelijke if-statement te sturen.
- Een bug waarbij de noise-schaal nul kon worden, waardoor geen ruis werd toegevoegd.
Diffprivlib:
- Een gevoeligheidsfout in Lineaire Regressie waarbij alleen de ondergrens van de data werd gebruikt in plaats van het bereik.
- Een data-afhankelijke controle-flow in Logistieke Regressie waarbij de set van labels werd afgeleid uit de data, wat informatie lekt over de aanwezigheid van zeldzame klassen.
Opacus: Een fout waarbij de datasetgrootte (die privaat is onder het "add/remove" model) werd gebruikt voor normalisatie, wat de datasetgrootte lekt aan de optimizer.
MOSTLY AI: Dubbele uitgave van het privacybudget voor dezelfde kolom en data-afhankelijke vertakkingen die de aanwezigheid van bepaalde datapatronen onthullen.

Daarnaast bleek dat veel bibliotheken kwetsbaar zijn voor pathologische invoer (zoals NaN of ±∞), wat vaak leidt tot ongedefinieerd gedrag of datalekken. Google Differential Privacy was de enige bibliotheek die deze gevallen consistent correct afhandelde.

Betekenis en Conclusie

Dit paper demonstreert dat de correctheid van wiskundige afleidingen niet voldoende is voor veilige privacy-implementaties. De kloof tussen theorie en praktijk wordt vaak veroorzaakt door implementatiefouten in de integratie van primitieven.

De betekenis van dit werk ligt in:

Praktische Toepasbaarheid: Het biedt ontwikkelaars een snelle, goedkope en geautomatiseerde manier om privacyfouten te vinden, vergelijkbaar met een unit test.
Diagnostische Kracht: In tegenstelling tot black-box audits, kan het framework precies aangeven waar en waarom een fout optreedt (bijv. "de input voor dit mechanisme overschrijdt de gevoeligheid").
Veiligheid in de Softwareontwikkelcyclus: Door het open-source maken van het framework, wordt het mogelijk om privacy-audits te integreren in de CI/CD-pijplijn, waardoor fouten eerder worden opgespoord en gefixt.

De auteurs concluderen dat dit type "privacy debugger" essentieel is om te zorgen dat DP-software zijn theoretische beloften ook in de praktijk waarmaakt.