Dresden Identity Management - DRIM Sebastian Clauß, Thomas Kriegelstein Hauptseminar Technischer Datenschutz, 3. Februar 2004

Dresden Identity Management - DRIM

Sebastian Clauß, Thomas Kriegelstein

Hauptseminar Technischer Datenschutz, 3. Februar 2004

2 http://drim.inf.tu-dresden.de/

Gliederung

Was ist Identitätsmanagement? Wie kann Identitätsmanagement Online realisiert

werden? Wie werden diese Fragen in DRIM angegangen? Identitätsmanagement am Beispiel des Webshops Technische Details Fazit Ausblick


Was ist Identitätsmanagement?

Identitätsmanagement bedeutet, daß eine Person grundsätzlich wählen kann, wie anonym bzw. mit welchen persönlichen Informationen und wie zurechenbar die gegenüber ihren Kommunikationspartnern in Erscheinung tritt. [1]

Jeder tut es - offline Klärung der Fragen:

Was weiß mein Gesprächspartner über mich? Was kann er anderen gegenüber glaubhaft über mich

behaupten? Was lasse ich ihn über mich wissen.

[1] Marit Köhntopp, Andreas Pfitzmann: Informationelle Selbstbestimmung durch Identitätsmanagement; Kiel, 2001


Was ist Identitätsmanagement? - Die Beteiligten

Kommunikationspartner Dienstnehmer Diensteanbieter Dritte Parteien

Unbeteiligte Lauscher Betrüger Strafverfolgungsbehörden


Was ist Identitätsmanagement? - Wer tut was?

Was tun die Beteiligten? Kommunizieren – Daten übermitteln Interagieren – Dienste nutzen/erbringen

Welche Interessen haben Kommunikationspartner? Anonymität/Selbstbestimmte Wiedererkennbarkeit Auswertung bisheriger Kommunikation• Schutzziele gegenüber allen:

• Schutz vor ungewünschter Verkettung der Aktionen

• Schutzziele gegenüber unbeteiligten:• Vertraulichkeit und Integrität• Anonymität



Welche Interessen haben Dienstnehmer? Dienstnutzung, hohe Dienstqualität

Sicherheit soll nicht stören Datensparsamkeit• Schutzziele gegenüber Diensteanbietern:

• Schutz vor unberechtigtem Erhalt eigener Daten• Schutz vor unberechtigter Nutzung eigener Daten• Schutz vor unberechtigter Weitergabe eigener Daten



Welche Interessen haben Diensteanbieter? Möglichst hoher Profit Authentische Daten zur Verminderung des Risikos Kalkulierbare Schadensregulierung• Schutzziele gegenüber Dienstnehmer:

• Schutz vor Betrug• Schutz vor Dienstnutzung ohne Bezahlung• Schutz vor Diensterbringung für Unberechtigte

Dritte Parteien sind im wesentlichen Diensteanbieter.


Wie kann Identitätsmanagement Online realisiert werden?

Voraussetzung für Identitätsmanagement ist die Kenntnis der Kommunikationsumstände

Wer redet mit mir? Warum rede ich mit ihm? Wann rede ich mit ihm?

Manuell Weit verbreitet Fehleranfällig

Automatisiert Genügend viele Abstufungen? Umstände genau genug abgebildet?


Welche Anforderungen an das automatisierte Identitätsmanagement gibt es?

Aufteilung der Verantwortlichkeiten zwischen Anwendung und Manager Mensch (Nutzer, Dateninhaber) Anwendung (Aktionen) Identitätsmanager (Datensicherheit, Datenschutz)

Durchsetzen der Verantwortlichkeitsbereiche Formalisierung der Kommunikationsumstände Information des Nutzers


Welche Anforderungen an die Anwendung gibt es?

Alle Kommunikation unter Benutzung des Managers Verkettbarkeit und Anonymität sonst nicht kontrollierbar

Konfiguration des Managers durch die Anwendung Vereinfachung und Anpassung an Anwendung

Preisgabe personenbezogener Daten durch Manager - nicht durch die Anwendung Verkettbarkeit/Anonymität/Nachvollziehbarkeit

Dienste kommunizieren mit Manager des Nutzers Dienste erfragen personenbezogene Daten beim

Manager – nicht bei der Anwendung Automatisierung sonst unmöglich

[2] Sebastian Clauß, Marit Köhntopp: Identity Management and its support of multilateral security; Dresden, 2001


Welche Anforderungen an den Manager gibt es?

Beachtung der Nutzervorgaben bei: Beschränkung der Verkettbarkeit von Aktionen Erwerb und Verwaltung von Beglaubigungen Einsatz von Beglaubigungen Erfassung und Speicherung personenbezogener Daten Preisgabe personenbezogener Daten Überprüfung vorgelegter Beglaubigungen Auswertung bisheriger Aktionen und Ermittlung der

Verkettbarkeit

Nach [2] Sebastian Clauß, Marit Köhntopp: Identity Management and its support of multilateral security; Dresden, 2001


Welche Anforderungen sollen auf Anbieterseite realisiert sein?

Zugriff/Nutzung setzt Verwendungszweck etc. durch

Auskunft Löschung Berichtigung Sperrung

Widerruf der Nutzungserlaubnis


Wie werden diese Fragen in DRIM angegangen? - Beweisbarkeit

Generierung/Verwendung von Pseudonymen Pseudonym ist eine Referenz auf den Nutzer Pseudonym ist global einmalig und nicht fälschbarAnonymitätsgrad vollständig kontrollierbar

Verkettbarkeit/Beweisbarkeit Pseudonym entspricht öffentlichem Signaturschlüssel Authentische Zuordnung beliebiger Daten möglich Austausch selbstsignierter Dokumente (unter Pseudonym)

• Erfüllte Schutzziele:• Kontrolle der Verkettbarkeit, weil alles relativ zu einem

Pseudonym• Beweisbarkeit (allerdings relativ zum Pseudonym)


Wie werden diese Fragen in DRIM angegangen? - Datenschutz: Verwaltung personenbezogener Daten

Es gibt einen Pool für eigene personenbezogene Daten Sonst Betrug vereinfacht Preisgabe der Daten durch Regeln bestimmt Fremdbeglaubigungen üblicherweise nur für einen Inhalt

Zur Formalisierung wird das P3P-Namensschema verwendet Umfassend, wenige Fehlstellen Softwarebibliothek existiert

Vorhandene Fremdbeglaubigungen zu Datenfeldern werden gespeichert


Wie werden diese Fragen in DRIM angegangen? - Datenschutz: Verwaltung personenbezogener Daten


Wie werden diese Fragen in DRIM angegangen? - Datenschutz: Datenspeicherung

Im Filesystem des Nutzers als Datei oder In einer Datenbank

Verschiedene DBMS unterstützt

Verschlüsselung der Inhalte auch in der Datenbank möglich Speicherung der Daten bei Anbieter möglich

• Erfüllte Schutzziele:• Verfügbarkeit (zentrale Datenbank oder lokal)• Vertraulichkeit (Verschlüsselte Speicherung)


Wie werden diese Fragen in DRIM angegangen? - Datenschutz: Datenübermittlung

Anfrage und Preisgabe mit angepaßtem P3P Bei Anfrage Angabe von

Verwendungszweck, Speicherdauer und Empfänger

Formulierung der Regeln in angepaßtem APPEL Einsatz von Fremdbeglaubigungen derzeit nicht

möglich

• Erfüllte Schutzziele:• Authentische Anfrage• Authentische Preisgabe (selbstsigniert)

• Offene Schutzziele:• Authentische Preisgabe (fremdsigniert)


Wie werden diese Fragen in DRIM angegangen? - Betrugsschutz: Schadensregulierung

Dienstnutzer kann Deanonymisierbarkeit erlauben Diensteanbieter kann Deanonymisierbarkeit

einfordern Treuhänder kann Deanonymisierung durchführen

Schadensregulierung ist damit außerhalb des Systems möglich

Voraussetzungen für Schadensregulierung sind bekannt und erfüllbar


Wie werden diese Fragen in DRIM angegangen? - Verbindungsschutz: Verbindungssicherung

SSONET mit SSL vergleichbar Vertraulichkeit Integrität Zurechenbarkeit besser in darüberliegenden

Protokollen Grundlegende Anonymität durch Anonymisierungs-

dienst AN.ON

• Erfüllte Schutzziele:• Schutz vor Kenntnisnahme und Verfälschung durch

Unbeteiligte• Schutz gegen Verkettbarkeit auf Netzebene


Wie werden diese Fragen in DRIM angegangen? - Verbindungsschutz: Verbindungssicherung


Wie werden diese Fragen in DRIM angegangen? - Nachvollziehbarkeit: Protokollierung

Verbindungsumstände: Zeitpunkt, Partner, Rolle Verbindungsinhalte: mit Verwendungszweck,

Speicherungsdauer und Empfänger Übermittelte, personenbezogene Daten Empfangene, personenbezogene Daten

Inhalte werden ersetzt, nicht gelöscht Nicht protokolliert werden:

Anwendungsdaten Ermöglichung der Deanonymisierung

Übersichtliche Ansicht der Protokolle existiert• Erfüllte Schutzziele:

• Nachvollziehbarkeit


Wie werden diese Fragen in DRIM angegangen? - Nachvollziehbarkeit: Protokollierung


Wie werden diese Fragen in DRIM angegangen? - Automatisierung

Kontextbestimmung: Pseudonym des Gegenüber -> Wer Aktion/Zweck -> Warum Verbindungsumstände bestimmen Rolle

Regelauswertung: Rolle bestimmt Regeln für:

Pseudonymwahl/-wiederverwendung Datenpreisgabe Deanonymisierbarkeit

Vom Kontext über die Rolle zur Regel





Restriktionen für die Rollenverwendung Rolle wird vom Nutzer festgelegt

Nicht durch Wechsel des Gegenübers, der Transaktionsart, der Anwendung zu beeinflussen

Warum? Gegenüber: Vertrauenseinstufung/Reputation notwendig Transaktionsart: derzeit unbestimmt Anwendung: gleiche Rolle in verschiedenen Anwendungen

nutzbar

Rolle wird von Anwendung an Manager übermittelt Granularität der Aktionen kennt nur die Anwendung

Rolle kann an Benutzeroberfläche überprüft werden




Identitätsmanagement am Beispiel des Webshops

Vorkonfiguration: Festlegung der Rolle Festlegung des Anonymitätsdienstes

Verbindungsaufbau: Anwendung fordert Verbindung an Aushandlung über Verbindungssicherheit Empfang des Serverpseudonyms Wahl des eigenen Pseudonyms Übermittlung des eigenen Pseudonyms Sicherung der Verbindung





Datenübertragung: Anforderung einer Webseite Empfang der Seite

Auslösen des Kaufs: Nutzer: Anforderung einer Webseite Anbieter: Anforderung der Lieferadresse Nutzer: Auswerten der Regeln hierzu Nutzer: Übermitteln der Lieferadresse Anbieter: Auslösen der Lieferung

Anzeige des Resultats: Empfang der Seite




Technische Details - Architektur

Steuerung des Manager-Kerns über RMI möglich Trennung der JVMs Abschottung der Datenhaltung Sandbox für Anwendung Performante Datenübermittlung durch Worker statt RMI Verschlüsselung für Worker und RMI

Anwendung Manager-GUI

Manager-Kern

Datenhaltung Regelengine SSONET PKI Signatur


Technische Details - Verbindungsaufbau

AN.ON Kompatibiliät Jede Verbindung geht vom Dienstnehmer aus

SSONET tauscht Einstellungen XML kodiert aus Pseudonyme in selbstsignierten X.509 Zertifikaten Responder wählt Pseudonym ohne Kenntnis des

Initiator-Pseudonym Challenge-Response für Test auf Pseudonymbesitz


Technische Details - Managerschnittstelle

Listener (auch für RMI) log/setStatus/baseConfigurationChanged contextListChanged/contextDataChanged

Verbindungsmanagement - SSONET createContext/registerContext/unregisterContext

Deanonymisierbarkeit - PKI isDetectablePartner/ensureDetectablePartner

Signaturen - XML Signatur signDocument/verifyDocument

Datenhaltung - PSMAN requestData getReceivedData/registerReceivedData getSentData/registerSentData


Technische Details - Steuerungsschicht

Kommunikation in bestehender Nutzdatenverbindung Anhalten der

Nutzdatenübertragung Kommunikation der

Manager Fortsetzung der

Datenübertragung Mehrstufiges Anhalten der

Datenübermittlung Nutzdaten Managerkommunikation SSONET Aushandlung


Technische Details - Datenhaltung

DBMS per JDBC oder Datei in XML Keine Transaktionen, meist nur ,,Anhängen'' Eigene Oberfläche – in Manager einbettbar Verschlüsselung einzelner Spalten möglich

Erhalt referentieller Integrität TripleDES mit Schlüsselgenerierung aus Passphrase

Typsicherheit: Tabelle=Java-Klasse Derzeitig Unterstützung für:

MySQL, PostgreSQL, Sybase

SQL: Create: Anpassung pro DBMS notwendig Insert, Update, Delete: gemeinsame SQL-Oberklasse


Technische Details - Übermittlung personenbezogener Daten

Anwendung fordert Daten über Manager an Angabe von Verwendungszweck, Speicherdauer und

Empfänger

Anforderung in P3P', selbstsigniertes XML-Dokument

Antwort in P3P', selbstsigniertes XML-Dokument Auswertung von Regeln in APPEL' Mehrstufige Aushandlung mit Prüfen von

Bedingungen möglich


Technische Details - XML-Signatur

Verwendung der Enveloping Signature<?xml version="1.0"?>

<ds:Signature>

<ds:Object id="#1">Daten...</ds:Object>

Signatur...

</ds:Signature>

Genau ein unterschriebenes Objekt pro Dokument Unterschrift mit DSA-Signaturschlüssel=Pseudonym


Technische Details - Entwicklungsumgebung

Eclipse - Programmierung Netbeans - GUI, Programmierung CVS - Versionsverwaltung JUnit - Unittests für Kernkomponenten JDepend - Abhängigkeitstests für Pakete Ant - Buildsystem JDK 1.4.2 - Zielplattform Jigsaw - Webserver, Webproxy, Servletcontainer Periodische Builds aller aktuellen Pakete Versionsverwaltung umfaßt auch Webseite

http://drim.inf.tu-dresden.de/


Fazit

Performance unzureichend – Kryptografie in Java Statische Rollen

Kurzfristiger Wechsel nicht möglich Änderungen nur zeitweilig

Abgrenzung/Zusammenfassung von Transaktionen unzureichend, derzeit Transaktion=Verbindung

Anwendungsintegration Als Proxy für einen Webbrowser: unflexible Rollenwahl Integration in Anwendung: hoher Aufwand

Prototyp läuft mit Identitätstreuhänder stabil.


Ausblick

Beschränkung Transaktion=Verbindung aufheben Integration anonymer Beglaubigungen (IDEMIX) Fremdbeglaubigte Daten (Attributzertifikate) Reputation für Kommunikationspartner Verbesserung der Benutzerfreundlichkeit Überprüfung der Sicherheitseigenschaften der

eingesetzten Software

Documents

Dresden Identity Management - DRIM Sebastian Clauß, Thomas Kriegelstein Hauptseminar Technischer Datenschutz, 3. Februar 2004