7a Risiko einschätzen
In dieser Komponente werden drei Methoden vorgestellt, um das Privatsphärerisiko eines Mobilitätsdatensatzes zu analysieren. Die Anwendung dieser Methoden beantwortet die Fragen, welches Risiko besteht und welcher Bedarf für weitere Maßnahmen zur Risikokontrolle existiert.
Offenlegungsszenarien
Szenarien erstellen
Im Datenaudit wurden bereits Szenarien genutzt, um einen Überblick über den voraussichtlichen Ablauf des Projektes zu erhalten und um mögliche Stakeholder zu identifizieren. Auf ähnlicher Weise sollen in dieser Komponente sogenannte Offenlegungsszenarien erstellt und analysiert werden, die sich darauf fokussieren, wie potentielle (bösartige) Akteur:innen, im folgenden
Der Zweck dieser sogenannten Offenlegungsszenarien besteht darin, die Risikobewertung in einem Rahmen plausibler Ereignisse zu verankern (zusätzliche Details befinden in dem zum Download verfügbaren Dokument Offenlegungsszenarien).
Eine der zentralen Informationen in einem Offenlegungsszenario sind die Datenquellen, zu denen Angreifer:innen Zugang haben und welche Schlüsselvariablen die Angreifer:innen nutzen, um die Einträge aus diesen Datensätzen mit den Einträgen aus dem Mobilitätsdatensatz abzugleichen. Daher müssen möglichst viele mögliche Datenquellen berücksichtigt werden. Da eine laufende (automatisierte) Analyse der
Öffentliche Quellen: Adressverzeichnisse, Verzeichnisse von Arztpraxen / Krankenhäusern, POIs von Google Maps, OpenStreetMap oder Wikipedia, öffentliche Informationen über Veranstaltungen, Demonstrationen usw., Informationen über Gebäude, Satellitenbilder, Unternehmens-Webseiten / Teamseiten (für Arbeitsplatzadressen)
Social Media: Aufzeichnungen in sozialen Medien über den Aufenthaltsort von Nutzer:innen (mit Geotags versehene Beiträge), z.B. Facebook, Instagram, Mastodon oder auch der bewussten Selbstvermarktung z.B. die Veröffentlichung des Arbeitsplatzes über LinkedIn.
Offizielle Quellen / Amtliche Statistiken: Zensusdaten, Daten des Statistischen Bundesamtes, beispielsweise zur Grundsicherung oder zur regionalen Aufteilung von Asylbewerber:innen.
Die Durchführung einer vollständigen Analyse der Offenlegungsszenarien kann sehr zeitaufwändig sein und sollte daher im Verhältnis zum Risiko stehen. Besonders bei einem geschätzt geringen Risiko, sollte gut überlegt werden, ob der Nutzen der vollständigen Analyse die Kosten rechtfertigt oder ob die Ressourcen der Analyse anderweitig zielgerichteter eingesetzt werden können.
- Die bereits erstellten Szenarien aus dem Datenaudit können oft als Inspiration für Offenlegungsszenarien dienen.
- Eine Datenquelle kann in verschiedenen Szenarien auftauchen oder auch in Kombination mit mehreren anderen Datenquellen genutzt werden.
- Externen Datenquellen sind zentral für die Offenlegungsszenarien. Daher kann die Frage "In welchen anderen Situationen können diese Datenquellen noch zu einer Offenlegung führen" als Inspiration für weitere Szenarien dienen.
- Mit der Frage, welche Datenquellen in Kombination mit anderen zu einer Offenlegung führen kann, können weitere relevante Datenquellen und weitere Szenarien identifiziert werden.
Grundsätzlich gibt es zwei Kategorien möglicher Szenarien:
- ungewollte Offenlegung und
- vorsätzliche Angriffe.
Diese werden nachfolgend näher erläutert.
1) Ungewollte Offenlegung
Eine ungewollte Offenlegung liegt vor, wenn Angreifer:innen nicht aktiv darauf hinarbeiten ein Datensubjekt zu erkennen, sondern das Datensubjekt zufällig identifizieren können, beispielsweise aufgrund von vorhandenem Wissen oder Analysen, die aus einem anderen primären Grund durchgeführt wurden. Dies muss nicht zwangsläufig negative Folgen nach sich ziehen.
In dem Beispiel Scoooot kann eine ungewollte Offenlegung stattfinden, wenn Mitarbeitende des ÖPNV-Datenanalyse-Teams die Daten explorativ sichten und hierbei Fahrten von Bekannten zufällig erkennen. Das Szenario könnte dann folgendermaßen ablaufen:
Bob arbeitet in dem ÖPNV-Datenanalyse-Teams. Bei einer explorativen Sichtung fällt Bob auf, dass eine Reihe von Fahrten direkt am Wohnort von Alice enden, die Bob über gemeinsame Freunde kennt. Bob fällt auf, dass viele dieser Fahrten eine Kinderwunsch-klinik als Ursprungsort haben und ist schon ganz gespannt wie die gemeinsamen Freunde darauf reagieren werden, wenn er ihnen erzählt, dass Alice versucht schwanger zu werden.
Folgende Faktoren beeinflussen die Wahrscheinlichkeit einer ungewollten Offenlegung:
- Größe des Datensatzes: Normalerweise verringert ein großer Datensatz die Wahrscheinlichkeit, auf jemanden zufällig zu stoßen, da weniger einzigartige Merkmale zu finden sind.
- The fallback content to display on prerendering: Falls bekannt ist, dass ein Individuum im Datensatz enthalten ist, ist es einfacher einen Datensatz dieses Individuums zu erkennen, wodurch eine ungewollte Offenlegung zustande kommt. Das Wissen, ob ein Individuum in einem Datensatz enthalten ist, wird *Teilnahmekenntnis* genannt und weiter unten noch genauer diskutiert.
- Nutzer:innen des Datensatzes: Die Anzahl und Art Nutzer:innen können die Wahrscheinlichkeit für eine ungewollte Offenlegung unterschiedlich beeinflussen. Die Möglichkeit für eine Beziehung zwischen den Datennutzer:innen und den betroffenen Personen spielt eine Rolle (z. B. eine Wissenschaftlerin, die mit Studierendendaten forscht). Je größer die Anzahl der Datennutzer:innen ist, desto wahrscheinlicher ist eine solche Beziehung und damit eine ungewollte Offenlegung. Bei offenen Daten ist die:der Datennutzer:in potenziell die ganze Welt, und wenn es sich um Daten mit hohem Nutzwert handelt, kann die tatsächliche Datennutzer:innenbasis sehr groß sein.
2) Vorsätzliche Angriffe
Hier versuchen Angreifer:innen gezielt Informationen über eine Zielperson oder Zielgruppe zu erhalten, indem sie auf alle verfügbaren Informationen zurückzugreifen und diese mit den Daten des Datensatzes kombinieren. Die hinzugezogenen Daten werden
Das folgende Klassifizierungssystem kann die konzeptionelle Analyse von Angriffen erleichtern und ermöglicht die Erstellung einer Sammlung von Schlüsselvariablen, die Angreifer:innen wahrscheinlich zur Verfügung stehen. Solche Schlüsselvariablen sind ein sehr guter Ausgangspunkt für die Risikobewertung.
Zu einem Szenario mit vorsätzlichem Angriff sollten mindestens die folgenden Informationen festgehalten werden:
- Motivation: Was versuchen Angreifer:innen zu erreichen?
- Mittel: Welche Ressourcen (inkl. anderer Datenquellen) und Fähigkeiten stehen Angreifer:innen potentiell zur Verfügung?
- Zugang: Wie erhalten mögliche Angreifer:innen Zugang zu den Daten?
- Zielinformation: Welche sensible Information können die Angreifer:innen / wollen die Angreifer:innen erhalten?
- Alternativen: Gibt es einen alternativen, besseren Weg für Angreifer:innen diese Information zu erhalten?
- Datenabweichungen: Alle Daten enthalten Fehler/Ungenauigkeiten. Wie wirkt sich dies auf den Angriff aus?
- Beschreibung des Angriffs: Was ist der technische Aspekt der statistischen/rechnerischen Methode, die im Angriff verwendet wird?
- Schlüsselvariable: Welche Informationen aus anderen Datenquellen können für den Angriff genutzt werden?
Nachfolgend werden zwei dieser Informationen - Datenabweichung und Teilnahmekenntnis - näher erläutert.
Datenabweichungen (data divergence)
Alle Datensätze enthalten Fehler und Ungenauigkeiten. Die Befragten geben nicht immer korrekte Daten an. Bei automatisch aufgezeichneten Daten treten Fehler bei den Aufzeichnungen auf, beispielsweise durch falsch kalibrierte Sensoren. Es können auch einige Datenelemente fehlen. Darüber hinaus können die Daten Monate oder sogar Jahre alt sein, bevor sie veröffentlicht werden, und damit können sich die Merkmale seit der Erstellung der Daten geändert haben. Dies gilt sowohl für den Zieldatensatz als auch für die Zusatzinformationen, über die Angreifer:innen verfügen. Die Kombination dieser Faktoren führt dazu, dass bei der Verknüpfung zwischen dem Hintergrundwissen und dem Mobilitätsdatensatz Fehler entstehen.
Dies wird als Datenabweichungen (Datendivergenz) bezeichnet. Der Begriff bezieht sich auf zwei Situationen: (i) Divergenz zwischen Daten und Daten, d. h. Unterschiede zwischen Datensätzen, und (ii) Unterschiede zwischen Daten und Welt, d. h. Unterschiede zwischen den in den Datensätzen aufgezeichneten Werten und tatsächlichen Werten. Im Allgemeinen kann davon ausgegangen werden, dass beide Formen der Datenabweichung die Quote für eine erfolgreiche Verknüpfung von Hintergrundwissen und Mobilitätsdatensatz verringern.
Wenn jedoch zwei Datensätze auf die gleiche Weise von der Welt abweichen, was als parallele Divergenz bezeichnet wird, dann ist eine korrekte Verknüpfung wieder möglich. Dies wäre zum Beispiel der Fall, wenn ein Befragter konsequent falsche Angaben gemacht hat oder wenn zwei Datensätze veraltete, aber identische Daten enthalten.
Die Berücksichtigung von Datendivergenz ist kompliziert und führt tendenziell dazu, dass Risikomessungen das Risiko überschätzen. Damit können Datenabweichungen dazu führen, dass ein Angriff weniger erfolgreich ist, d.h. sie bieten einen potentiellen zusätzlichen Schutz, der allerdings nicht garantiert ist.
Teilnahmekenntnis (response knowledge)
Das Teilnahmekenntnis bezeichnet das Wissen von Angreifer:innen, ob die Zielperson in einem Datensatz enthalten ist. Wenn Angreifer:innen nicht wissen, ob die Zielperson beispielsweise Nutzer:in eines Sharing-Dienstes ist, so können Angreifer:innen sich bei übereinstimmenden Merkmalen nicht sicher sein, ob es sich um die Zielperson handelt, selbst wenn die Kombination an Merkmalen in dem gegebenen Datensatz einzigartig ist. In der Praxis kann Teilnahmekenntnis auf zwei Arten auftreten:
- Angreifer:innen wissen, dass (a) die Daten eine Population vollständig abdecken und (b) die Zielperson ein Mitglied dieser Population ist.
- Der Eindringling hat Ad-hoc-Wissen aus anderen Quellen, die auf das Vorhandensein einer bestimmten Person in den Daten schließen lassen.
In unserem Beispiel können Angreifer:innen über Erzählungen von Dritten oder direkte Beobachtungen wissen, dass eine Zielperson Nutzer:in des Shared Mobility-Unternehmens Scoooot ist und damit im Datensatz (der alle Nutzer:innen umfasst) enthalten ist. Somit muss angenommen werden, dass Teilnahmekenntnis vorhanden ist.
Hier sind für das Beispiel von Scoooot drei Szenarien für vorsätzliche Angriffe aufgeführt.
| Fragen |
| |
|---|---|---|
| Motivation | Was versuchen Angreifer:innen zu erreichen? | Feststellen, ob eine Zielperson einen bestimmten (sensiblen) Ort aufgesucht hat - z.B. die Partnerin einen Ex-Freund, der Mitarbeiter das Casino, die Politikerin den Lobbyverband |
| Mittel | Welche Ressourcen (inkl. anderer Datenquellen) und Fähigkeiten stehen Angreifer:innen zur Verfügung? | Als Mitarbeiter:in des ÖPNV-Analytics-Teams besteht Zugang zum Datensatz. Offen verfügbare Daten zu Standorten von POIs und Unternehmen sind ebenfalls einfach verfügbar. Zusätzlich kann die Person potenziell wissen, dass die Zielperson Kund:in des Shared Mobility-Anbieters ist. Es wäre jedoch zusätzlich fraglich, ob die relevante Fahrt auch mit dem Anbieter getätigt wurde. |
| Zugang | Wie erhalten mögliche Angreifer:innen Zugang zu den Daten? | Die Daten stehen der Person durch dessen Position zur Verfügung. |
| Zielinformation | Was ist die Zielinformation des Angriffs? Welche sensible Information erhalten die Angreifer:innen? | Ein Ort und Zeitpunkt des Aufenthalts der Zielperson. |
| Alternativen | Gibt es einen alternativen, besseren Weg für Angreifer:innen diese Information zu erhalten? | Beobachtung der Zielperson. |
| Datenabweichungen | Alle Daten enthalten Fehler/Ungenauigkeiten. Wie wirkt sich dies auf den Angriff aus? | Da die Koordinaten als zuverlässig anzusehen sind, ist hier kein (großer) Effekt zu erwarten. |
| Beschreibung des Angriffs | Was ist der technische Aspekt der statistischen/rechnerischen Methode, die im Angriff verwendet wird? | Der Datensatz wird mit offen verfügbaren Daten zum Standort von POIs und Unternahmen verknüpft (Linkage Attack) |
| Schlüsselvariablen | Welche Informationen aus anderen Datenquellen werden für den Angriff genutzt? | Wissen über bekannte Aufenthaltsorte der Zielperson (z.B. Wohnort); potenziell durch zusätzlichen Datensatz |
Nachdem ein Offenlegungsszenario mit diesen Informationen angereichert wurde, kann das Szenario anhand der folgenden Fragen analysiert werden.
- Wie wahrscheinlich ist der Angriff der in diesem Szenario beschrieben wird?
- Wenn es einen solchen Angriff gibt, wie wahrscheinlich ist es, dass er erfolgreich ist?
- Wie geht es weiter, nachdem der Angriff erfolgreich durchgeführt wurde (oder nicht)?
- Können durch eine Änderung der Datenlage die oben genannten Punkte beeinflusst werden?
In dem folgenden Beispiel werden die Fragen zur Analyse für die drei eingeführten Szenarien mit Scoooot beantwortet.
| Ergebnis |
| |
|---|---|---|
| Durchführungswahrscheinlichkeit | Wie wahrscheinlich ist ein solcher Angriff angesichts der Eingaben? | Die Wahrscheinlichkeit ist als eher gering einzustufen, da es eine Mitarbeiter:in mit entsprechendem Interesse geben muss, die zusätzlich weiß, dass die Zielperson Teil des Datensatzes ist (response knowledge). |
| Erfolgswahrscheinlichkeit | Wenn es einen solchen Angriff gibt, wie wahrscheinlich ist es, dass er erfolgreich ist? | Die Wahrscheinlichkeit ist als nicht hoch einzustufen, da verschiedene Faktoren zusammentreffen müssen: 1) Nicht jede:r Mitarbeiter:in hat Zugriff, sondern diese Person muss Teil der ausgewählten, eingeschränkten Gruppe der Daten-Analyst:innen sein. 2) Die fragliche Fahrt muss mit dem Shared Mobility-Anbieter getätigt worden sein. 3) Da die direkte Kundenreferenz entfernt wurde, muss der Startpunkt der Fahrt bereits als Identifikator ausreichen. Zusätzlich ist zu bemerken, dass aufgrund der entfernten User-ID die Identifizierung deutlich erschwert wurde, sodass Vermutungen über den Urheber einer Fahrt zwar getroffen werden können, jedoch Angreifer:innen kaum Gewissheit haben können, ob sie damit richtig liegen. Je nach Fall kann eine solche Vermutung bereits ausreichen, um als erfolgreich zu gelten, oder sie bietet der Zielperson genügend Spielraum diese abzustreiten, sodass die Attacke nicht als erfolgreich zu bewerten ist. |
| Konsequenzen | Wie geht es weiter, wenn sie erfolgreich sind (oder nicht)? | Potenzielle negative Folgen für die Zielperson (entsprechend der oberen Beispiele, ggf. Konflikt mit dem Partner, Kündigung, Rücktrittsforderungen von Ämtern); Reputationsschäden für den Shared Mobility-Anbieter und ggf. für das ÖPNV-Unternehmen als Quelle des Datenleaks. |
| Effekte bei Veränderung der Datensituation | Können durch eine Änderung der Datenlage die oben genannten Punkte beeinflusst werden? | Durch Einschränkung der Zugangsbedingungen kann der Kreis möglicher Angreifer:innen reduziert und damit das Risiko minimiert werden. Durch die Dokumentation von Datensatzzugriffen können Leaks nachverfolgt und die Hürde für einen Missbrauch der Daten erhöht werden. |
Datenanalytische Risikoanalyse (Data analytical risk assessment - DARA)
Bei der Datenanalytischen Risikoanalyse geht es darum das Risiko numerisch auf Grundlage des vorhandenen Datensatzes zu bestimmen. Hierbei ist es ratsam (externes) Fachwissen heranzuziehen.
Einzigartigkeit als Risiko-Metrik (Angriffsziel Singling-out: Identity Attack)
In diesem Schritt wird das Risiko quantitativ analysiert. Diese Quantifizierung basiert hauptsächlich auf der Berechnung, wie einzigartig der Eintrag einer Person im Datensatz ist. Daraus leitet sich ab, ob diese wieder identifiziert werden kann. Das Risiko setzt voraus, dass Angreifer:innen das Ziel haben, Zielpersonen herauszugreifen (singling-out). Einzigartigkeit alleine führt nicht direkt zur Identifizierung, da Es kein Standardverfahren gibt, wie Angreifer:innen einzigartige Personen im Allgemeinen wieder identifizieren können. Allerdings deuten Einzigartigkeiten eine Anfälligkeit an, auf die sich Angreifer:innen fokussieren.
Bei der Verwendung der Einzigartigkeit als Risikoberechnung ist zusätzlich die Frage relevant, ob es sich bei dem Datensatz um eine Stichprobe oder die gesamte Population handelt. 'Population' kann sich hierbei auch auf die Gesamtheit einer bestimmten Zielgruppe beziehen. Einzigartige Nutzer:innen in einer Stichprobe (sample unique), müssen nicht zwangsläufig auch einzigartige Nutzer:innen in der Gesamtpopulation (population unique) sein.
Beispielsweise kann ein Datensatz alle Nutzer:innen einer Region enthalten. Gibt es in der Region nur eine einzige 95-jährige Frau (population unique), so kann in jedem vermeintlich anonymisierten Datensatz dieser Region, in dem eine weibliche Person mit einem Alter von 95 vorkommt, diese Frau sofort wieder identifiziert werden, da diese Kombination an Attributen (Schlüsselvariablen) einzigartig ist. Hierbei spielt es keine Rolle, ob es sich um den gesamten Datensatz oder nur eine Stichprobe handelt. Ist die Zielperson anhand der Schlüsselvariablen in der Population nicht einzigartig, aber dafür in der veröffentlichten Stichprobe (sample unique), können sich Angreifer:innen nicht sicher sein, ob die Zielperson Teil der Stichprobe ist, oder ob eine andere Person mit den gleichen Merkmalen in der Stichprobe vertreten ist. In diesem Fall ist die Teilnahmekenntnis (response knowledge) relevant, d.h. ob Angreifer:innen wissen, dass die Zielperson im veröffentlichten Datensatz enthalten ist. Ob Angreifer:innen über Teilnahmekenntnis verfügen, sollte aus der Analyse der Offenlegungsszenarien hervorgehen.
Ist von Teilnahmekenntnis auszugehen, so ist die Berechnung der Einzigartigkeit von Einträgen im Datensatz und damit das Risiko direkt mittels des vorliegenden Datensatzes zu berechnen (der Anteil an Einträgen, die eine einzigartige Kombination an Attributen aufweisen). Ist nicht davon auszugehen, dass Angreifer:innen Teilnahmekenntnis besitzen, so kann das Risiko anhand der data intrusion simulation [3] berechnet werden. Dabei wird die Wahrscheinlichkeit berechnet, dass es sich bei dem einzigartigen Eintrag in der Stichprobe (sample unique) auch um einen einzigartigen Eintrag der Gesamtpopulation (population unique) handelt.
Im Gegensatz zu anderen tabellarischen Daten wird die Einzigartigkeit von Mobilitätsdaten jedoch nicht (hauptsächlich) durch Attribute wie Alter, Geschlecht usw. bestimmt, sondern durch die räumlich-zeitlichen Punkte. Bei unbearbeiteten GPS-Daten beispielsweise, wird wahrscheinlich jede:r Nutzer:in einzigartig sein. Soweit bisher nicht geschehen, muss fast immer die räumliche und zeitliche Granularität reduziert werden, d.h. es dürfen keine exakten Koordinaten und Zeitstempel verwendet werden. Jedoch führen auch starke Generalisierungen auf groben Rastern und großen Zeitfenstern häufig nur bedingt dazu, die Einzigartigkeit auf ein befriedigendes Level zu reduzieren (siehe hierzu auch Montjoye, 2013 [10]). Weitere Möglichkeiten sind räumliche und/oder zeitliche Aggregationen oder das Erstellen einer Stichprobe (sampling). Alternativ kann die Datenumgebung geändert werden, sodass diese weniger risikoreich ist (siehe 7b Risiko kontrollieren).
In dem Beispiel des Anbieters Scoooot, wurden in der Fokusumgebung die pseudonymisierte User-IDs aus den Transaktionsdaten bereits entfernt, sodass immer nur zwei räumlich-zeitliche Punkte miteinander verknüpft sind. Da es sich allerdings um exakte Koordinaten und Zeitstempel handelt, ist jeder Eintrag immer noch einzigartig.
Aus den Offenlegungsszenarien geht hervor, dass es unwahrscheinlich ist, dass Angreifer:innen über Informationen der exakten Zeitstempel und Koordinaten verfügt. Beispielsweise könnte ein:e Angreifer:in nur wissen, dass die Zielperson an einem bestimmten Tag abends zwischen 18 und 20 Uhr zu Hause angekommen ist, oder mittels Social-Media-Post wissen, dass sich die Person gegen 15 Uhr in der Nähe des Brandenburger Tors befunden hat.
Trotzdem, selbst wenn die Berechnung von einzigartigen Einträgen auf einer räumlichen Generalisierung eines 200-Meter-Rasters und in 1-Stunden-Zeitfenstern ausgeführt wird, bleiben in unserem Beispiel 75% einzigartige Einträge übrig.
Da jeder Eintrag allerdings nur noch aus zwei Punkten besteht, lässt sich argumentieren, dass das Risiko für die Offenlegung der Zielinformation (das individuelle Bewegungsmuster) deutlich reduziert ist, sodass die Berechnung der Einzigartigkeit keine relevante Gefahr darstellt. Das verbliebene Rest-Risiko könnte alternativ über die Gestaltung der Datenumgebung, sprich über striktere Nutzungsbestimmungen für das ÖPNV-Unternehmen, kontrolliert werden.
Um den Datenschutz zu erhöhen, werden anstatt der exakten Zeitstempel und Koordinaten nur Zeitfenster bzw. Zellen-IDs verwendet. Damit gibt es für die Kombination von räumlich-zeitlichen Punkten keine einzigartigen Fahrten. In diesem Beispiel sind die User-IDs allerdings noch in den Transaktionsdaten enthalten. Damit können die Fahrten nicht mehr naiv einer Person zugeordnet werden.
Aus der Analyse der Offenlegungsszenarien in diesem Beispiel ist allerdings hervorgegangen, dass Angreifer:innen mehrere räumlich-zeitlichen Punkte einer Zielperson kennen können. Beispielsweise könnte die Zielperson mehrere Male mit einem E-Scooter beobachtet worden sein. Wenige solche Punkte reichen aus, um die Bewegungsmuster einer Person zu identifizieren. Damit können Angreifer:innen der Zielperson eine User-ID und folglich auch alle Bewegungen mit dieser User-ID zuordnen. Im Allgemeinen bekommen Angreifer:innen dadurch neues Wissen über die Zielperson, da für die Identifizierung einige, aber nicht alle räumlich-zeitlichen Punkte aus dem Mobilitätsdatensatz bekannt waren.
Für die Einschätzung des Risikos ist demnach nicht nur die Einzigartigkeit der Nutzer:innen von Bedeutung, sondern auch das dazu benötigte Hintergrundwissen (z.B. Anzahl der Punkte) und die neu erlangte Zielinformation (z.B. Anzahl der dazu gewonnen Punkte/Fahrten).
Wenn man sich jedoch auf das Konzept der Einzigartigkeit konzentriert, lassen sich zwei einfache pragmatische Grundsätze erkennen:
- Je mehr Informationen benötigt werden, um einen Eintrag eindeutig zu machen (oder um ihn "herauszugreifen"), desto weniger ungewöhnlich ist er. Die ungewöhnlichen Einträge sind diejenigen, die mit einer kleinen Anzahl von Schlüsselvariablen bereits einzigartig sind.
- Je mehr Informationen benötigt werden, um einen Eintrag eindeutig zu machen (oder um ihn "herauszugreifen"), desto wahrscheinlicher ist es, dass jeder Abgleich mit diesem Eintrag zu Datenabweichungen führt, was die Wahrscheinlichkeit sowohl falsch positiver als auch falsch negativer Übereinstimmungen erhöht.
Der erste Grundsatz ist in erster Linie für Szenarien relevant, in denen der Datensatz eine Stichprobe ist und Angreifer:innen keine Teilnahmekenntnis haben. Der zweite Grundsatz ist relevant, wenn es sich entweder um Datensätze über die Gesamtpopulation handelt oder das Szenario von Teilnahmekenntnis ausgeht.
Berechnung der Einzigartigkeit:
Um die Einzigartigkeit in einem Datensatz zu berechnen, kann der folgende Pseudocode genutzt werden.
def uniqueness(D,n):
// D: Datensatz mit Trajektorien
// n: Anzahl der möglichen Punkte, die Angreifer:innen haben können
// Wähle zufällig n Punkte aus D für jeden Nutzer aus. Das sind dann die Schlüsselvariablen
D['random Points'] = [] // Liste mit zufälligen Punkten
für alle user in D:
user['random points'] = random.sample(user['locations'], n)
// Prüfe Uniqueness basierend der n Punkte pro User
uniqueness = 0
für alle user in D:
points = user['random points']
unique = 0
für alle user in D:
userpoints = user['locations']
if all(points in userpoints):
unique += 1
remove user from D, um Dopplungen zu vermeiden
if unique == 1:
uniqueness += 1
return uniqueness/ lenght(D)
Diversität als Risiko-Metrik (Angriffsziel Attribute Inference: Localization Attack)
Einzigartigkeit alleine ist nicht ausreichend für die Risikoberechnung. Die Einzigartigkeit ist geeignet, um das Risiko des Herausgreifens (singling-out) von einzelnen Einträgen (z.B. Nutzer:innen oder Trajektorien) zu berechnen. Gibt es keine einzigartigen Einträge, befinden sich in einer Gruppe gleicher Schlüsselvariablen (sog. Äquivalenzklassen) mehrere Einträge. In diesem Fall, sollte die Diversität der Zielinformation für die Risikoberechnung hinzugezogen werden, da diese sensible Informationen preisgeben kann. Ist beispielweise die Zielinformation, die sich aus allen Einträgen der Äquivalenzklasse ergibt, ähnlich zu einander, können Angreifer:innen auch bei nicht einzigartigen Einträgen auf die Zielinformation schließen.
Um die Einzigartigkeit zu reduzieren, verwendet Scoooot nun anstatt der exakten Zeitstempel und Koordinaten nur Zeitfenster bzw. Zellen-IDs. Damit gibt es für die Kombination von räumlich-zeitlichen Punkten keine einzigartigen Fahrten.
Aus den Offenlegungsszenarien geht hervor, dass das Hintergrundwissen der Angreifer:innen aus (mehreren) Startpunkten von Nutzer:innen besteht. Mit drei Punkten aus dem Hintergrundwissen, kann der Datensatz auf drei mögliche Fahrten reduziert werden, die allerdings alle an einem Nachtclub enden. Zwei der Fahrten enden in der gleichen Zelle, die dritte Fahrt endet in der benachbarten Zelle, in der der Nachtclub einen weiteren Eingang hat. Zwar sind die Daten nicht einzigartig, aber das Ziel der Fahrten ist dennoch identisch. Somit können Angreifer:innen zwar nicht sicher sein, welche Fahrt von der Zielperson getätigt wurde. Über die Ähnlichkeit der Fahrtziele kann jedoch trotzdem auf das sensible Attribut, nämlich die Art der Fahrt oder Aktivität am Zielort, geschlossen werden. Das ist ein klassisches Beispiel einer attribute inference und zeigt, dass auch die genaue Betrachtung der sensiblen Attribute in die Bestimmung Einzigartigkeit einbezogen werden muss.
Grundsätzlich gilt, dass eine höhere Diversität zu einem geringeren Risiko fir die erneute Identifizierung von Personen führt. Im Falle von Mobilitätsdaten ist es jedoch relevant, wie die Diversität gemessen wird. So können sensible Attribute zwar unterschiedlich, aber semantisch sehr ähnlich sein.
Berechnung der Diversität:
Mit dem folgenden Pseudocode kann die Diversität in einem Datensatz berechnet werden:
def diversity(D,n):
// D: Datensatz mit Trajektorien
// n: Anzahl der möglichen Punkte, die Angreifer:innen haben können
// Wähle zufällig n Punkte aus D für jeden Nutzer aus. Das sind dann die Schlüsselvariablen
D['random Points'] = [] // Liste mit zufälligen Punkten
für alle user in D:
user['random points'] = random.sample(user['locations'], n)
// Prüfe Diversität basierend der n Punkte für alle user, die nicht einzigartig sind
diversity = []
für alle user in D:
points = user['random points']
unique = 0
locations = {}
für alle user in D:
userpoints = user['locations']
if all(points in userpoints):
unique += 1
locations.append([userpoints]) // Standorte des Users, der die gleichen random points aufweist
remove user from D, um Dopplungen zu vermeiden
if unique > 1:
div = unique(locations)/length(locations) //
diversity.append[div]
return diversity //alle diversity für einzelne Gruppen
Penetrationstest
Bei einem Penetrationstest (Pen-Test) handelt es sich um einen simulierten Angriff, bei dem der zu veröffentlichende Datensatz angegriffen wird. Ein solcher Pen-Test kann an jedem beliebigen Punkt des Prozesses der Risikokontrolle durchgeführt werden. Beispielsweise kann er auch nach Anwendung von Kontrollmaßnahmen (disclosure control) angewendet werden, um deren Effektivität zu prüfen.
Ein Pen-Test besteht im Wesentlichen aus vier Phasen: (i) Datenerfassung, (ii) Datenaufbereitung und -abgleich, (iii) dem eigentlichen Angriff und (iv) Verifizierung:
- Datenerfassung. Die erste Phase ist in der Regel die ressourcenintensivste. Je nach Art des simulierten Angriffs, werden unterschiedliche Daten benötigt. Wird von Teilnahmekenntnis ausgegangen, kann eine Stichprobe des Gesamtdatensatz ein Ausgangspunkt für einen simulierten Angriff sein. Andernfalls müssen andere Quellen hinzugezogen werden.
- Datenaufbereitung und -abgleich. Damit das Hintergrundwissen (andere Daten) von Angreifer:innen verwendet werden kann, müssen die Daten identisch kodiert sein. In dieser Phase wird viel Fachwissen benötigt.
- Angriff. Die Details des Angriffs sind von dem Szenario und den Daten abhängig. In der Regel, wird das Hintergrundwissen (Daten aus der ersten Phase) verwendet, um eine Verbindung zu den eigentlichen Daten herzustellen. Jede gefundene Übereinstimmung kann allerdings auch fehlerhaft sein, sodass es sinnvoll ist entsprechende Konfidenzintervalle mitanzugeben. Es sei an dieser Stelle angemerkt, dass diese Phase am meisten Fachwissen benötigt. Im Allgemeinen ist es daher hilfreich, externe Expert:innen hinzuzuziehen, auch wenn intern über entsprechendes Fachwissen verfügt wird, um die Perspektive unabhängiger Angreifer:innen realistisch einzubringen.
- Verifizierung. Gefundene Übereinstimmungen müssen überprüft werden. In der Regel wird dies nicht durch die (simulierten) Angreifer:innen erfolgen, sondern durch eine interne Person.
Beispielhaftes Vorgehen mit Risiko Edit Distance on Real Sequence (EDR):
In dem folgenden Beispieldatensatz von Scoooot soll ein Penetrationstest an einen Datensatz mit Trajektorien einzelner Personen durchgeführt werden. Angenommen, Angreifer:innen möchten Informationen über eine Person sammeln, von der sie wissen, dass sie im Datensatz enthalten ist. Wir gehen also von Teilnahmekenntnis aus. Das Ziel des Angriffs ist es, einer Zielperson Einträge aus dem Mobilitätsdatensatz zuzuordnen.
Nachfolgende ist ein Auszug aus dem Datensatz angegeben, der veröffentlicht werden soll.
| TripID | UserID | Breitengrad | Längengrad | Datum/Uhrzeit |
|---|---|---|---|---|
| ... | ... | ... | ... | ... |
| S12 | 23 | 49.89317588854993 | 10.886685776864049 | 13.06.2008 13:27 |
| S12 | 23 | 49.92995512380473 | 10.873004316555292 | 13.06.2008 14:01 |
| S12 | 23 | 49.8888823332195 | 10.926632822076753 | 13.06.2008 14:33 |
| ... | ... | ... | ... | ... |
| S19 | 23 | 49.89317588854993 | 10.886685776864049 | 20.06.2008 18:30 |
| S19 | 23 | 49.900914522186504 | 10.911567361443652 | 20.06.2008 19:30 |
| S19 | 23 | 49.91594959280955 | 10.87087556134096 | 20.06.2008 22:30 |
| ... | ... | ... | ... | ... |
| S21 | 23 | 49.895617593472906 | 10.914747327677274 | 21.06.2008 15:25 |
| S21 | 23 | 49.884752851434236 | 10.91627868535414 | 21.06.2008 16:37 |
| ... | ... | ... | ... | ... |
| S29 | 37 | 49.92995512380473 | 10.873004316555292 | 13.06.2008 14:01 |
| S29 | 37 | 49.8888823332195 | 10.926632822076753 | 13.06.2008 14:33 |
| S29 | 37 | 49.882900051205006 | 10.916043537245846 | 13.06.2008 15:01 |
| ... | ... | ... | ... | ... |
Phase 1: Datenerfassung
Um die Einträge aus dem veröffentlichten Datensatz der Zielperson zuzuordnen, werden diese mit Daten abgeglichen, die aus anderen Quellen (z.B. eigenen Beobachtungen) gesammelt wurden.
Dieses Hintergrundwissen kann sich beispielsweise aus einzelnen Social Media-Beiträgen zusammensetzen, in denen die Zielperson Alice zu verschiedenen Zeiten ihren Standort (z.B. Brandenburger Tor, Restaurant im Bundestag) veröffentlicht hat. Dieser Datensatz kann wie folgt aussehen:
| TripID | Name | Breitengrad | Längengrad | Datum/Uhrzeit |
|---|---|---|---|---|
| ... | ... | ... | ... | ... |
| A3 | Alice | 49.89318 | 10.88669 | 13.06.2008 13:27 |
| A3 | Alice | 49.92996 | 10.87300 | 13.06.2008 14:01 |
| A3 | Alice | 49.88888 | 10.92663 | 13.06.2008 14:33 |
| ... | ... | ... | ... | ... |
| A5 | Alice | 49.89318 | 10.88669 | 20.06.2008 18:30 |
| A5 | Alice | 49.91595 | 10.87088 | 20.06.2008 22:30 |
Die TripID identifiziert hier mehrere Koordinatenpunkte, die zu einer Reise von Alice gehören. Da das Hintergrundwissen unabhängig von dem Scoooot Datensatz ist, sind die TripIDs verschieden, was durch das Präfix S bzw. A verdeutlicht wird.
Phase 2: Datenaufbereitung und -abgleich
Die Koordinaten aus dem Hintergrundwissen sind aus veröffentlichten Social Media-Beiträgen. Daher sind sie nur auf fünf Nachkommastellen genau angegeben. Die Koordinaten aus dem Datensatz von Scoooot sind die aufgezeichneten GPS-Koordinaten und haben daher eine höhere Genauigkeit.
Da die Datensätze unterschiedliche Granularitäten bei den Koordinaten aufweisen, wird der Datensatz von Scoooot auf fünf Nachkommastellen gerundet.
Phase 3: Angriff
Bei diesem Angriff werden die Trajektorien aus den Datensätzen abgeglichen. Um zu evaluieren, ob eine Trajektorie aus dem Datensatz von Scoooot die gleiche Reise repräsentiert, wie eine Trajektorie aus dem Hintergrundwissen, kann die Edit Distance on Real sequence (EDR), von Chen et al. [11] verwendet werden.
Edit Distance on Real Sequence (EDR):
Bei der EDR wird geprüft, wie viele Änderungsoperationen an einzelnen Einträgen benötigt werden, um eine Trajektorie in die anderen zu überführen. Dabei zählen jeweils das Einfügen, Löschen und Verändern eines Eintrags als eine Operation. Das Verändern gilt immer als eine Operation, unabhängig davon, ob beim Verändern des Breitengrads, des Längengrads, oder ob beide geändert werden und wie weit die (Zahlen-)Werte auseinanderliegen. Es kann aber ein Schwellenwert für den rechnerischen Abstand der Werte definiert werden, bis zu dem zwei Längen- oder Breitengrade als gleich angesehen werden. Dies dient dazu, kleine, durch die Messungen entstandene Abweichungen auszugleichen. Um das Beispiel verständlich zu gestalten, haben wir hier auf solche Abweichungen und somit auch auf einen Schwellenwert verzichtet.
Ob man die Zeitstempel mit in die EDR einbezieht, ist eine Frage des Anwendungsfalls. In unserem Beispiel berechnen wir die EDR nur auf Basis der Koordinaten (die Reihenfolge der Koordinatenpunkte in einem Trip bleibt aber erhalten).
Der naive Ansatz, um zwei Trajektorien miteinander zu vergleichen, ist, punktweise den räumlichen Abstand zwischen zwei Einträgen zu bestimmen und aufzuaddieren. Dieses Verfahren ist allerdings sehr anfällig, da ein Ausreißer, beispielsweise durch GPS-Messfehler, den Gesamtunterschied zwischen zwei Trajektorien stark beeinflusst. Es gibt noch viele weitere Metriken, um die Ähnlichkeit zweier Trajektorien zu bewerten, die unterschiedlichen Vor- und Nachteile haben. Die Auswahl der Metriken hängt letztlich von den Eigenschaften des Datensatzes ab.
Für den Angriff werden paarweise zwischen allen Trajektorien des Hintergrundwissens und des Veröffentlichungsdatensatzes von Scoooot die EDR berechnet.
| EDR | Trip S12 | Trip S19 | Trip S21 | Trip S29 |
|---|---|---|---|---|
| Trip A3 | 0 | 2 | 3 | 2 |
| Trip A5 | 2 | 1 | 2 | 3 |
Nun kann zu jedem Trip des Hintergrundwissens der Trip aus dem Datensatz von Scoooot ausgewählt werden, der die geringste EDR hat:
Die EDR zwischen Trip A3 und S12 beträgt 0, da die Trajektorien identisch sind, nachdem Trip S12 gerundet wurde.
Die EDR zwischen Trip A5 und S19 beträgt 1, da der zweite Eintrag aus Trip S19 in Trip A5 fehlt. Um die Trips aneinander anzugleichen, müsste also der fehlende Eintrag (in der Mitte) eingefügt werden, was einer Operation entspricht.
Obwohl die Trips A3 und S29 zwei aufeinanderfolgende gleiche Einträge haben, ist die Distanz mit 2 relativ hoch. Das liegt daran, dass EDR die Reihenfolge beachtet und die gleichen Einträge bei Trip A3 am Ende und bei Trip S29 am Anfang vorkommen. Somit sind mehr Operationen nötig, um die Trips anzugleichen.
Für eine Auswertung bietet es sich an, die EDR auf 1 zu normieren, indem man alle Werte durch die maximal mögliche EDR teilt. Der Übersichtlichkeit halber wurde dies hier ausgelassen.
Somit ist das Ergebnis dieses Angriffs wie folgt: Trip A3 aus dem veröffentlichten Datensatz wird Trip S12 aus dem Hintergrundwissen und Trip A5 aus dem veröffentlichten Datensatz wird Trip S19 aus dem Hintergrundwissen zugeordnet. Beide zugeordneten Trips S12 und S19 wurden von User23 aufgezeichnet. Damit wurde Alice in den Daten identifiziert und alle weiteren Trips von User23 können zu einer Offenlegung weiterer Informationen über Alices genutzt werden.
Phase 4: Verifizierung
In der letzten Phase werden die Zuordnungen aus dem Angriff mit den Originaldaten, also den noch nicht zur Veröffentlichung angepassten Daten, verifiziert. Je nach Szenario und Anonymisierungsmethode kann die Verifizierung unterschiedlich ausfallen.
Die Daten wurden nur generalisiert. Es wird überprüft, ob die markierte Zielperson auch der Zielperson im Originaldatensatz entspricht.
| Hintergrundwissen | Zuordnung Angreifer:innen | Korrekte Zuordnung | Match |
|---|---|---|---|
| Trip A3 | Trip A3 --> Trip S12 --> User 23 | Alice = User 23 | Wahr |
| Trip A5 | Trip A5 --> Trip S19 --> User 23 | Alice = User 23 | Wahr |
| ... | ... | ... |
Als Gesamturteil wird das Verhältnis der korrekten Zuordnungen angegeben. In unserem Fall sind die Zuordnungen alle korrekt (100%) und der Angriff somit erfolgreich.
Bei synthetischen Daten kann eine Zuordnung nicht überprüft werden, da es keinen direkten Link mehr gibt. Mit anderen Worten kann eine direkte Zuordnung von synthetischen User-Daten und dem "originalen" User nicht erfolgen. Die Verifizierung bezieht sich hier stattdessen auf die Zielinformation, also darauf wie viele Fahrten Alice korrekt zugeordnet werden können. Dazu werden die Fahrten von User23, der Alice am ehesten entspricht, mit den Fahrten von Alice verglichen. Eine mögliche Metrik für diesen Fall könnte beispielsweise sein, welcher Prozentsatz der Fahrten von User23 mit Alices Fahrten übereinstimmen.
Während des Penetrationtests in diesem Beispiel können drei Beobachtungen über die Sicherheitsevaluationen gemacht werden.
- Die Existenz der UserIDs (und somit eine Zuordnung, welche Trips von der gleichen Person gemacht wurden) haben den Angriff wesentlich erleichtert. Es sollte also darüber nachgedacht werden, ob die UserIDs nötig sind.
- Da alle Trips von Alice im Datensatz enthalten waren, konnte im Angriff jedem Trip aus dem Hintergrundwissen ein Trip aus dem Datensatz von Scoooot zugeordnet werden. Je mehr Trips zugeordnet werden können, desto sicherer können Angreifer:innen die Zuordnung zwischen Pseudonym und Zielperson annehmen. Um diesen Faktor des Angriffes einzuschränken, bietet es sich an, beispielsweise die Anzahl an Trips zu begrenzen, die von der gleichen Person stammen können.
- Die Genauigkeit der Koordinaten hat den Datensatz auch zu einem wertvolleren Angriffsziel gemacht. Wenn der Verwendungszweck es zulässt, sollte die Genauigkeit reduziert werden.
[1] Saskia Nuñez von Voigt, Stephan A. Fahrenkrog-Petersen, Dominik Janssen, Agnes Koschmider, Florian Tschorsch, Felix Mannhardt, Olaf Landsiedel, Matthias Weidlich: Quantifying the Re-identification Risk of Event Logs for Process Mining - Empiricial Evaluation Paper. CAiSE 2020: 252-26
[2] Luise Mehner, Saskia Nuñez von Voigt, Florian Tschorsch: Towards Explaining Epsilon: A Worst-Case Study of Differential Privacy Risks. EuroS&P Workshops 2021: 328-331
[3] Skinner, C. J., und M. J. Elliot. „A Measure of Disclosure Risk for Microdata“. Journal of the Royal Statistical Society. Series B: Statistical Methodology, Bd. 64, Nr. 4, 2002, S. 855–67. research.manchester.ac.uk, https://doi.org/10.1111/1467-9868.00365.
[4] Roberto Pellungrini, Luca Pappalardo, Francesca Pratesi, and Anna Monreale. 2017. A Data Mining Approach to Assess Privacy Risk in Human Mobility Data. ACM Trans. Intell. Syst. Technol. 9, 3, Article 31 (December 2017), 27 pages. DOI: https://doi.org/10.1145/3106774
[5] Pappalardo, L., Simini, F., Barlacchi, G., & Pellungrini, R. (2019). scikit-mobility: A Python library for the analysis, generation and risk assessment of mobility data. arXiv preprint arXiv:1907.07062.
[6] R. Shokri, G. Theodorakopoulos, J. -Y. Le Boudec and J. -P. Hubaux, "Quantifying Location Privacy," 2011 IEEE Symposium on Security and Privacy, Oakland, CA, USA, 2011, pp. 247-262, doi: 10.1109/SP.2011.18.
[7] B. Liu, W. Zhou, T. Zhu, L. Gao and Y. Xiang, "Location Privacy and Its Applications: A Systematic Study," in IEEE Access, vol. 6, pp. 17606-17624, 2018, doi: 10.1109/ACCESS.2018.2822260.
[8] V. Primault, A. Boutet, S. B. Mokhtar and L. Brunie, "The Long Road to Computational Location Privacy: A Survey," in IEEE Communications Surveys & Tutorials, vol. 21, no. 3, pp. 2772-2793, thirdquarter 2019, doi: 10.1109/COMST.2018.2873950.
[9] Isabel Wagner and David Eckhoff. 2018. Technical Privacy Metrics: A Systematic Survey. ACM Comput. Surv. 51, 3, Article 57 (May 2019), 38 pages. https://doi.org/10.1145/3168389
[10] Y.-A. de Montjoye, C. A. Hidalgo, M. Verleysen, und V. D. Blondel, „Unique in the Crowd: The privacy bounds of human mobility“, Sci Rep, Bd. 3, Nr. 1, S. 1376, März 2013, doi: 10.1038/srep01376.
[11] Chen, Lei, u. a. „Robust and fast similarity search for moving object trajectories“. Proceedings of the ACM SIGMOD International Conference on Management of Data, Juni 2005, S. 491–502. ResearchGate, https://doi.org/10.1145/1066157.1066213.