KIF345:Arbeitskreise/AK Chipkarten/Checkliste

Aus KIF

Wahrscheinlich werden verschiedene Stellen an der Uni die Chipkarte nutzen wollen. Jede Stelle sollte aber für sich die persönlichen Daten verwalten und diese sollen nicht zusammengeführt werden können. Wo möglich, sollen die Daten nur anonym existieren, um die Zusammenführung der Daten zu erschweren. Immerhin ist es möglich, allein mit dem Vor-/Nachnamen eine recht zuverlässige Zusammenführung zweier Datensätze zu schaffen.


Anforderung[Bearbeiten]

Beschreibung, Diskussion und Mögliche Lösung[Bearbeiten]

Jede beteiligte Stelle soll nur auf die "eigenen" Daten zugreifen können.[Bearbeiten]

Die Daten auf der Chipkarte müssen für jede beteiligte Stelle getrennt gespeichert werden.

Ein möglicher Lösungsansatz wäre, die auf der Chipkarte gespeicherten Daten rein statisch zu halten (z.B. für jede beteiligte Stelle nur eine interne, zufällig vergebene Authentification-ID auf der Karte speichern, die auch neu vergeben werden kann) und diesen Datensatz mittels public/private-key Verfahren zu sichern. Dazu verschlüsselt die ausgebende Stelle ("Ax") den Datensatz mit dem public key der Lesestellen ("Lx/pub") und signiert ihn mit dem eigenen private key ("Ax/priv"). Die Lesestellen ("Lx") können so anhand des eigenen private keys ("Lx/priv") die ID des Benutzers entschlüsseln und mittels des public keys der Ausgabestelle ("Ax/pub") den Ursprung des Datensatzes verifizieren.

Der Inhalt der Chipkarte muss gegen Kopie gesichert werden.[Bearbeiten]

Dies bedeutet, dass niemand die Daten auf der Chipkarte auslesen darf (nicht einmal die verschlüsselten Daten), außer authentifizierte Lesegeräte. Und nur die ursprüngliche Ausgabestelle darf überhaupt neue Exemplare der Chipkarte ausgeben. Ein Challenge-Response-Verfahren, mittels dessen sich die Lesegeräte bei der Karte authentifizieren, scheint hier die einfachste Möglichkeit zu sein, selbst wenn dadurch der Chip auf der Karte komplexer wird. Es müsste dann jede ausgebende Stelle einen neuen Datensatz auch ohne Authentifikation anlegen können, um die Notwendigkeit einer zentralen Ausgabestelle zu umgehen.

In Verbindung mit der ersten Anforderung könnte die Karte eine Challenge generieren und diese mit L/pub verschlüsseln (L/pub wurde von der ausgebenden Stelle diesem Datensatz mitgegeben). Das Lesegerät kann nun mittels L/priv die Challenge entschlüsseln und sich so Zugriff auf die Karte verschaffen. Dies bedeutet natürlich, dass die Lesegeräte ständig online sein müssen, um L/priv nicht lokal speichern zu müssen (Diebstahl eines Lesegerätes würde sonst bedeuten, alle Karten neu ausgeben zu müssen).

Für den Benutzer würde das bedeuten, zu Beginn seiner Studilaufbahn eine noch leere Karte zu erhalten, auf der jede Stelle der Uni einen eigenen Datensatz ablegen kann. Mit der Zeit muss der Studi sich einmal an jeder Stelle registrieren und erhält an jeder Stelle die Informationen zur Sperrung des einen Datensatzes.

Prinzip der Datenvermeidung beachten[Bearbeiten]

Dies bedeutet, nur die absolut notwendigen Daten zu speichern.

Beispiel 1: Der Datensatz für die Mensa-Bezahl-Karte braucht nur die Authentifikations-ID auf der Karte und den zugehörigen Betrag auf dem Server. Ansonsten kann der Account völlig anonym sein.

Beispiel 2: Die Bibliothekskarte dagegen erfordert die eindeutige Auffindbarkeit und Benachrichtigungsmöglichkeit der betreffenden Person. Daher ist natürlich Name, Anschrift und weitere Kontaktdaten sowie natürlich die laufenden Daten (ausgeliehene Bücher usw.) auf dem Server notwendig.

Die Karte muss bei Diebstahl gesperrt werden können[Bearbeiten]

Der Benutzer muss nun bei jeder einzelnen Stelle die jeweilige ID sperren lassen.

Bei personalisierten Accounts (Zugangskarten, Bibliotheksausweis, ...) ist dies einfach; hier kann mittels des Namens eine Sperrung der aktuellen ID erfolgen und auf einer neuen Karte eine neue Authentifikations-ID für den gleichen Datensatz abgelegt werden.

Bei anonymisierten Accounts (Mensa-Bezahl-Karte, ...) muss der Studi die bei der Ausgabe des Accounts auf Papier mit ausgegebene Auth-ID angeben, um z.B. das evtl. auf diesem Account vorhandene Restgeld ausbezahlt zu bekommen. Danach kann er ein neues, anonymes Konto anlegen.

Das System muss transparent sein[Bearbeiten]

D.h. was wird wann von wem gelesen/erfasst? Welche wege gehen die Daten? Wie lange werden sie gespeichert. Wie sind die Verantwortlichkeiten (DS-Beauftragte/r) und wer hat zugriff?

Unabhaengige Kontrollinstanz ueberprueft das System und ist Ansprechpartner bei Fragen/Problemen/usw..

Fazit[Bearbeiten]

Im Prinzip ist eine Karte gefordert, bei der jede beteiligte Stelle praktisch beliebige Daten einspeichern und wieder auslesen kann; diese müssen jedoch gegen unerlaubten Zugriff geschützt werden. Nicht einmal die verschlüsselten Daten dürfen von nicht authentifizierten Lesegeräten ausgelesen werden können (Kopierschutz) und jedes authentifizierte Lesegerät darf nur den ihm zustehenden Datensatz über einen verschlüsselten Kanal erhalten (Datenschutz). In gewisser Weise wird die Karte so zur "Account-Sammel-Karte".