View source for Selbstauskunft "in-the-middle"

Der zum Projekt gehörige Code findet sich [https://github.com/eriknellessen/Selbstauskunft-in-the-middle hier].

=Szenario=
==Aufbau==
[[File:Selbstauskunft_in_the_middle_Ablauf1.png|thumb|center|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 [https://www.autentapp.de AusweisApp2] bzw. Governikus GmbH & Co. KG.

==Ablauf==

===Initialisierung===

[[File:Selbstauskunft_in_the_middle_Ablauf2.png|thumb|center|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===

[[File:Selbstauskunft_in_the_middle_Ablauf3.png|thumb|center|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 [https://frankmorgner.github.io/vsmartcard/virtualsmartcard/README.html Virtual Smart Card] benutzt werden.

==Webseitenbetreiber vorbereiten==
Der Webseitenbetreiber installiert [https://frankmorgner.github.io/vsmartcard/virtualsmartcard/README.html Virtual Smart Card] sowie den [https://github.com/BeID-lab/eIDClientCore eIDClientCore] auf seinem Server.

[https://frankmorgner.github.io/vsmartcard/virtualsmartcard/README.html Virtual Smart Card] erstellt virtuelle Leser. Diese lauschen auf einem Port auf eingehende Verbindungen. Welcher Port das ist, kann in der Datei
<code>/etc/reader.conf.d/vpcd</code>
eingestellt werden. Dort kann auch der Name der virtuellen Leser, der Pfad zur [https://frankmorgner.github.io/vsmartcard/virtualsmartcard/README.html Virtual Smart Card]-Bibliothek und der Hostname eingestellt werden. Für das beschriebene Szenario konnte die Konfigurationsdatei unverändert verwendet werden.
Standardmäßig erstellt [https://frankmorgner.github.io/vsmartcard/virtualsmartcard/README.html 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
<code>pcscd</code>
neu. <code>pcscd</code> erstellt dann beim Start die virtuellen Leser. Mit dem Befehl <code>pcscd -f -a -d</code> kann man auch aktiv in der Konsole mitverfolgen, wie <code>pcscd</code> das tut. Über <code>pcsc_scan</code> 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.
# '''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 [https://frankmorgner.github.io/vsmartcard/virtualsmartcard/README.html Virtual Smart Card], so versucht <code>pcscd</code>, den Treiber für den virtuellen Treiber, d.h. den Treiber von [https://frankmorgner.github.io/vsmartcard/virtualsmartcard/README.html Virtual Smart Card] zu benutzen, um mit dem Leser zu kommunizieren. Im [https://frankmorgner.github.io/vsmartcard/virtualsmartcard/README.html 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.
# '''PseudoAPDUs:''' Auch über PseudoAPDUs kann der Leser angesteuert werden, siehe [https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03119/index_htm.html 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 [https://frankmorgner.github.io/vsmartcard/virtualsmartcard/README.html Virtual Smart Card]. Er schließt den Kartenleser an und verbindet ihn mit dem nPA. Über <code>pcsc_scan</code> kann man herauskriegen, welche Nummer der angeschlossene Leser hat.
Anschließend gibt er einen Befehl der Art
<code>vicc --hostname 192.168.0.11 --port 35963 --type=relay --reader 2 -v</code>
ein.

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

Nach der Eingabe des Befehls verbindet sich [https://frankmorgner.github.io/vsmartcard/virtualsmartcard/README.html Virtual Smart Card] mit dem virtuellen Leser des Webseitenbetreibers. Auf dem Server des Webseitenbetreibers kann nun mit <code>pcsc_scan</code> ü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 [https://github.com/BeID-lab/eIDClientCore 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 [https://github.com/BeID-lab/eIDClientCore eIDClientCore]-Ordner) den Befehl <code>bin/Test_nPAClientLib_AutentApp</code> 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 [https://httpd.apache.org/docs/2.4/developer/modguide.html 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. <code>/etc/apache2/httpd.conf.eIDClientCore</code>. Im [https://github.com/eriknellessen/Selbstauskunft-in-the-middle github Repository] wird bereits eine passende Konfigurationsdatei mitgeliefert. Anschließend trägt man den Pfad der Datei in die Datei <code>/etc/sysconfig/apache2</code> (bzw. <code>/etc/apache2/apache2.conf, je nach System</code>) ein: <code>APACHE_CONF_INCLUDE_FILES="/Pfad/zur/httpd.conf.eIDClientCore"</code>. Das Makefile im [https://github.com/eriknellessen/Selbstauskunft-in-the-middle github Repository] macht das automatisiert, insofern die Zeile vorher <code>APACHE_CONF_INCLUDE_FILES=""</code> gelautet hat.

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

<code>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"</code>

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

Den Apache-Server startet man mit <code>rcapache2 start</code>.

==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 <code>free</code> 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 [http://man7.org/linux/man-pages/man3/popen.3.html popen] die Binärdatei <code>Test_nPAClientLib_AutentApp</code> 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 [https://github.com/eriknellessen/Selbstauskunft-in-the-middle 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 <code>vicc</code>-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 [https://addons.mozilla.org/EN-us/firefox/addon/commandrun/ hier] und [https://stackoverflow.com/questions/10215643/how-to-execute-a-windows-command-from-firefox-addon 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.