Selbstauskunft "in-the-middle"

Szenario

Aufbau

Aufbau des Szenarios.

Bei der Selbstauskunft in the middle möchte ein Webseitenbetreiber Daten aus dem neuen Personalausweis (nPA) eines Nutzers auslesen. Dafür bräuchte er eigentlich ein Berechtigungszertifikat, das von der Vergabestelle vergeben wird. Das Ziel dieses Projekts ist, dem Webseitenbetreiber das Auslesen der Daten zu ermöglichen, ohne dass dieser sich ein Berechtigungszertifikat besorgen muss. Gleichzeitig soll für den Nutzer sichtbar sein, welcher Dienstanbieter welche Daten aus seinem nPA ausliest.

Der Dienstanbieter besitzt ein Berechtigungszertifikat. Dieses berechtigt ihn dazu, bestimmte Daten aus dem nPA auszulesen. Der Dienstanbieter, der in diesem Projekt verwendet wurde, ist die AusweisApp2 bzw. Governikus GmbH & Co. KG.

Ablauf

Initialisierung

Der rote Kasten zeigt die Reichweite des SSL/TLS-Kanals.

Webseitenbetreiber und Nutzer sind über das Internet miteinander verbunden. Über eine geeignete Software kann der Webseitenbetreiber auf den Kartenleser des Nutzers zugreifen.

Der Webseitenbetreiber fragt die Selbstauskunft beim Dienstanbieter an. Zwischen den beiden wird ein SSL/TLS-Kanal aufgebaut.

Auslesen der Daten

Der rote Kasten zeigt die Reichweite des EAC-Kanals.

Der Dienstanbieter liest die Daten aus dem nPA aus. Dazu wird ein vertraulicher und authentischer Kanal zwischen Dienstanbieter und nPA aufgebaut (siehe EACv2). Der Nutzer sieht auf seinem Kartenleser, welcher Dienstanbieter welche Daten auslesen möchte. Außerdem gibt der Nutzer seine PIN in seinen Kartenleser ein. Das Eingeben der PIN ist notwendig zum Auslesen der Daten und für den Aufbau des EAC-Kanals.

Dadurch, dass der EAC-Kanal vom Dienstanbieter bis zum nPA reicht, kann der Webseitenbetreiber die Kommunikation nicht mitlesen. Er reicht die Datenpakete nur in die jeweilige Richtung weiter.

Anzeigen der Daten

Der Dienstanbieter schickt das Resultat des Auslesens über den vertraulichen und authentischen SSL/TLS-Kanal an den Webseitenbetreiber. Der Webseitenbetreiber hat nun also die Daten des Nutzers authentisch vom Dienstanbieter, also in hoher Qualität, erhalten. Das Vertrauen in die Authentizität der Daten basiert auf dem Vertrauen in den Dienstanbieter.

Kartenleser über das Netzwerk verfügbar machen

Zu diesem Zweck kann Virtual Smart Card benutzt werden.

Webseitenbetreiber vorbereiten

Der Webseitenbetreiber installiert Virtual Smart Card auf seinem Server.

Virtual Smart Card erstellt virtuelle Leser. Diese lauschen auf einem Port auf eingehende Verbindungen. Welcher Port das ist, kann in der Datei /etc/reader.conf.d/vpcd eingestellt werden. Dort kann auch der Name der virtuellen Leser, der Pfad zur Virtual Smart Card-Bibliothek und der Hostname eingestellt werden. Für das beschriebene Szenario konnte die Konfigurationsdatei unverändert verwendet werden. Standardmäßig erstellt Virtual Smart Card zwei virtuelle Leser. Möchte man die Anzahl verändern, muss man das Programm vor dem Kompilieren verändern. Die Anzahl der Leser kann nicht in der Konfigurationsdatei eingestellt werden.

Anschließend startet der Webseitenbetreiber pcscd neu. pcscd erstellt dann beim Start die virtuellen Leser. Mit dem Befehl pcscd -f -a -d kann man auch aktiv in der Konsole mitverfolgen, wie pcscd das tut. Über pcsc_scan kann man überprüfen, ob die Leser erstellt wurden.

Der Webseitenbetreiber ist nun mit den Vorbereitungen fertig und wartet darauf, dass sich Nutzer auf die virtuellen Leser verbinden.

Nutzer vorbereiten

Wahl des Kartenlesers

Nicht jeder Kartenleser sollte für das Szenario verwendet werden. Basisleser ohne Anzeige oder Tastatur sind ungeeignet, da sie dem Nutzer nicht anzeigen, welcher Dienstanbieter welche Daten ausliest. Das war aber ein Ziel des Szenarios. Prinzipiell können sie aber verwendet werden, das Szenario konnte erfolgreich mit einem Basisleser durchgeführt werden.

Wir möchten also einen Komfortleser mit Anzeige und Tastatur verwenden. Diesem muss vor dem Auslesen der Daten mitgeteilt werden, welcher Dienstanbieter welche Daten auslesen möchte und dass er einen PACE-Kanal aufbauen soll. Es gibt dafür zwei Mechanismen.

1. Leserspezifische Kommunikation über den Treiber: Der Hersteller des Lesers bietet in seinem Treiber eine Funktion, die mit dem Leser kommuniziert. Das ist z.B. beim ReinerSCT cyberJack RFID komfort der Fall. Kombiniert man diesen Mechanismus mit Virtual Smart Card, so versucht pcscd, den Treiber für den virtuellen Treiber, d.h. den Treiber von Virtual Smart Card zu benutzen, um mit dem Leser zu kommunizieren. Im Virtual Smart Card-Treiber wurde dieser Mechanismus aber nicht implementiert. Daher kann der ReinerSCT cyberJack RFID komfort-Leser nicht angesteuert werden, um die Dienstanbieterinformationen anzuzeigen, die PIN abzufragen und den PACE-Kanal aufzubauen. Daher konnte das Szenario nicht erfolgreich mit dem ReinerSCT cyberJack RFID komfort-Leser durchgeführt werden.
2. PseudoAPDUs: Auch über PseudoAPDUs kann der Leser angesteuert werden, siehe BSI TR 3119. Dabei werden bestimmte APDUs an den Leser gesendet, so, als wenn sie für die Karte bestimmt wären. Der Leser fängt die APDUs dann ab und sendet sie nicht an die Karte weiter. Dieser Mechanismus wird nicht vom ReinerSCT cyberJack RFID komfort-Leser unterstützt, aber vom ReinerSCT cyberJack wave. PseudoAPDUs werden vom eIDClientCore unterstützt. Das Szenario konnte daher mit dem ReinerSCT cyberJack wave-Leser erfolgreich durchgeführt werden.

Aufbau der Verbindung

Auch der Nutzer installiert Virtual Smart Card. Er schließt den Kartenleser an und verbindet ihn mit dem nPA. Über pcsc_scan kann man herauskriegen, welche Nummer der angeschlossene Leser hat. Anschließend gibt er einen Befehl der Art vicc --hostname 192.168.0.11 --port 35963 --type=relay --reader 2 -v ein.

Hierbei entspricht die IP hinter --hostname der IP des Webseitenbetreibers und der Port hinter --port dem Port des Webseitenbetreibers (diese Parameter hat dieser in der Datei /etc/reader.conf.d/vpcd eingestellt). Die Zahl hinter --reader ist die Zahl des Kartenlesers, die mit pcsc_scan herausgefunden werden kann. Für mehr Debug-Ausgaben können weitere -v an den Befehl angefügt werden.

Nach der Eingabe des Befehls verbindet sich Virtual Smart Card mit dem virtuellen Leser des Webseitenbetreibers. Auf dem Server des Webseitenbetreibers kann nun mit pcsc_scan überprüft werden, ob alles funktioniert hat. In einem virtuellen Leser des Webseitenbetreibers sollte der nPA des Nutzers angezeigt werden.