Selbstauskunft "in-the-middle"

Der zum Projekt gehörige Code findet sich hier.

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 sowie den eIDClientCore 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.

Auslesen der Daten

Der Webseitenbetreiber kann nun den eIDClientCore genau so benutzen, als ob der nPA des Nutzers von einem lokalen Leser (also einem, der direkt mit dem Server des Webseitenbetreibers angeschlossen wäre) ausgelesen werden würde.

Dazu gibt er (im eIDClientCore-Ordner) den Befehl bin/Test_nPAClientLib_AutentApp ein. Daraufhin erscheint auf dem Leser des Nutzers die Information, welcher Dienstanbieter welche Daten auslesen möchte. Der Nutzer kann den Vorgang akzeptieren oder abbrechen. Anschließend erscheint die Aufforderung, die PIN über die Tastatur des Lesers einzugeben. Gibt der Nutzer hier die richtige PIN ein, werden die Daten ausgelesen und auf dem Bildschirm des Webseitenbetreibers angezeigt.

Apache Modul bauen

Ein weiteres Ziel des Projekts ist es, ein Apache Modul zu bauen, sodass vom Apache aus der eIDClientCore gestartet wird. Das lässt sich dann so integrieren, dass der Nutzer auf der Webseite z.B. auf einen Button klickt und anschließend auf dem Server des Webseitenbetreibers der eIDClientCore anläuft.

Eine Anleitung zum Erstellen von Apache Modulen findet sich hier. Auf OpenSUSE musste zum Übersetzen des Moduls das Paket apache2-devel installiert werden.

Laden und Auslösen des Moduls

Im Apache muss eingestellt werden, dass das Modul beim Start geladen wird und welche Aktionen des Nutzers den Start des Moduls auslösen.

Dazu erstellt man eine Konfigurationsdatei, z.B. /etc/apache2/httpd.conf.eIDClientCore. Im github Repository wird bereits eine passende Konfigurationsdatei mitgeliefert. Anschließend trägt man den Pfad der Datei in die Datei /etc/sysconfig/apache2 (bzw. /etc/apache2/apache2.conf, je nach System) ein: APACHE_CONF_INCLUDE_FILES="/Pfad/zur/httpd.conf.eIDClientCore". Das Makefile im github Repository macht das automatisiert, insofern die Zeile vorher APACHE_CONF_INCLUDE_FILES="" gelautet hat.

In die Datei /etc/apache2/httpd.conf.eIDClientCore trägt man folgendes ein:

LoadModule eIDClientCore_module /usr/lib64/apache2/mod_eIDClientCore.so

<Location "/eIDClientCore">

SetHandler eidclientcore-handler

</Location>

eIDClientCoreEIDCCBinaryPath "/Pfad/zur/Test_nPAClientLib_AutentApp"

eIDClientCoreParserCommand "Mein_Interpreter /Pfad/zum/Parser_Skript"

Die Pfade und Namen sind entsprechend anzupassen. Das Makefile versucht, die Pfade bereits korrekt einzutragen. Ruft der Nutzer die Seite /eIDClientCore auf, wird das Modul gestartet.

Den Apache-Server startet man mit rcapache2 start.

Einbinden des eIDClientCore

Als Bibliothek

Der eIDClientCore wurde so erweitert, dass seine Testfälle auch als Bibliothek (shared library) genutzt werden können.

Das Einbinden als Bibliothek konnte bisher nicht erfolgreich im Apache Modul getestet werden. Es kommt zu einem Aufruf von free mit einer fehlerhaften Speicheradresse.

Das Einbinden als Bibliothek konnte aber in einem kleinen C-Programm erfolgreich getestet werden. Daher wird davon ausgegangen, dass der Apache-Kontext für das Auftreten des Fehlers verantwortlich ist.

Ausführen der Binärdatei

Im Modul wird per popen die Binärdatei Test_nPAClientLib_AutentApp aufgerufen. Die Ausgabe des Programms wird einem Parser (über eine UNIX-Pipe) übergeben. Die Pfade/Befehle, um den die eIDClientCore-Binärdatei sowie den Parser auszuführen, kann man in der Konfigurationsdatei einstellen. Der im Code mitgelieferte Parser ist in Python geschrieben.

Anschließend werden die Daten, die der Parser ausgibt, im Modul in eine Datenstruktur geordnet. So liegen die Daten in einer Form vor, in der sie leicht weiterverarbeitet werden können. Im Code findet sich beispielhaft ein Mechanismus, der nur Personen mit dem Vornamen Erik den Zugriff auf ein Geheimnis gewährt.

Automatisiertes Einlegen des nPA in den virtuellen Leser

Eine noch zu klärende Frage ist, wie auf dem Client PC der vicc-Befehl mit den richtigen Parametern automatisiert gestartet werden kann. Das Ausführen von Kommandos durch eine Webseite ist aus Sicherheitsgründen erst einmal nicht möglich. Man könnte aber z.B. ein Firefox Addon erstellen. Dieses wäre dazu in der Lage, siehe hier und hier.

Ungeklärt ist auch, wie der Server erkennen kann, dass die HTTP(S)-Anfrage und das Einlegen des nPA in den virtuellen Leser zusammen gehören. Die beiden Kanäle könnten z.B. über RSA-PSK aneinander gebunden werden.