Lösungen

Auf dieser Seite finden Sie die Lösungen zu den Übungsaufgaben aus dem Buch.

Aufgabe 2.1
„Klassische“ Schutzziele der IT-Sicherheit stehen gelegentlich im Widerspruch zum Datenschutz – zeigen Sie einen solchen Zielkonflikt an einem konkreten Beispiel auf!

Häufig wird die Authentizität im Widerspruch zur Anonymität gesehen. Ein Beispiel: Der Betreiber eines Webservers möchte den Zugriff auf eine bestimmte Personengruppe einschränken. Er legt eine Liste berechtigter Benutzer an und verlangt von jedem Benutzer einen Login mit echtem Namen und Passwort (Authentifizierung ist in diesem Fall Vorbedingung für die Autorisierung). Das Schutzziel Authentizität wird hier in der Regel erreicht werden, doch kann der Betreiber des Webservers auch genau nachvollziehen, wer wann welche Teile der Webpräsenz abgerufen hat (hierbei handelt es sich um personenbezogene Daten). Ein Mechanismus mit gemeinsamem Passwort würde den Datenschutz besser wahren, aber das Schutzziel Authentizität wäre hier nicht mehr erreicht (und bei Missbrauch auch nicht nachvollziehbar, wer beispielsweise das Passwort weitergegeben hat). 
Ein weiteres Beispiel ist ein potentieller Konflikt zwischen Verfügbarkeit und Datenschutz: Um die Verfügbarkeit von Web-Anwendungen zu erhöhen, werden diese Dienste von verschiedenen, weltweit verteilten Standorten aus erbracht. Dazu müssen jedoch (ggf. zum Teil personenbezogene) Daten repliziert und an diese Standorte verteilt werden, und zumindest die IP-Adresse des Benutzers wird an den Standorten bekannt, mit denen er kommuniziert – oft, ohne dass dem Benutzer dies bewusst ist. Das Datenschutzrecht an diesen Standorten ist oft weniger streng als das europäische, so dass diese spezielle Maßnahme zur Erhöhung der Verfügbarkeit im Widerspruch zum Datenschutz gesehen wird.

Aufgabe 2.2
Geben Sie ein konkretes Beispiel eines Angriffs an, durch den ein Angreifer eine positive Anonymitätsdifferenz erzielen kann, ohne dabei ein Subjekt eindeutig zu identifizieren! Wie können Sie die Anonymität in Ihrem Beispiel messen?

Der Betreiber eines Webservers möchte einen Besucher einer Website identifizieren. Im ersten Schritt weiß er nur, dass der Besucher ein Internetnutzer ist. In aller Regel kann er durch einen Reverse Lookup im DNS den Provider des Nutzers bestimmen (oft, insbesondere bei regionalen Providern, auch die Region des Besuchers). Damit ist die Anzahl in Frage kommender Personen von allen Internetnutzern auf alle Kunden eines bestimmten Providers eingeschränkt. In einem zweiten Schritt kann der Betreiber ggf. durch Verwendung eines Geolokalisierungsdienstes die Region weiter einschränken und weiß, dass der gesuchte Nutzer einer der Kunden eines Providers in einer bestimmten Stadt ist (nicht immer möglich). 
Gemessen wird die Anonymität hier einfach als die Anzahl in Frage kommender Personen.

Aufgabe 3.1
Geben Sie für die dargestellte Tabelle die Attribute an, die zu einem Quasi-Identifikator gehören! Wie könnten Sie vorgehen, um k-Anonymität a) durch Löschen von Tupeln und b) durch Generalisierung herzustellen? (Nehmen Sie zum Beispiel k = 3 an). 

Die Definition eines Quasi-Identifikators lässt hier mehrere mögliche Antworten zu. So könnten z.B. Vorname und Nachname oder Matrikelnummer (es kommt hierbei darauf an, wen man als möglichen Angreifer sieht; Mitarbeiter des Prüfungssekretariats können einfacher von der Matrikelnummer auf eine Person schließen als beliebige Dritte) Quasi-Identifikatoren bilden. Um eine k-anonyme Tabelle zu erstellen, würde man diese Informationen aber sinnvollerweise ohnehin weglassen (aus Praktikabilitätsgründen tun wir das; das heißt nicht, dass sie nicht zu einem Quasi-Identifikator gehören). Auch Geschlecht, Alter und Größe ermöglichen gemeinsam eine Identifikation, wenn man den entsprechenden Kurs besucht und die Teilnehmer anschaut. 
Die Punktzahl ist für Dritte eher nicht zugänglich und gehört daher nicht zu einem Quasi-Identifikator. 
Wir gehen hier vom Quasi-Identifikator (Geschlecht, Alter, Größe) aus und entfernen die Felder (Vorname, Name, Matrikelnummer), da diese schon alleine eine eindeutige Identifikation ermöglichen könnten. Alternativ könnten diese im Fall der k-Anonymisierung durch Generalisierung ebenfalls generalisiert werden – bei k-Anonymisierung durch Unterdrückung von Tupeln bliebe aber kein Tupel übrig.

Zunächst zur Unterdrückung von Tupeln: 
Bemerkung: „Tupel“ sind in der Sprache relationaler Datenbanken die Zeilen. Hier werden alle Zeilen entfernt, die die Bedingung der k-Anonymität verletzen. Man kann beispielsweise erst nach einer Spalte (Attribut) sortieren und alle Tupel entfernen, bei denen schon in dieser Spalte die k-Anonymität verletzt wird. Anschließend bezieht man die weiteren Spalten mit ein; übrig bleiben nur die Zeilen, die die k-Anonymität nicht verletzen. Dass die Punktzahlen jeweils identisch sind, hat keine Bedeutung (sondern ist lediglich ein Beispiel für den Homogenitätsangriff).

Bei der Generalisierung gibt es nicht nur eine mögliche Lösung oder ein mögliches Vorgehen. Beispielsweise könnte man wiederum nach einer Spalte sortieren, dort eine Generalisierung vornehmen, um jeweils für mindestens drei Zeilen identische Werte zu erhalten. Im Anschluss könnte man dann die weiteren Spalten einbeziehen (die so weit generalisiert werden, dass insgesamt die k-Anonymität erreicht wird). In der Beispiellösung wurden jeweils drei bis vier Personen ähnlicher Größe zusammengefasst und beim Alter eine grobe Generalisierung in Kauf genommen.

Aufgabe 4.1
Warum wird die Circuit-ID nicht global für den gesamten Circuit gewählt? Warum werden stattdessen Circuit-IDs gewählt, die jeweils nur zwischen zwei Knoten gelten?

Ansonsten könnte ein Angreifer, der an unterschiedlichen Knoten die eingehenden und ausgehenden Kommunikationsverbindungen einsehen könnte, einfach über die konstante Circuit ID Rückschlüsse über die Kommunikationspartner ziehen. Würde der Angreifer insbesondere den Start-Knoten und den End-Knoten eines Virtual Circuits einsehen können, hätte er damit über die konstante Circuit ID direkt die Kommunikationsbeziehung zwischen den beiden Partnern aufgedeckt. 

Aufgabe 4.2
Warum ist es bei Tor kein Problem, dass Bob während des Verbindungsaufbaus den Hash-Wert des berechneten Sitzungsschlüssels an Alice überträgt?

Es wird eine kryptographische Hash-Funktion eingesetzt. Das bedeutet (falls die Hash-Funktion die Anforderungen tatsächlich erfüllt), dass es nicht effizient möglich ist, das (bzw. ein) Urbild zu ermitteln. Ein Angreifer kann also den Schlüssel nicht aus dem Hash-Wert ableiten. 
Die Lösung hat in diesem Fall nicht direkt damit zu tun, dass der Schlüssel per Diffie-Hellman ausgehandelt wurde; allerdings garantiert die Länge des ausgehandelten Schlüssels, dass Brute-Force-Angriffe oder auch Angriffe mit „Rainbow Tables“ erfolglos bleiben.

Aufgabe 5.1
Welche Dienste an Ihrer Universität/in Ihrem Unternehmen benötigen (Teil-) Identitäten von Studierenden/Mitarbeitern? Unter welchen Teil-Identitäten treten Sie gegenüber diesen Diensten auf? Wie authentifizieren Sie sich? Wie gelangen Sie an diese Teil-Identitäten? Berücksichtigen sie auch Dienste, die nicht von der Universität/von dem Unternehmen selbst angeboten werden. Welche Eigenschaften sollte eine Identitätsmanagement-Lösung haben? Ist eine einheitliche Lösung für alle Dienste denkbar?

Die Antwort hängt stark von der jeweiligen Organisation ab. An einer Universität gibt es typischerweise einen Dienst zur Verwaltung von Kursen und Prüfungen, einen Dienst zur Bereitstellung und zum Abruf von Lehrmaterialien, einen Dienst zur Ausleihe von Büchern in der Bibliothek, einen Dienst zum Login auf Pool-Rechnern, etc.; bei all diesen Diensten werden (Teil-) Identitäten benötigt. Häufig wird das gleiche Pseudonym (ein einmal zugewiesener Benutzername) nebst zugehörigem Passwort verwendet, aber es liegen nicht alle Attribute bei allen Diensten vor (bspw. nicht die ausgeliehenen Bücher bei der Prüfungsverwaltung). 
Neben den von der Universität direkt angebotenen Diensten gibt es auch Datenbanken (z.B. IEEEXplore), die eine Teilidentität nutzen: Ihnen wird bei Nutzung des Uni-Netzes eine IP-Adresse zugewiesen, die externe Datenbanken zur Authentifizierung nutzen können. 
Eine Identitätsmanagement-Lösung sollte eine einfache und möglichst einheitliche Authentifizierung und Verwaltung der zu den jeweiligen Teilidentitäten gehörigen Attribute ermöglichen. Eine einheitliche Lösung für alle genannten Dienste ist vermutlich nicht realisierbar, denn dafür müssten alle (auch externen) Dienste diese Lösung unterstützen. Für viele Web-Anwendungen innerhalb einer Universität kann aber eine einheitliche Authentifizierung anhand des Benutzernamens stattfinden, wobei die Login-Daten an eine zentrale Infrastruktur übermittelt werden. Dieser Ansatz erhöht die Bequemlichkeit für Nutzer, doch besteht bei unbemerkter Kompromittierung eines Dienstes die Möglichkeit, dass eingegebene Authentifizierungsdaten durch Angreifer mitgelesen werden. 

Aufgabe 6.1
Bei dem vorgestellten Bezahlverfahren nach Chaum ist es möglich, dass ein Kunde mit einem Händler kollaboriert, um zu betrügen. Der Kunde wickelt dabei eine Bezahlung mit einem Händler ordnungsgemäß ab. Danach gibt der Kunde die Challenge dieses Händlers an den zweiten Händler und bezahlt mit der gleichen Münze. Kann die Bank den betrügenden Kunden identifizieren? Kann die Bank den betrügenden Händler identifizieren? Welcher Lösungsansatz könnte dieses Problem verhindern?

Die Bank kann erkennen, dass ein Kunde betrogen hat; sie kann aber nicht feststellen, welcher (die Offenlegung funktioniert nur bei unterschiedlichen Challenges). Ebenso weiß die Bank, dass mit hoher Wahrscheinlichkeit einer der beiden Händler an dem Betrug beteiligt war, kann aber nicht feststellen, welcher der beiden. Ein möglicher Lösungsansatz ist es, einen Teil der Challenge jeweils an die Identität des Händlers zu knüpfen.

Aufgabe 7.1
Ist der Einsatz von „Device Fingerprinting“ auf einer Website für Nutzer erkennbar?

Dies hängt von der konkreten Ausgestaltung des Device Fingerprintings ab. Sofern nur die „normalen“ Attribute analysiert werden, die standardmäßig bei http übermittelt werden (etwa unterstützte Sprachen sowie Betriebssystem- und Browserversion, etc.), ist das Device Fingerprinting für Nutzer nicht erkennbar. Sollten zusätzliche Attribute der Client-Seite über JavaScript ermittelt werden (etwa Zeitzone, Bildschirmauflösung, Schriftarten, installierte Plugins, etc.), wäre es für Nutzer prinzipiell möglich, den Einsatz von Device Fingerprinting zu erkennen; hierzu müssten Nutzer allerdings den Quellcode der Website untersuchen. Praktisch ist der Einsatz von Device Fingerprinting also sehr viel schwieriger zu erkennen (und zu verhindern; ohne JavaScript funktionieren nämlich viele Websites nicht mehr) als etwa ein Tracking mittels Cookies.

Aufgabe 8.1
Kann OTR Messaging auch für die E-Mail-Kommunikation verwendet werden?

Nein, da die E-Mail-Kommunikation typischerweise asynchron stattfindet, d.h. Sender und Empfänger sind nicht gleichzeitig online, was für den beim OTR Messaging zum Einsatz kommenden DH-Schlüsselaustausch allerdings nötig wäre. 

Aufgabe 9.1
Die Basic Access Control verwendet Seriennummer, Geburtsdatum und Ablaufdatum (jeweils mit Prüfziffer) als Eingaben zur Erzeugung des Schlüssels. Nehmen Sie an, der Inhaber eines „E-Passes“ stehe Ihnen gegenüber, und Sie wollen heimlich das Gesichtsbild aus dem Pass in dessen Jackentasche auslesen. Ihr Lesegerät hat die dafür benötigte Reichweite. Wie sollten Sie bei einem Angriff vorgehen? Nutzen Sie möglichst viel (vorhandenes oder recherchierbares) Wissen! Geben Sie eine begründete Schätzung ab, wie viele benötigte Versuche Sie erwarten (und wie lange das dauern würde)

• bei serieller Vergabe der (nur aus Ziffern bestehenden) Seriennummern, entsprechend den bis Oktober 2007 gültigen Regeln!
• bei Vergabe der Seriennummern, entsprechend den derzeit gültigen Regeln (informieren Sie sich, wie viele Zeichen zulässig sind)!

Sollten Sie benötigte Informationen nicht finden, so treffen Sie plausible Annahmen!

• Die Seriennummer besteht (abgesehen von der Prüfziffer) aus zwei Bestandteilen, der vierstelligen Behördenkennzahl und der fünfstelligen Passnummer.
  • Die Behördenkennzahlen sind öffentlich zugänglich; können Sie aufgrund z.B. des Dialekts Rückschlüsse auf eine wahrscheinliche Wohngegend ziehen, lässt sich die Anzahl möglicher Kennzahlen eingrenzen. Gehen wir davon aus, dass keine solche Eingrenzung möglich ist und die vier möglichen Stellen voll ausgenutzt werden, haben wir 10.000 Möglichkeiten (soweit ersichtlich, wurde die Anzahl möglicher Behördenkennzahlen nach Umstellung auf alphanumerische Seriennummern nicht erhöht, auch wenn diese nun anders codiert werden).
  • Die Passnummern wurden früher fortlaufend vergeben und bestanden nur aus Ziffern. Maximal muss ein Angreifer dabei 100.000 Möglichkeiten durchprobieren. Mit Kenntnis anderer Seriennummern mit gleicher Behördenkennzahl war aber eine deutlich weitergehende Einschränkung möglich. Kaum eine Behörde dürfte aber die möglichen Seriennummern vollständig ausgeschöpft haben.
  • Nach heutigem Verfahren sind 27 verschiedene Zeichen in Passnummern zulässig, so dass 27^5 Möglichkeiten bestehen. Die Nummern werden zudem zufällig vergeben, so dass Wissen über andere Ausweisnummern einem Angreifer keine praktischen Vorteile bietet.
• Wenn die Person Ihnen gegenüber steht, können Sie ihr Alter schätzen. Wie genau Sie schätzen können, ist schwer zu beurteilen. Wir gehen davon aus, dass Sie auf +/- 5 Jahre genau schätzen können, also lediglich einen 10-Jahres-Zeitraum (entsprechend ca. 3.650 Möglichkeiten) ausprobieren müssen. Gegebenenfalls kann man beim Durchprobieren mit den als am wahrscheinlichsten empfundenen Möglichkeiten beginnen.
• Für das Ablaufdatum gehen wir von einem grundsätzlich möglichen Zeitraum von 10 Jahren aus. Dabei nehmen wir an, dass der Pass noch nicht abgelaufen ist. An Personen unter 24 Jahren werden Pässe mit nur 6 Jahren Gültigkeit ausgegeben; diese Möglichkeit vernachlässigen wir ebenfalls (ob sie in Betracht kommt, müssten Sie in der Realität aus dem geschätzten Alter des Pass-Inhabers ableiten). Die Anzahl der möglichen Ablaufdaten liegt bei 10 * 365, also 3.650. (Ggf. könnte man das Ablaufdatum noch weiter einschränken, wenn man davon ausgeht, dass Pässe nur an Arbeitstagen von Meldebehörden ausgegeben werden).
• Prüfziffern spielen für die Schätzung keine Rolle, denn die zu Ihren restlichen Angaben passenden Prüfziffern können Sie anhand eines öffentlich bekannten Algorithmus selbst berechnen.

Insgesamt hat ein Angreifer beim alten Verfahren also ca. 10.000 * 100.000 * 3.650 * 3.650, d.h. ca. 13 Billiarden Möglichkeiten (entsprechend ca. 53 Bit) und wird (als Erwartungswert) nach der Hälfte – also 6,5 Billiarden Versuchen – erfolgreich sein. Geht man von einer Wartezeit von einer Sekunde pro Zugriffsversuch aus, führt dies zu einer Dauer des Angriffs von ca.~200 Millionen Jahren (in diesem Szenario ist kein Offline-Angriff möglich, denn es kann keine bestehende Kommunikation mitgehört werden. Die Sekunde Zugriffszeit kommt durch den Pass selbst zustande). 
Beim neuen Verfahren ist mit ca. 10.000 * 27^5 * 3.650 * 3.650 Möglichkeiten zu rechnen. 
Beachten Sie, dass beide Berechnungen nur auf groben Abschätzungen beruhen und noch Optimierungspotential besteht. Die Berechnung zeigt aber, dass der Angriff in dieser Form nicht praktikabel ist.

Aufgabe 9.2
Warum kann bei der Extended Access Control die Terminal Authentication auch mit einem lange abgelaufenen Zertifikat des Terminals erfolgreich verlaufen? Wie kann man diesem Problem entgegenwirken? 

Der Pass hat keine eigene Uhr und kann somit das aktuelle Datum nicht feststellen; nur, wenn die Terminal Authentication durchgeführt wird, „weiß“ der Pass danach, dass das aktuelle Datum nach dem Gültigkeitsbeginn des vom Terminal verwendeten Zertifikats liegt. Beispiel: Am 1.1.2017 wurde letztmals eine Terminal Authentication von einem legitimen Terminal durchgeführt, wobei ein Zertifikat mit Gültigkeitsbeginn am 31.12.2016 verwendet wurde. Führt nun ein Angreifer am 10. November 2017 eine Terminal Authentication mit einem am 30. April 2017 abgelaufenen Zertifikat durch, kann durch den Pass nicht festgestellt werden, dass das Zertifikat bereits nicht mehr gültig ist. 
Eine Möglichkeit wäre, eine einfache Uhr in Pässe einzubauen; das wäre allerdings teuer und wohl auch fehleranfällig. Praktikabel ist die Möglichkeit, die Terminal Authentication mit legitimen Terminals häufiger durchzuführen, damit der Pass das aktuelle Datum jeweils auf den Gültigkeitsbeginn des verwendeten Zertifikats aktualisieren kann – ggf. auch dann, wenn eigentlich keine Notwendigkeit besteht, auf den Pass zuzugreifen. Ein Beispiel ist die Ausreise in ein potentiell „unsicheres“ Land. Vor der Ausreise könnte der Passinhaber noch im Heimatland die Terminal Authentication durchführen lassen, wobei der Pass den Gültigkeitsbeginn des verwendeten Zertifikats lernt, der (aufgrund der kurzen Gültigkeitsdauern) nicht lange in der Vergangenheit liegt.

Aufgabe 9.3
Wie wird bei der Restricted Identification sichergestellt, dass verschiedene Diensteanbieter auch verschiedene Pseudonyme erhalten, und wieso können die Diensteanbieter dies nicht umgehen?

Der Ausweis berechnet das jeweilige Pseudonym durch Verwendung des Diffie-Hellman-Verfahrens mit dem privaten Diffie-Hellman-Schlüssel des Ausweises und dem öffentlichen Diffie-Hellman-Schlüssel des Diensteanbieters sowie anschließende Anwendung einer Hashfunktion. Dass Diensteanbieter mit verschiedenen öffentlichen Diffie-Hellman-Schlüsseln dabei das gleiche Pseudonym erhalten, ist sehr unwahrscheinlich (praktisch ausgeschlossen). Der öffentliche Schlüssel ist auch im Zertifikat des Diensteanbieters enthalten, das durch den Ausweis überprüft wird. Der Zertifikatsaussteller würde es bemerken, wenn mehrere Zertifikate den gleichen öffentlichen Diffie-Hellman-Schlüssel enthielten. Bemerkung: Für dieses Verfahren wird im Ausweis ein eigenes (für jeden Ausweis unterschiedliches) Diffie-Hellman-Schlüsselpaar benutzt und nicht das gleiche wie für die Chip Authentication.

Aufgabe 10.1
Ein Unternehmen möchte die ausgehenden E-Mails seiner Abteilungen signieren. Die Kunden sollen den Signaturen nicht ansehen können, welcher Sachbearbeiter sie erstellt hat; außerdem sollen sie nicht sehen können, ob zwei Signaturen durch denselben Sachbearbeiter erstellt wurden. Aus Sicherheitsgründen sollen aber nicht alle Mitarbeiter Zugriff auf den gleichen kryptographischen Schlüssel erhalten. Welche kryptographischen Bausteine eigenen sich für diese Anwendung?

Denkbar wären hier Ringsignatur und Gruppensignatur. Bei der Ringsignatur besteht keine vordefinierte Gruppe – um die Signaturprüfung zu ermöglichen, müsste daher jeder Sachbearbeiter dem Empfänger jeweils die Liste der öffentlichen Schlüssel aller Sachbearbeiter zur Verfügung stellen und könnte dann eine Signatur berechnen, die nachweist, dass er zu diesen Sachbearbeitern gehört. Damit wäre die Anzahl der Sachbearbeiter bzw. beim Mitsenden der Zertifikate der anderen Sachbearbeiter sogar eine Liste der Namen offengelegt. In der Regel werden Unternehmen diese Information nicht preisgeben wollen. 
Bei der Gruppensignatur wird lediglich ein öffentlicher Gruppenschlüssel für die Verifikation verwendet. Ein Gruppenmanager kann die Gruppenmitgliedschaft widerrufen, wenn ein Sachbearbeiter ausscheidet; er kann auch im Nachhinein offenlegen, von wem die Signatur stammt (z.B. bei Streitigkeiten über Aussagen eines Sachbearbeiters). Die Erfüllung der rechtlichen Anforderungen des Signaturgesetzes (bzw. seit deren Inkrafttreten der eIDAS-Verordnung) ist allerdings auf diesem Weg nicht möglich, was für Unternehmen ein Ausschlusskriterium sein kann. Es gibt auch noch keine Unterstützung für Gruppensignaturen in gängiger Mailsoftware – insbesondere bräuchten auch die Empfänger eine Möglichkeit zur Überprüfung der Signaturen. 
Bemerkung: Die eIDAS-Verordnung kennt neben Signaturen auch sogenannte Siegel – aus technischer Sicht sind dies Signaturen, die aber einer Behörde oder einem Unternehmen zugeordnet werden und nicht einer natürlichen Person. Ob Gruppensignaturen hierfür rechtlich geeignet sind, ist bislang nicht geklärt.

Aufgabe 11.1
Ein Unternehmen gibt Kundenkarten mit Fotos aus. Es konvertiert nun die für diesen Zweck gespeicherten hochauflösenden Bitmaps in stark komprimierte JPEGs mit kleinerer Auflösung. Liegt eine Verarbeitung im datenschutzrechtlichen Sinne vor?

§ 3 Abs. 4 BDSG lautet: „Verarbeiten ist das Speichern, Verändern, Übermitteln, Sperren und Löschen personenbezogener Daten.“ Verändern ist dabei das inhaltliche Umgestalten gespeicherter personenbezogener Daten. Dies ist beim Konvertieren von hochauflösenden Bitmaps in stark komprimierte JPEGs mit kleinerer Auflösung der Fall.

Aufgabe 11.2
Student S hat Schwierigkeiten, einen Kredit zu bekommen. Er befürchtet, eine Auskunftei könne falsche Daten über seine Zahlungsmoral gespeichert haben. S verlangt von der Auskunftei daher eine unentgeltliche Auskunft über die zu seiner Person gespeicherten Daten. Hat er ein Recht darauf?

§ 34 Abs. 1 BDSG lautet: „Die verantwortliche Stelle hat dem Betroffenen auf Verlangen Auskunft zu erteilen über 1. die zu seiner Person gespeicherten Daten, auch soweit sie sich auf die Herkunft dieser Daten beziehen, 2. den Empfänger oder die Kategorien von Empfängern, an die Daten weitergegeben werden, und 3. den Zweck der Speicherung.“ 
In § 34 Abs. 2 BDSG heißt es weiter: „Im Fall des § 28b hat die für die Entscheidung verantwortliche Stelle dem Betroffenen auf Verlangen Auskunft zu erteilen über 1. die innerhalb der letzten sechs Monate vor dem Zugang des Auskunftsverlangens erhobenen oder erstmalig gespeicherten Wahrscheinlichkeitswerte, 2. die zur Berechnung der Wahrscheinlichkeitswerte genutzten Datenarten und 3. das Zustandekommen und die Bedeutung der Wahrscheinlichkeitswerte einzelfallbezogen und nachvollziehbar in allgemein verständlicher Form.“ § 28b enthält dabei die Vorgaben zum Scoring. 
Außerdem heißt es in § 34 Abs. 8 BDSG: „Die Auskunft ist unentgeltlich. Werden die personenbezogenen Daten geschäftsmäßig zum Zweck der Übermittlung gespeichert, kann der Betroffene einmal je Kalenderjahr eine unentgeltliche Auskunft in Textform verlangen. Für jede weitere Auskunft kann ein Entgelt verlangt werden, wenn der Betroffene die Auskunft gegenüber Dritten zu wirtschaftlichen Zwecken nutzen kann. Das Entgelt darf über die durch die Auskunftserteilung entstandenen unmittelbar zurechenbaren Kosten nicht hinausgehen. Ein Entgelt kann nicht verlangt werden, wenn 1. besondere Umstände die Annahme rechtfertigen, dass Daten unrichtig oder unzulässig gespeichert werden, oder 2. die Auskunft ergibt, dass die Daten nach § 35 Abs. 1 zu berichtigen oder nach § 35 Abs. 2 Satz 2 Nr. 1 zu löschen sind.“ 
Zusammenfassend lässt sich festhalten, dass Student S also ein Recht darauf hat, von der Auskunftei eine unentgeltliche Auskunft über die zu seiner Person gespeicherten Daten zu erhalten. Einmal im Jahr gilt dies auf jeden Fall; unter bestimmten Umständen, die der Aufgabenstellung nach hier vorliegen könnten, kann S die Auskunft auch ein weiteres Mal kostenlos erhalten.

Aufgabe 11.3
Mit welchen Anliegen können Sie sich an einen Landesbeauftragten für Datenschutz (z.B. in Baden-Württemberg) wenden und welche Aufgaben hat er sonst?

Die Aufgaben eines Landesbeauftragten für Datenschutz ergeben sich u. A. aus § 38 BDSG. Die Aufsichtsbehörde kontrolliert die Einhaltung der datenschutzrechtlichen Vorschriften (aus dem BDSG, LDSG, TMG, etc.) durch öffentliche und nicht-öffentliche Stellen im Zuständigkeitsbereich (z.B. Baden-Württemberg). Zur Gewährleistung der Einhaltung der Vorschriften kann die Aufsichtsbehörde Maßnahmen zur Beseitigung festgestellter Verstöße anordnen. Bei schwerwiegenden Verstößen oder Mängeln kann die Aufsichtsbehörde Verfahren auch untersagen. Außerdem berät und unterstütz die Aufsichtsbehörde Datenschutzbeauftragte von Unternehmen und öffentlichen Einrichtungen. 
Bürger können beim Landesbeauftragten für Datenschutz Beschwerde gegen Unternehmen und öffentliche Einrichtungen (mit Sitz im Zuständigkeitsbereich der Aufsichtsbehörde) einreichen, wenn sie der Meinung sind, diese würden gegen datenschutzrechtliche Vorschriften verstoßen. Die Aufsichtsbehörde geht diesen Beschwerden nach.

Aufgabe 11.4
Wie lassen sich Webserver-Logfiles (bspw. bei Apache) derart gestalten, dass IP-Adressen nicht vollständig, sondern „verschleiert“ gespeichert werden? Überlegen Sie sich Ansätze, die eine De-Anonymisierung der IP-Adresse im Angriffsfall erlaubt bzw. recherchieren Sie, ob Apache bereits technische Lösungen dafür bietet. 

IP-Adressen könnten erst gar nicht protokolliert werden. Aus Datenschutzsicht wäre dies die schönste Lösung, allerdings würden damit auch Informationen zu Beziehungen zwischen verschiedenen Seitenaufrufen verloren gehen. Diese Informationen können aber für eine Fehlerdiagnose oder zur Angriffsverfolgung relevant sein. 
IP-Adressen könnten auch verkürzt gespeichert werden, wie dies etwa von Google Analytics angeboten wird. Durch das Weglassen des letzten 8-Bit-Blocks der IPv4-Adresse wird jeder Log-Eintrag auf eine Gruppe von bis zu 256 IP-Adressen verschiedener Nutzer verallgemeinert (im Falle von IPv6 werden fünf 16-Bit-Blöcke entfernt). Die Möglichkeiten zur Fehlerdiagnose sind nach wie vor gegeben. Aus Datenschutzsicht ist dieser Ansatz fragwürdig: Wurde zu einem Zeitpunkt nur eine IP-Adresse aus dem jeweiligen Bereich durch den Internetprovider dynamisch vergeben oder ist der gesamte betrachtete Bereich einer Person oder einem Unternehmen zugeordnet, so kann der Personenbezug u.U. noch hergestellt werden. 
Ein anderer Ansatz besteht im Mapping der IP-Adressen auf nicht-personenbezogene Daten und der anschließenden Speicherung. Technisch können etwa Einwegfunktionen, wie die kryptographische Hashfunktion SHA-256, eingesetzt werden. Zusammenhängende Seitenaufrufe bleiben damit erhalten, da dieselben IP-Adressen immer auf denselben Hashwert abgebildet werden. Durch die Eigenschaft, dass Kollisionen praktisch nicht zu finden sind, werden IP-Adressen auf einen Hashwert abgebildet der sie nahezu eindeutig repräsentiert, aber nicht zu ihr zurückgerechnet werden kann. IP-Adressen werden damit verschleiert, eine Aufdeckung ist damit aber nicht unmöglich: Bekannte IP-Adressen können durch die feste Berechnungsvorschrift im Logfile einfach gefunden werden, etwa zum Zwecke der Angriffsanalyse. Aufgrund der begrenzten Anzahl an IPv4-Adressen (2^32 Stück) ist aber auch eine systematische Aufdeckung der IP-Adressen aller Logeinträge via Brute Force praktisch möglich. Durch das Hinzufügen von Salt-Werten, also zufällig gewählten und in festen Intervallen vernichteten und erneuerten Werten, lässt sich dieses Problem verhindern. Der Salt-Wert dient als eine Art Schlüssel, nach dessen Vernichtung eine Aufdeckung nicht mehr möglich ist. Beziehungen zwischen Log-Einträgen bleiben indes erhalten, solange der Wert gleich bleibt. Durch die Wahl der Zeitfenster für die Salt-Erneuerung ist ein Tradeoff zwischen datenschutzrechtlicher Verschleierung und technisch notwendiger Protokollierung möglich. 
Die gängigsten Webserver, darunter auch Apache, bieten die Möglichkeit, IP-Adressen erst gar nicht zu protokollieren. Eine weitere gängige Praxis ist das periodische Ersetzen der protokollierten Daten mittels eines Scripts. Apache 2 bietet drei fertige Software-Erweiterungen. Das Modul mod_removeip verwirft die IP-Adressen direkt – damit ist keine Speicherung möglich. Das Modul mod_log_iphash ersetzt die IP-Adressen im Logfile durch Hashwerte. Zusätzlich besteht die Möglichkeit, beim Starten einen neuen Salt-Wert zu wählen. Damit hat der Betreiber keine Möglichkeit mehr, vom Hashwert auf die IP-Adresse zu schließen. Gleichzeitig können verschiedene Zugriffe desselben Nutzers aber wieder miteinander in Verbindung gebracht werden. Ein Nachteil besteht allerdings darin, dass auch im Falle eines Angriffs die IP-Adresse nicht mehr aus dem Logfile extrahiert werden kann. Die umfangreichsten Möglichkeiten bietet das Modul mod_anonstats, das eine Konfiguration der Zeit zum Ändern des verwendeten Salt-Werts ermöglicht. Dies schützt IP-Adressen in älteren Log-Files vor ihrer Aufdeckung. Es gibt allerdings auch hier nicht die Möglichkeit, den aktuellen Salt-Wert verfügbar zu machen, sollte er etwa zur Angriffsanalyse benötigt werden.

Aufgabe 11.5
Nennen Sie jeweils ein Beispiel, wie die Speicherung von Vorratsdaten a) im Bereich der Mobilkommunikation, b) beim Access Provider eines Internetzugangs und c) im Bereich der Kommunikation per E-Mail umgangen werden kann! (Als Umgehung soll hier bereits zählen, wenn der Zweck der Speicherung nicht erreicht wird).

Im Bereich der Mobilkommunikation: Die Zuordnungsmöglichkeit gespeicherter Daten zu einer Person kann umgangen werden, indem SIM-Karten verwendet werden, die dem Nutzer eben nicht zuzuordnen sind. Dies können ausländische Karten sein, aber auch ältere Prepaid-Karten, bei denen manche Anbieter die Identität des Käufers nicht verifizierten. 
Beim Access Provider eines Internetzugangs: Beim eigenen Internetzugang kann der Nutzer dafür sorgen, dass seine IP-Adresse von Kommunikationspartnern nicht gesehen werden kann. Beispielsweise kann er Tor einsetzen oder ein VPN eines ausländischen Anbieters verwenden, der selbst die Zuordnung von IP-Adressen zu Nutzern nicht speichert. Alternativ kann der Nutzer offene oder schlecht geschützte WLANs anderer Personen mitbenutzen (in vielen Fällen wird diese Mitbenutzung allerdings rechtswidrig sein). 
Im Bereich der Kommunikation per E-Mail: Der Nutzer kann einen eigenen Mailserver aufsetzen oder den Mailserver eines kleinen Anbieters nutzen, der nicht zur Vorratsdatenspeicherung verpflichtet ist. Alternativ können auch ausländische Anbieter genutzt werden.

Aufgabe 11.6
(Unter welchen Umständen) darf Ihr Telefonanbieter Ihre Daten im Telefonbuch veröffentlichen? Falls ja: Welche Daten?

Die Antwort ergibt sich direkt aus dem Gesetzestext. § 104 TKG lautet: 
„Teilnehmer können mit ihrem Namen, ihrer Anschrift und zusätzlichen Angaben wie Beruf, Branche und Art des Anschlusses in öffentliche gedruckte oder elektronische Verzeichnisse eingetragen werden, soweit sie dies beantragen. Dabei können die Teilnehmer bestimmen, welche Angaben in den Verzeichnissen veröffentlicht werden sollen. Auf Verlangen des Teilnehmers dürfen Mitbenutzer eingetragen werden, soweit diese damit einverstanden sind.“