The project PArADISE deals with activity and intention recognition in smart environments. This can be used in apartments, for example, to recognize falls of elderly people. While doing this, the privacy concerns of the user should be kept. To reach this goal, the processing of the data is done as close as possible at those sensors collecting the data. Only in cases where the processing is not possible on local nodes the data will be transferred to the cloud. But before transferring, it is checked against the privacy concerns using some measures for the anonymity of the data. If the data is not valid against these checks, some additional anonymizations will be done. This anonymization of data must be done quite carefully. Mistakes might cause the problem that data can be reassigned to persons and anonymized data might be reproduced. This paper gives an overview about recent methods for anonymizing data while showing their weaknesses. How these weaknesses can be used to invert the anonymization (called de-anonymization) is shown as well. Our attacks representing the de-anonymization should help to nd weaknesses in methods used to anonymize data and how these can be eliminated. Zusammenfassung: Im Projekt PArADISE sollen Aktivitats- und Intentionserkennungen in smarten Systemen, etwa Assistenzsystemen in Wohnungen, so durchgefuhrt werden, dass Privatheitsanforderungen des Nutzers gewahrt bleiben. Dazu werden einerseits Auswertungen der Daten sehr nah an den Sensoren, die die Daten erzeugen, vorgenommen. Eine Ubertragung von Daten in die Cloud ndet nur im Notfall statt. Zusatzlich werden aber vor der Ubertragung der nicht vorausgewerteten Daten in die Cloud diese auf Privatheitsanforderungen hin gepruft, indem Anonymisierungsma e getestet und eventuell weitere Anonymisierungen von Daten vorgenommen werden. Diese Anonymisierung von Datenbestanden muss mit gro er Sorgfalt geschehen. Fehler konnen sehr schnell dazu fuhren, dass anonymisierte Datenbestande wieder personalisiert werden konnen und Daten, die eigentlich entfernt wurden, wieder zuruckgewonnen werden konnen. Dieser Artikel betrachtet aktuelle Verfahren zur Anonymisierung und zeigt Schwachstellen auf, die zu Problemen oder gar der Umkehrung der Methoden fuhren konnen. Unsere kunstlich erzeugten Angri e durch De-Anonymisierungen sollen helfen, Schwachstellen in den Anonymisierungsverfahren zu entdecken und zu beheben.
Copyright © 2017 by the paper’s authors. Copying permitted only for private and academic purposes. In: M. Leyer (Ed.): Proceedings of the LWDA 2017 Workshops: KDML, FGWM, IR, and FGDB. Rostock, Germany, 11.-13. September 2017, published at http://ceur-ws.org
Datenschutz wird in der heutigen Gesellschaft zunehmend wichtiger. Durch neuartige Techniken werden immer mehr Systeme ins Leben eingebunden, die Informationen von ihren Nutzern sammeln und auswerten. Die Auswertung kommt neben dem Nutzer auch den Anbietern dieser Softwaresysteme zugute, da sie immer einfacher und detaillierter Informationen uber ihre Nutzer sammeln konnen, um einen besseren Service anzubieten. Fur Nutzer dieser Systeme wird es hingegen zunehmend schwieriger zu erkennen, welche Daten konkret gesammelt und wie diese weiter verarbeitet werden. Zudem wird hau g mit einer Anonymisierung der Daten geworben, wobei allerdings detaillierte Informationen zur Umsetzung hau g nicht zu nden sind.
Erschwerend kommt hinzu, dass Nutzer hau g die Datenschutz- oder Nutzungsvereinbarung aus Grunden der Bequemlichkeit nicht mehr lesen und so keine Ahnung haben, wie ihre Daten weiterverarbeitet werden. Beispielsweise versprachen einige Nutzer in einem Experiment durch die Nutzung eines o entlichen Hotspots ihr erstgeborenes Kind oder liebstes Haustier dem Hoster des Hotspots [12]. Dies zeigt, dass grundsatzlich eine gro e Diskrepanz zwischen der Aufklarungsp icht des Anbieters und der Bereitschaft der Nutzer, diese zu lesen, besteht.
Bei Nutzung von aktuellen Anonymisierungsverfahren muss allerdings die Implementierung genau betrachtet werden, da kleine Fehler fatale Auswirkungen auf das Resultat haben konnen. Zu eng gewahlte Randbedingungen fur eine Anonymisierung von einem Datenbestand konnen beispielsweise dazu fuhren, dass die ursprunglichen Daten rekonstruiert werden konnen, oder zumindest teilweise wieder personenbeziehbare Daten o engelegt werden.
Konkret soll die De-Anonymisierung vor allem fur das
PArADISEFramework1 [
Die Forschung an der Universitat Rostock beschaftigt sich unter anderem interdisziplinar mit Assistenzsystemen. Hierbei sollen zum Beispiel Sturze in Wohnungen erkannt werden. Es wird neben der Sensorik auch die Datenverarbeitung untersucht. An dieser Stelle kommt PArADISE zum Einsatz, 1 Privacy Aware Assistive Distributed Information System Environment (PArADISE) welches die Prinzipien von Privacy by Design umsetzt, indem die Implementierung von datenschutzfordernden Techniken (Privacy Enhancing Technologies, PETs) erfolgt. Dabei werden im Speziellen die rechtlichen Anforderungen nach Datensparsamkeit und Datenvermeidung durch Techniken zur Anfrageumschreibung umgesetzt. Ausgehend von dem reduzierten Datenbestand werden verschiedene Anonymisierungstechniken verwendet, um das Ergebnis der Anfrage datenschutzkonform zu vero entlichen. In diesem Artikel wird beschrieben, wie durch De-Anonymisierungstechniken uberpruft wird, ob der scheinbar anonymisierte Datensatz wieder deanonymisiert werden kann. Ziel der U berprufung ist die Reduzierung von Angri smoglichkeiten innerhalb der Verarbeitungskette im PArADISE-Framework.
Die Auswertung der Rohdaten erfolgt uber SQL-Anfragen, wobei ein
Schichtsystem aus logischen Schichten implementiert wurde. In Abbildung 1 ist dies
gezeigt. Die verfugbaren Gerate zur Auswertung werden nach Leistungsfahigkeit
in unterschiedliche Schichten eingeteilt und Daten zwischen den Schichten
werden nur weiter gereicht, wenn die aktuelle Schicht nicht ausreichend Leistung zur
Durchfuhrung der Anfrage besitzt. Die Anfrage wird dabei aufgespalten und in
mehrere Teilanfragen zerlegt. Jeder Knoten fuhrt die fur ihn maximal mogliche
Teilanfrage aus und reicht den fur ihn nicht ausfuhrbaren Teil weiter. Auf diese
Art und Weise ist es beispielsweise moglich, dass bereits Sensoren einfache
Selektionen oder auch Aggregate uber die letzten Werte berechnen und lediglich das
Ergebnis weiterreichen. Es ist zu beachten, dass im Ergebnis deutlich weniger
Informationen enthalten sind als im Originaldatenbestand aller ausgewerteten
Sensoren. Daher kann Datensparsamkeit auf diese Art sehr gut umgesetzt
werden. Die Anfrageumschreibung des PArADISE-Projekts ist in [
Dazu mussen wir einerseits die zu kontrollierenden Anonymitatsma e und ihre Parameter festlegen, andererseits aber auch Verfahren implementieren, die dieses Anonymitatsma e auf dem in die Cloud zu ubertragenden Datenbestand e zient berechnen konnen (siehe folgendes Kapitel 3). Um zu testen, wie sicher die Anonymitat des Nutzers gewahrleistet ist, entwickeln wir gleichzeitig Angri sverfahren (De-Anonymisierung), die Schwachstellen in der Anonymisierung aufdecken sollen (siehe Kapitel 4). 3
Um die Anonymisierung von Datenbestanden automatisieren zu konnen, werden
entsprechende Ma e benotigt, die den aktuellen Grad der Anonymitat
bestimmen. Sollten die vorliegenden Daten noch nicht anonym genug sein, konnen
Algorithmen genutzt werden, um den Informationsgehalt zu verringern. Dies wird
so lange iterativ in Schritten durchgefuhrt, bis ein entsprechendes Ma erfullt
ist. Dieser Absatz beschreibt entsprechende Methoden zum Messen des Grades
der Anonymisierung. Ein Kern-Bestandteil ist dabei der Quasi-Identi kator [
Innerhalb von PArADISE werden QIs fur die Parametrisierung der
verschiedenen Komponenten und Algorithmen, wie dem Modul zur Generierung von
Datenschutzeinstellungen und dem Praprozessor zur Reformulierung von
Anfragen, genutzt (siehe Abbildung 2). Speziell im Postprozessor werden anhand von
QIs die Anonymitatsma e uberpruft. Durch die vorherige Projektion der
Attributmenge mussen nicht alle Attribute zum Finden von QIs in Betracht
gezogen werden. Durch den in [
Ein sogenanntes "sensitives Attribut\ ist ein Attribut, das nicht mit personenbeziehbaren Informationen in Verbindung gebracht werden darf, da dies der entsprechenden Person schaden konnte. Beispielsweise konnte dieses Attribut die Diagnose in einer Tabelle sein, in der Patientendaten mit entsprechenden Diagnosen abgespeichert sind (siehe Tabelle 1). Wahrend die Informationen der Spalte Diagnose allein nicht problematisch sind, werden sie in Verbindung mit Name und Vorname durchaus kritisch. Die Mengen der sensitiven Attribute und der Attribute von QIs und Schlusseln sind nicht zwangsweise disjunkt. Es kann daher vorkommen, dass jedes Attribut Teil eines QIs ist. 3.1
Die im Folgenden vorgestellten Ma e fur die Anonymitat einer Relation lassen
sich vor allem in Kombination mit der Technik der Generalisierung und
Unterdruckung einsetzen. Diese werden im weiteren Verlauf vorgestellt.
k-Anonymitat
Die k-Anonymitat stellt die geringsten Anforderungen an die zu bewertenden
Daten. Der Wert k gibt dabei an, wie viele Tupel es mit jeweils gleichem QI
geben muss. Eine formale De nition ist in [
Bei t-Closeness wird die Verteilung der Attributwerte des sensitiven
Attributes in Bezug zur Verteilung der Attributwerte in der gesamten Relation
betrachtet. Die Verteilung darf dabei pro q -Block hochstens um t von der
Gesamtverteilung abweichen [
Ein weiteres Ma zum Messen der Anonymitat stellt Di erential Privacy [
Ein typisches Verfahren zur Anonymisierung von Datenbestanden wird als Generalisierung bezeichnet. Es kann auch mit der Unterdruckung kombiniert werden. Konkrete Attributwerte werden dabei auf ein Intervall abgebildet, sodass ein Teil der Informationen verloren geht und der Grad der Anonymisierung steigt.
Die Generalisierung ist hierbei ein spaltenorientiertes Verfahren. Es werden zu generalisierende Attribute ausgewahlt, anschlie end alle Attributwerte dieser Spalten (die Domane) auf ein entsprechendes Intervall abgebildet. Die originalen Werte einer Tabelle bilden die Grunddomane, welche auf weitere Domanen generalisiert wird [13]. Das Verfahren der Unterdruckung arbeitet im Gegenzug dazu auf Zeilenebene. Es kann dazu genutzt werden, um Ausrei er zu streichen, somit ein Anonymisierungsma zu erfullen, und dabei weniger Generalisierungsschritte durchzufuhren. Das Tupel, welches den Wert enthalt, der unterdruckt werden soll, wird dabei komplett generalisiert. Das bedeutet, dass fur alle Attributwerte ein " *" eingetragen wird. Hierbei ist es sinnvoll, eine Obergrenze an moglichen Unterdruckungen anzugeben. Ansonsten konnte es passieren, dass durch den starken Einsatz der Unterdruckung zwar eine Anonymisierung mit vergleichsweise wenig Generalisierungsschritten erreicht werden kann, allerdings sind die Daten nicht mehr reprasentativ, da zu viele Werte gestrichen wurden [13].
In der rechten Relation von Tabelle 1 ist zu erkennen, wie Generalisierung und Unterdruckung arbeiten. Zeile 2 wurde unterdruckt, da das Alter einen stark abweichenden Wert im Verhaltnis zu den anderen Werten darstellt. Um trotz des Wertes k-Anonymitat fur k =2 zu erfullen, hatten die Werte sonst auf ein entsprechend gro es Intervall abgebildet werden mussen und alle Werte hatten mit gro er Wahrscheinlichkeit im selben Intervall gelegen. Die einzelnen q -Blocke wurden zusatzlich farblich hervorgehoben. Sie unterscheiden sich bezuglich des QIs nicht. Ist bekannt, welches Alter die entsprechende Person hat, so ist nicht mehr ersichtlich, welche Diagnose ihr gestellt wurde.
Ein weiteres Verfahren wird als Slicing bezeichnet. Hierbei wird eine Relation R in m vertikale und n horizontale Teilrelationen aufgeteilt. Innerhalb dieser Teilrelationen werden die Tupel zufallig sortiert, bevor alle Teilrelationen wieder zu einer kompletten Relation zusammengefugt werden [10]. Es ist zu beachten, dass unbedingt angegeben werden muss, an welchen Stellen in der Relation die Trennung vorgenommen wurde. Zusammenhangende Auswertungen zwischen Attributen, die in unterschiedlichen Teilrelationen standen, sind nicht mehr moglich, da die Reihenfolge unabhangig und zufallig verandert wurde. Zwischen Attributen, die gemeinsam in einer Teilrelation standen, kann allerdings problemlos eine Auswertung statt nden, da die Zusammenhange nicht verandert wurden. Mit der Technik ist es somit moglich, trotz au erst geringem Informationsverlust eine gute Anonymisierung zu erreichen. Naturlich muss sehr genau beachtet werden, zwischen welchen Attributen die Tabelle aufgetrennt wird. 4
Wir beschreiben nun, an welchen Stellen die vorher vorgestellten Anonymisierungsverfahren versagen. Es lassen sich grundsatzlich zwei unterschiedliche Ansatze unterscheiden. Zum einen kann lediglich die Anfrage zur De-Anonymisierung von Daten betrachtet werden, zum anderen ist auch eine De-Anonymisierung auf Grundlage der vorliegenden Daten moglich. 4.1
Datenbankmanagementsysteme bieten die Moglichkeit, den Zugri komplett auf
einzelne Sichten zu beschranken. Diese Technik kann eingesetzt werden, um den
Zugri nur auf ganz bestimmte Attribute zu erlauben. Das Besondere ist, dass
auch Attributkombinationen vero entlicht werden konnen, die ohne Joins nicht
abzufragen sind, wobei in der Ergebnisrelation der Sicht das verbindende
Attribut ausgeblendet wird und nicht eingesehen werden kann. Anfragen, welche
an das DBMS gestellt werden, die auf die internen Relationen zugreifen, konnen
automatisiert in Anfragen umgeschrieben werden, die lediglich Sichten einsetzen.
Hierzu wird die sogenannte Answering-Queries-using-Views-Technik [
Da wir uns in diesem Artikel schwerpunktma ig mit der datenbasierten
De-Anonymisierung befassen, verweisen wir fur Details zu den bekannten
Verfahren und unsere Weiterentwicklung in Richtung einer
Answering-Queriesusing-Operators-Technik auf [
Bei datenbasierten Verfahren wird lediglich auf die aus der Auswertung erhaltende Ergebnisrelation einer Anfrage geachtet, und nicht auf die Anfrage an sich. Hier kommen die im vorangegangenen Abschnitt vorgestellten Anonymisierungsma e zum Einsatz, um den Grad der Anonymitat zu bestimmen. Diese weisen allerdings Schwachstellen auf, die Beachtung nden mussen.
K-Anonymitat bildet das Anonymisierungsma mit der geringsten Anforderung, daher sind auch hier besonders einfach Schwachpunkte zu nden. Ein gro es Problem stellt die Selektivitat des sensitiven Attributes dar [11]. Sollte ein q -Block k-Anonymitat entsprechend der Anforderungen erfullen, kann es jedoch passieren, dass das sensitive Attribut aller Tupel in diesem Block den selben Wert annimmt. Dies ist problematisch, da so die Daten ohne aktives Zutun des Angreifers aufgrund der Homogenitat extrahiert werden konnen. Beispielhaft ist dies in Tabelle 1 zu sehen.
Das Ma der l-Diversitat nimmt sich dieses Problems teilweise an. Der Wert von l gibt an, wie viele unterschiedliche Attributwerte innerhalb eines q -Blocks vorkommen mussen. Je nach Unterschied der Werte kann dies allerdings noch immer problematisch sein. Als Beispiel sollen Krankheiten dienen. Es kann sein, dass fur das sensitive Attribut eines Blocks lediglich unterschiedliche Krebsarten vorkommen, dies allerdings fur den Angreifer bereits ausreichend viele Informationen sind. Tabelle 1 zeigt dieses Problem. Sobald bekannt ist, dass die Person zwischen 20 und 29 Jahren alt ist und in der Tabelle vorkommt, kann abgeleitet werden, dass sie eine Art von Krebs hat. Eine deutlich bessere Losung des Problems bietet das Ma der t-Closeness. Hierbei wird auch die Verteilung der Werte im sensitiven Attribut innerhalb eines q -Blocks in Bezug zur Verteilung der Werte innerhalb der gesamten Relation betrachtet. Dabei darf ein Schwellwert t nicht uberschritten werden. Bei restriktiver Anwendung kann diese Problematik mit sehr hoher Wahrscheinlichkeit eliminiert werden.
Ein ahnlich gelagertes Problem stellt gutes Hintergrundwissen dar. Problematisch wird dies vor allem bei einer Anonymisierung von Daten, die keinen strengen Anforderungen an k-Anonymitat und l-Diversitat stellt [11]. Es sind immer genau x-1 Fakten notwendig, um ein Tupel aus einer Gruppe von x Tupeln eindeutig zu identi zieren. Durch den Einsatz von t-Closeness kann das Problem gemildert werden, da die Verteilung der Werte fur das sensitive Attribut ahnlich zur gesamten Relation ist. Allerdings ist auch damit eine Identi zierung durch Hintergrundwissen nicht ausgeschlossen.
Je nach vero entlichten Daten kann auch die Sortierung der Tupel dem Angreifer helfen, personliche Daten aus Ergebnissen zu extrahieren. Grundsatzlich sind Ergebnisrelationen immer sortiert. Dies liegt an den internen Speicherstrukturen der Datenbanksysteme [15]. Sollten allerdings mehrere Vero entlichungen der gleichen Daten mit unterschiedlichen Quasi-Identi katoren gemacht werden, so kann es zum Problem kommen, dass diese Daten eventuell einfach uber die Sortierung verknupft werden konnen. In Tabelle 2 ist dies beispielhaft zu sehen. Ahnlich verhalt es sich, wenn der Angreifer einen direkten Zugang zur Datenbank nutzen kann. Damit konnte er die gleiche Anfrage mehrfach stellen und so ho en, dass vom System unterschiedliche Attribute der Quasi-Identi katoren gewahlt werden und so die Anonymisierung unterschiedlich umgesetzt wird. Zusatzlich konnte es auch passieren, dass eventuell ein anderer Quasi-Identi kator gewahlt wird. Das Problem lasst sich allerdings auch sehr leicht beheben, indem die Ergebnisrelation einfach vor der Vero entlichung zufallig sortiert wird.
Bei mehreren Vero entlichungen der gleichen Daten muss darauf geachtet werden, dass immer der gleiche Quasi-Identi kator gewahlt wird, oder zumindest alle Attribute, die im Quasi-Identi kator der ersten Vero entlichung enthalten waren, im Neuen auch enthalten sind. Ansonsten ist es einem Angreifer unter Umstanden moglich, durch die wechselnden Attribute Joins uber den Vero entlichungen zu erstellen und somit private Daten zu rekonstruieren [15]. Ahnlich verhalt es sich bei zeitlich versetzten Vero entlichungen. Hier muss gepruft werden, wie sich die beiden Vero entlichungen unterscheiden. Sollte durch die A nderung des Datenbestandes eine geringere Generalisierung statt nden, konnte es dazu kommen, dass Informationen genauer spezi ziert werden konnen, als es mit der ursprunglichen Vero entlichung moglich war. 5
Besonders wunschenswert ist fur einen Angreifer naturlich eine vollstandige Automatisierung des Angri s. Dies hilft aber nicht nur dem spateren Angreifer, sondern in der Entwicklungsphase bereits dem Entwickler des Assistenzsystems, der das Prinzip Privacy by Design realisieren und Schwachstellen aufdecken mochte. Fur anfragebasierte und datenbasierte De-Anonymisierungen wollen wir daher auch Methoden entwickeln, um Angri e automatisch zu generieren | und diese danach durch Verscharfung der Anonymisierungsma e und Verscharfung der erlaubten Sichten zu verhindern.
Dies wurde sehr viel Arbeit ersparen, ist aktuell aber nur mit au erst gro em Aufwand realisierbar. Eine Hilfestellung fur die Wahl des richtigen Angri svektors hingegen kann durch vergleichsweise einfache Techniken erreicht werden. Durch eine statistische Auswertung der Ergebnisse kann ein schneller Uberblick uber die vorliegenden Daten gewonnen werden.
Hilfreich ist zudem das Suchen nach vorhandenen Quasi-Identi katoren im
Ergebnis der Anfrage, da diese eine Kombination von Attributen darstellen,
die besonders selektiv sind. Hierzu bietet sich vor allem der
TopDownBottomUp-Ansatz an (siehe [
Sollten Werte, welche fur die Bestimmung der statistischen Daten benotigt
werden, aus der Datenbank abgefragt werden, konnte es zu Problemen kommen,
wenn sich in der Zwischenzeit der Datenbestand verandert hat, oder auch die
Ausgabe fur jede Anfrage eventuell anders anonymisiert wurde. Weiterhin wurde
in PArADISE eine Moglichkeit gescha en, Wertebereiche der einzelnen Spalten
einschranken zu konnen, um so fehlerhafte beziehungsweise nicht relevante Werte
aus der statistischen Berechnung ausschlie en zu konnen (siehe [
Durch eine automatisierte Generalisierung konnen die Attributwerte des sensitiven Attributes so lange iterativ generalisiert werden, bis fur jeden q -Block ein eindeutiger Wert zugeordnet ist. Dabei mussen Duplikate nach jeder Iteration geloscht werden. Mit den Informationen ist es einem Angreifer anschlie end moglich, einen allgemeineren, aber immer noch moglichst spezi schen, Wert zu erkennen, ohne dass er aktiv einschreiten muss. 6
Grundsatzlich lasst sich sagen, dass trotz Anonymisierung die Daten nie zu 100 Prozent sicher vor einem Angri sind. Allerdings kann die Moglichkeit der De-Anonymisierung durch Angreifer sehr stark verringert werden. Auf der anderen Seite muss gepruft werden, ob die anonymisierten Daten noch fur die notigen Auswertungen ausreichend Informationen enthalten. Es sollte ein Maximum fur die Werte der Anonymisierungsma e gewahlt werden, sodass gerade noch genugend Informationen fur die gutartigen Anfragen enthalten sind, die von einem Assistenzsystem fur die Analyse erlaubter Aktivitaten (wie Sturze) benotigt werden. Die Ausfuhrung von bosartigen Anfragen, etwa die Ableitung genauerer Nutzerpro le oder Bewegungspro le, die nicht zur Analyse der erlaubten Aktivitatserkennung beitragen, sollten dagegen verhindert werden.
Die fertige Losung sollte auch schon wahrend des Entstehungsprozesses
und vor allem am Ende intensiv aus Sicht eines moglichen Angreifers
betrachtet werden, um eventuelle Schwachpunkte zu lokalisieren und diese abstellen
zu konnen. Die Answering-Queries-using-Views-Technik ist ein sehr
vielversprechender Ansatz, allerdings fehlt fur den produktiven Einsatz noch eine
automatisierte Umschreibung von komplexeren SQL-Operationen. Hieran wird
gerade im Rahmen des PArADISE-Projektes gearbeitet [
Das Schichtkonzept des PArADISE-Frameworks [
Wir danken den anonymen Gutachtern fur ihre konstruktiven Kommentare.