Anonymität zum Schutz der Privatsphäre

Dr. Christian Stingl Daniel Slamanig, M.Sc.(FH) Anonymität zum Schutz der Privatsphäre Die zunehmende Verfügbarkeit von elektronischen Diensten ermöglicht eine effiziente und komfortable Abwicklung von vielen Tätigkeiten des alltäglichen Lebens. Dazu zählen neben beruflichen, auch private Bereiche, wie z.B. Internetbanking, eCommerce, eGovernment und aktuell Dienste im Gesundheitswesen. Gerade im letztgenannten Bereich kann die zeit- und ortsunabhängige Verfügbarkeit von relevanten Gesundheitsdaten die Qualität der Gesundheitsprozesse und somit die Lebensqualität des Einzelnen nachhaltig verbessern. Jedoch bringen diese bereichsübergreifenden Informationen, die theoretisch relativ leicht miteinander verknüpft werden können, die Gefahr des "gläsernen Menschen" mit sich. In diesem Vortrag werden aktuelle und zukünftige Gefahrenpotentiale aufgezeigt und State-of-the-Art-Methoden eingehend diskutiert. Zusätzlich werden auch Konzepte vorgestellt, die von den Autoren entwickelt und international publiziert wurden.

Dr. Christian Stingl / Daniel Slamanig, M.Sc. Dr. Christian Stingl ist Professor für Healthcare IT & Informationssicherheit am Fachbereich Medizinische Informationstechnik der Fachhochschule Kärnten in Klagenfurt. Er war Assistent am Institut für Mathematik an der Universität Klagenfurt und promovierte in Mathematik im Bereich der Kryptographie. Danach war er 10 Jahre als Consultant in der Entwicklung von Informationssystemen im In- und Ausland tätig und seit 2005 ist er Professor an der Fachhochschule Kärnten. Seine Forschungsschwerpunkte umfassen Gesundheitsinformationssysteme und im Speziellen Informationssicherheit im Kontext von Elektronischen Gesundheitsakten.

Daniel Slamanig ist wissenschaftlicher Mitarbeiter in der Forschungsgruppe Healthcare IT & Informationssicherheit am Studienbereich Medizinische Informationstechnik an der Fachhochschule Kärnten. Derzeit absolviert er ein Doktoratsstudium im Fach Informatik im Bereich der Informationssicherheit an der Universität Klagenfurt. Seine Forschungsbereiche umfassen Netzwerksicherheit und Kryptographie und im Speziellen Verfahren zur Gewährleistung der Anonymität und des Schutzes der Privatsphäre.

20.04.2009

ANONYMITÄT ZUM SCHUTZ DER PRIVATSPHÄRE Christian Stingl und Daniel Slamanig Healthcare IT & Information Security Medizinische Informationstechnik Fachhochschule Kärnten

Security Forum 2009, 22. April 2009 Hagenberg

Überblick


Motivation







Gesundheitsakte

Webbasierte Dienste Analyse der Bedrohungen Gegenmaßnahmen Kommunikationsanonymität Authentifikationsanonymität
Datenanonymität






Zusammenfassung

Motivation


Zunahme von webbasierten Diensten


Erhöht den Komfort für die Gesellschaft




Aber

  





E-Commerce, E-Banking, E-Government, E-Health, etc. Personenbezogene Daten sind vermehrt verfügbar („gläserner Mensch“) Mehr Möglichkeiten kompromittierende Informationen abzuleiten

-> das Missbrauchspotential wird immer größer

Bedingt auch immer mehr Datendiebstähle



Sind diese Diebstähle vermeidbar? oder sind diese unabwendbar?

1

20.04.2009

Gesundheitsakten


Elektronische und persistente Speicherung der relevanten Gesundheitsdaten pro Individuum






EHR (electronic health record)






Sensible Daten (DSG 2000) Paradebeispiel

Institutionsübergreifende Akte Moderation: Klinisches Personal

PHR (personal health record)


webbasiert

Benutzer (Individuum)  

Moderation der Akte Rechtevergabe

Google Health


Personal Health Record: Webbasierte Verwaltung von Gesundheitsdaten durch den Benutzer


Integration aus anderen Quellen  





Gesundheitsakten Medizinische Devices (Glukosesensor, etc.)

Eingabe auch durch Benutzer Freigabe von Daten für anderen Benutzer möglich (z.B. ÄrztInnen)

Google Health Würden Sie Ihre Gesundheitsdaten mit Google Health verwalten?

2

20.04.2009

Google Health


Warum gibt es großes Misstrauen gegenüber Google Health?


Fehlendes Vertrauen gegenüber dem Provider Vertrauen ist jedoch absolut notwendig, da die Systemsicherheit ausschließlich von Google realisiert  Missbräuchliche Verwendung der Daten? 




Fehler in anderen Google Diensten




Intransparentes (und möglicherweise unvollständiges?) Sicherheitskonzept



 

z.B. Google Docs

Black Box für Anwender „Security by obscurity“

Österreichische Provider Würden Sie Ihre Gesundheitsdaten bei einem österreichischen Provider verwalten? •Warum gelten dieselben Kritikpunkte für österreichische Provider scheinbar nicht? •

•

Geographische Lage, Gesetzeslage, erworbenes Vertrauen, etc.

Ziel dieser Präsentation


Aufzeigen von Bedrohungsszenarien





Präsentation von Methoden, damit das Sicherheitsniveau erheblich verbessert werden kann








Sensibilisierung der Anwender

Wie kann man Google Health sicher(er) gestalten, sodass die Kritikpunkte für die Anwender nicht mehr relevant sind? Kann das bereits mit Standardmethoden (Verschlüsselung, etc.) erreicht werden?

Wir wollen dafür Verfahren vorstellen, die auf dem Grundprinzip der Anonymität beruhen

3

20.04.2009

Arten von Diensten Öffentliche Dienste




1. Jeder Benutzer kann Informationen konsumieren   

Wikipedia Suchmaschinen Informationsplattformen (Info-Portale)

Lesezugriff für autorisierte Benutzer




2. Mitglieder einer Gruppe können Informationen konsumieren 

Online-Abonnements

Schreibzugriff für autorisierte Benutzer




3. Mitglieder einer Gruppe können Informationen integrieren und anderen Mitgliedern zur Verfügung stellen  

Cloud Storage Dienste (iDisk, Nirvanix, Amazon S3, etc.) Personal Health Records (Google Health, MS Health Vault, etc.)

Arten von Diensten - Übersicht Öffentliche Dienste







Lesezugriff für autorisierte Benutzer Authentifikation




Schreibzugriff für autorisierte Benutzer Authentifikation

Authentifikation

Daten im Kontext von Diensten mit Beispielen aus dem Bereich Gesundheitsakten


Inhaltsdaten


Auflistung von sehr sensiblen medizinischen Informationen   




Metadaten des Dienstes (der Anwendung)






Suchterkrankungen, psychische und psychosomatische Erkrankungen Herzerkrankungen, Infektionserkrankungen Schwangerschaft, etc.

Beziehungen zwischen MedizinerInnen und PatientInnen Beziehungen zwischen PatientInnen und Dokumenten (Befunden)

Kommunikationsmetadaten



Anzahl der Anmeldungen im System Anzahl der transferierten Informationen (Dokumente)

Analog zur Problematik bei der Vorratsdatenspeicherung

4

20.04.2009

Wie kann Datenschutz realisiert werden?




Organisatorische Maßnahmen (Vertrauen absolut notwendig)


Administrative Maßnahmen




Physische Maßnahmen








Security-Policies, Geheimhaltungsvereinbarungen, Audits, Schulung, etc. Zutrittskontrollen, bauliche Maßnahmen, etc.

Technische Maßnahmen (Vertrauen nur bedingt notwendig)


Serverseitige Maßnahmen




Kryptographische Methoden am Client





Zugriffskontrolle z.B. RBAC, ACLs Inhaltsverschlüsselung, Schlüsselmanagement, etc.

Beispiel: Technische Maßnahmen Autorisierung auf Basis von ACLs Einfache Access Control List (ACL)







Daten liegen im Klartext im System




Bei jedem Datenobjekt wird hinterlegt welcher Benutzer welche Rechte hat




Überprüfung erfolgt durch Applikationslogik Umgehen des ACL-Mechanismus durch Insider einfach möglich -> unautorisierter Zugriff auf Daten




ACL mit Inhaltsverschlüsselung







Daten werden am Client verschlüsselt (bzw. entschlüsselt)




Nie im Plaintext im System (Dienst)




Insider hat zwar Zugriff, aber keine Möglichkeit Daten einzusehen




Berechtigungsmanagement auf Basis von Key-Sharing

Autorisierung auf Basis von ACLs


Einfache Access Control List (ACL)

Benutzer 1


User

Recht

Benutzer 1

rwx

…

…

ACL mit Inhaltsverschlüsselung

Benutzer 1

User

Recht

Benutzer 1

E(k,PK)

…

…

Insider - Administrator

? Insider - Administrator

5

20.04.2009

Google Docs Bug


Googles webbasiertes „Office“ und Kollaborationsplattform











Bug im System erlaubte im Februar 2009 Benutzern Zugriff auf fremde Dokumente Auf die sie nie Zugriff hatten! Dokumente liegen „plain“ im System Einfaches ACL-basiertes Zugriffskonzept? 




Anfällig gegenüber Implementierungsfehlern

Details werden nicht veröffentlicht!

Bedrohungen für webbasierte Dienste (1/3)





Was wird primär in Datenschutzkonzepten betrachtet? Externe Bedrohungen






Passive Angriffe: Protokollierung und Analyse Aktive Angriffe: Hacking, Denial of Service (DoS), etc.

Lösungsmöglichkeiten Aktualisierung des Betriebssystems (Patching) Firewalls, Intrusion Detection
Übertragungsverschlüsselung (SSL/TLS, IPsec)



Bedrohungen für webbasierte Dienste (2/3)





Was wird nur rudimentär in Datenschutzkonzepten betrachtet? Interne Bedrohungen


Durch Insider (z.B. Administratoren des Dienstes)




Durch Malware (z.B. Conficker) Studien zeigen, dass dieser Aspekt von hoher Relevanz ist

 





Passive oder aktive Angriffe Bewusste oder unbewusste Aktionen

Lösungsmöglichkeiten


Im Regelfall ausschließlich mittels organisatorischer Maßnahmen




Gibt es auch adäquate technische Maßnahmen?



Geheimhaltungsvereinbarungen, Audits, etc.

6

20.04.2009

Bedrohungen für webbasierte Dienste (3/3)





Wer wird nie in Datenschutzkonzepten betrachtet? „Neugierige“ Personen, die Personen zum Vorzeigen Ihrer Daten nötigen






z.B. Vorstellungsgespräch Offenlegung: erzwungen oder „motiviert“

Lösungsmöglichkeiten Dienste nicht nutzen Offenlegung verweigern (Auswirkungen?)
Technische Maßnahmen (paradoxe Situation)






Wie groß ist die Wahrscheinlichkeit?

Gefahrenpotentiale

Verfahren zur Gewährleistung von Anonymität


Charakteristika








Aktionen werden „im Namen“ einer Anonymitätsmenge durchgeführt Die Anonymität bezieht sich sowohl auf externe, als auch auf (provider-)interne Personen!

Was ist der Unterschied zum Anonymisieren von Daten?

7

20.04.2009

Überblick: Anonymität




Kommunikationsanonymität Authentifikationsanonymität Datenanonymität

Kommunikationsanonymität Datenanonymität Authentifikationsanonymität

Arten von Diensten - Übersicht


Öffentliche Dienste




Lesezugriff für autorisierte Benutzer Authentifikation




Schreibzugriff für autorisierte Benutzer Authentifikation

Authentifikation

Öffentliche Dienste 1. Jeder Benutzer kann Informationen konsumieren


Dienste erfordern keine Authentifikation auf Anwendungsebene




Welche Daten sind involviert?






Inhaltsdaten (Übertragungsverschlüsselung mittels SSL/TLS, IPsec)



Kommunikationsmetadaten

“A Face Is Exposed for AOL Searcher No. 4417749”









AOL publiziert 2006 20 Mio. Suchanfragen „anonymisiert“ Nummer 4417749 führte hunderte Suchanfragen innerhalb weniger Monate durch Durch scheinbar harmlose Suchanfragen konnte Thelma Arnold (62) einfach identifiziert werden Viele kompromittierende Suchanfragen anderer „anonymer“ Personen


„Depressionen und Krankenstand“




„Selbstmord durch Autoabgas“, etc.

8

20.04.2009

Kommunikationsanonymität 1/4


Anonymität durch anonymen Kommunikationskanal








Anonymität bei Kommunikation gegenüber






Anonymität  Innerhalb einer Menge (Anonymitätsmenge) hinsichtlich Aktionen nicht identifizierbar sein  z.B. Menge der potentiellen Sender einer Nachricht Unverkettbarkeit  Aktionen gleicher Benutzer können nicht verknüpft werden  z.B. Nachrichten eines Senders Lauschern am Kanal Kommunikationspartnern (Dienstbetreiber)

Anonymität gegenüber dem Dienstbetreiber





Identifikation eines Benutzers kann (einfach) auf Basis der IPAdresse erfolgen  Source-IP „verrät“ Sender Erstellen von Benutzerdossiers  Beispiel vorherige Folie

Kommunikationsanonymität 2/4


Einfachster Ansatz


Einsatz eines vertrauenswürdigen Anonymisierungsproxys




Source-IP ist für den Empfänger nicht mehr aussagekräftig S: 123 D: 789 S: 789 D: 123

IP: 123


S: 456 D: 789

IP: 456

S: 789 D: 456

IP: 789

Praktikables Konzept in den 1980‘ern von David Chaum


MIX-Netzwerke




Kaskade von Proxys mit „Zusatzfunktionalität“ Freie Implementierungen verfügbar




 

JAP (HTTP): http://anon.inf.tu-dresden.de Tor (TCP): http://www.torproject.org

Kommunikationsanonymität 3/4


Alice will Nachricht m an Bob
Aufgabe eines MIX schicken  Entfernen „einer Schale“ und weiterleiten  Alice verschlüsselt m und Bobs  In Realität mehr als eine Nachricht im Adresse für R3 Netzwerk  Das Ergebnis mit Adresse von R3  Jeder MIX permutiert (umordnen) eingehende Nachrichten vor dem Senden für R2 …  „Keine“ Korrelation von eingehenden und  Zwiebelstruktur (Onion Routing) ausgehenden Nachrichten feststellbar

9

20.04.2009

Kommunikationsanonymität 4/4


Weitere (theoretische) Konzepte


Kooperatives Routing   




Beispiele  




Nachricht wird (zufällig) über Mitglieder eine Menge geroutet Jeder Benutzer hilft aktiv mit „Untertauchen“ in der Menge –> Anonymitätsmenge Crowds Hordes

Zusammenfassung




Tools für anonyme Kommunikation verfügbar Anzahl der Benutzer steigt ständig Jedoch 

Overhead durch Verschlüsselung und Routing -> Performanceeinbußen (höhere Wartezeiten)



Anonymität vs. Web-Personalisierung



 

Relevant bei Diensten mit niedriger Latenzzeit (z.B. Web-browsen) Individualität bei dynamischen Inhalten geht verloren

Lesezugriff für autorisierte Benutzer 2. Mitglieder einer Gruppe können Informationen konsumieren


Dienstanbieter möchte Zugriff nur Mitgliedern der Gruppe gewähren




Identifikation der Benutzer mittels Authentifikationsprotokoll Challenge Response




Jede Authentifikation kann eindeutig einem Benutzer zugeordnet werden




Anzahl und Zeitpunkte der Authentifikation geben dem Dienstbetreiber Auskunft über Verhalten von Benutzern




Beispiel: Zugriff auf Gesundheitsakte 

Häufige Zugriffe -> Gesundheitszustand?



Periodizität der Zugriffe -> Erkrankungsmuster?

Authentifikationsanonymität 1/4


Lediglich Nachweis der Gruppenmitgliedschaft erbringen


Nur Gruppenmitglieder können sich erfolgreich authentifizieren




Dienstanbieter kann Benutzer jedoch nicht identifizieren




Kommunikationsanonymität ist Voraussetzung




Einfaches und impraktikables Verfahren


Alle Benutzer haben den gleichen geheimen Schlüssel k k k‘

Challenge-Response Authentifikation

E(c,k) c

User1

k k‘

User2

k k‘

User3

k k‘

User4

k

10

20.04.2009

Authentifikationsanonymität 2/4


Erbringen des Nachweises der Gruppenmitgliedschaft 1.

Eine versperrte Box für jedes Mitglied der Gruppe mit identischem Inhalt 2. Box wird anonym abgeholt und mit geheimen Schlüssel geöffnet 3. Inhalt wird dem Anbieter anonym zugestellt

Authentifikationsanonymität 3/4


User1

Ring-Authentifikation: Beispiel auf Basis von ClientZertifikaten


„Paralleles“ Challenge-Response Verfahren Verzeichnis c∈R

SK1

PK1

e1=E(c,PK1), e2=E(c,PK2), e3=E(c,PK3)

User2

PK2 c‘=D(e2,SK2)




Große Gruppe -> ineffizient




Wähle zufällige Teilmenge




SK3

„gleiches“ Challenge für alle?




Anonymitätsproblem?




Häufigkeitsanalyse

? c‘=c

…

Überprüfen ob Dienstbetreiber ehrlich ist

User3

PK3

c‘




…

SK2

Authentifikationsanonymität 4/4


Kombiniere anonyme Authentifikation mit anonymen unverkettbaren Tokens (anonyme Transaktionen)


Eine anonyme Authentifikation pro „Session“




Effizientes Token-Protokoll basierend auf (partiell) blinden Signaturen innerhalb einer „Session“




Alle Aktionen in einer „Session“ sind unverkettbar

11

20.04.2009

Übersicht Verfahren Verfahren

Charakteristik

Voraussetzungen

Implementierung

Nachteile

Ring-Authentifikation

Ad-hoc Verfahren

PKI, IBC

Einfach

Anonymitätsmenge

Ring-Signaturen

Ad-hoc Verfahren

PKI, IBC

Einfach

Anonymitätsmenge

Gruppensignaturen

Definierte Gruppe

PKI, proprietär

Aufwendiger

Dynamische Gruppen

Zero Knowledge Identifikationsverfahren (∑-OR Proofs)

Generische Konstruktion

proprietär

Aufwendiger

Anonymitätsmenge

Anonyme (erneuerbare) Token

Ticketsystem

Minimal

Einfach

Diebstahl

Ring-Authentifikation & anonyme Token

Kombination

PKI

Einfach

„Clonen“

Anonyme Credential Systeme

Komplexe Autorisierung möglich

PKI, proprietär

Komplex

Infrastruktur

Attributbasierte Kryptographie

Komplexe Autorisierung möglich

IBC

Komplex

Schlüsselmanagement

Schreibzugriff für autorisierte Benutzer 3.




Mitglieder einer Gruppe können Informationen integrieren und anderen Mitgliedern zur Verfügung stellen Anforderungen







Benutzer integrieren Daten in ein System Die Zuordnung der Daten zum Benutzer darf weder für Externe, noch für Interne eruierbar sein Verknüpfungen zwischen Daten dürfen nicht feststellbar sein

Grundvoraussetzungen




Anonyme Kommunikation Anonyme Authentifikation Inhaltsverschlüsselung  

Muss clientseitig durchgeführt werden Anonymisierung von Daten ist in unserer Meinung nach nicht sinnvoll!

Problemstellung Wie können personenbezogene Daten anonym abgelegt und dann effizient wiedergefunden werden? Wie können die Metadaten so „verschleiert“ werden, sodass keine sinnvollen Aussagen mehr ermöglicht werden?

12

20.04.2009

Beispiel Überführung von Master-Detail-Beziehungen PERSON

FOLDER

PERSON_PK

1:n

NAME

FOLDER_PK

FILE

1:n

FILE_PK

PERSON_PK

FOLDER_PK

NAME

NAME REFERENCE

PERSON

FOLDER

PERSON_PK

FOLDER_PK

PERSON_PK_2_ENC

X

NAME

FOLDER_PK_2_ENC

FILE FILE_PK

X

FOLDER_PK_2

PERSON_PK_2

NAME

NAME

REFERENCE

Geheimhaltung Metadaten

Geheimhaltung Inhaltsdaten

Beispiel Zugriff auf ein Dokument Client (Requests) 1

Anonyme Authentifikation

2

Anonyme Transaktion: Selektiere Personen inkl. der eigenen aus der Tabelle Person

3

Entschlüsselung des eigenen Datensatzes (nur dieser kann entschlüsselt werden!) -> Person_Pk_2 bekannt

4

Anonyme Transaktion: Selektiere alle Folder, die zu Person_Pk_2 gehören

5

Entschlüsselung des Folder_Pk_2 (pro Folder)

Server (Responses)

Übermittlung der Personen

1 und 2 sind unverkettbar

Übermittlung der Folder

2 und 4 sind unverkettbar

6

Anonyme Transaktion: Selektiere alle Files, die dem Folder zugeordnet wurden

Übermittlung der Files

4 und 6 sind unverkettbar

7

Anonyme Transaktion: Eruiere die Referenz zum Dokument und fordere das verschlüsselte Dokument an

Übermittlung des Dokuments

6 und 7 sind unverkettbar

8

Entschlüsselung des Dokuments

Datenanonymität: Identitätsprofile

Authentifikation mittels unterschiedlicher Passwörter

13

20.04.2009

Datenanonymität: Identitätsprofile

Zusammenfassung Dienste/Bedrohungen und Methoden Dienst

Methoden

Öffentliche Dienste

Kommunikationsanonymität

Lesezugriff für autorisierte Benutzer

Kommunikationsanonymität Authentifikationsanonymität

Schreibzugriff für autorisierte Benutzer

Kommunikationsanonymität Authentifikationsanonymität Datenanonymität

Bedrohung

Methoden

Externe Bedrohung (passiv)

Kommunikationsanonymität

Externe Bedrohung (aktiv) Interne Bedrohung

Kommunikationsanonymität Authentifikationsanonymität Datenanonymität

„Neugierige“ Person

Kommunikationsanonymität Authentifikationsanonymität Datenanonymität Identitätsprofile

Zusätzliche Aspekte


Ressourcenlimits





Verfügbarkeit von Schlüsselinformation





Scheint unlösbar, können aber mittels partial blind signatures realisiert werden Verlust: Secret sharing schemes (SSS)

Kombination der konkreten Methoden muss sorgfältig gewählt werden


z.B. Datenanonymität kann anonyme Authentifikation konterkarieren

14

20.04.2009

Zusammenfassung









Datendiebstähle nehmen zu Missbrauchspotential steigt durch die Zunahme unterschiedlicher Dienste -> enorme Gefährdung für die Privatsphäre der BürgerInnen Adäquates Sicherheitskonzept muss Grundvoraussetzung für Dienste werden


Ansatz




Häufig gewählter Ansatz

 

Vertrauen ist gut, Kontrolle ist besser Kontrolle ist gut, Vertrauen ist schneller (günstiger)

DANKE FÜR IHRE AUFMERKSAMKEIT Christian Stingl: [email protected]

Daniel Slamanig: [email protected]

15