Datenbank mit CertificateDescription für Berechtigungszertifikate

From
Jump to navigation Jump to search

Einleitung

Der neue Personalausweis

Übersicht

Seit 1. November 2010 löst der neue Personalausweis als Multifunktionskarte im handlichen Scheckkartenformat den klassischen Sichtausweis ab. Die Funktion als Sichtausweis bleibt erhalten, doch gleichzeitig kann das neue hoheitliche Dokument durch den integrierten elektronischen Chip drei weitere Funktionen erfüllen.

  • Biometrische Identitätsfunktion
  • Elektronischer Identitätsnachweis
  • Qualifizierte elektronische Signatur

Im Weiteren wird es nur um die Funktion des elektronischen Identitätsnachweises gehen; diese wird kurz eID-Funktion genannt.

Die eID-Funktion

Bei Kommunikation über das Internet stellt sich immer die Frage nach der Authentizität der Kommunikationspartner bzw. deren Nachrichten. Die eID-Funktion des neuen Personalausweises realisiert die gegenseitige Authentifizierung zweier Kommunikationspartner. Der Dienstanbieter kann in der elektronischen Welt weder die Sicherheitsmerkmale des Personalausweises, noch die Übereinstimmung körperlicher Merkmale mit dem Gesichtsbild überprüfen. Ersteres wird durch geeignete kryptographische Echtheitsnachweise realisiert. Zweiteres geschieht durch Eingabe einer geheimen PIN. Mit dieser bestätigt der Besitzer des Personalausweises, dass er auch dessen rechtmäßiger Besitzer (Inhaber) ist.

Des Weiteren muss sich der Dienstanbieter gegenüber dem Personalausweisinhaber authentisieren. Diese Authentisierung findet mittels eines Berechtigungszertifikates statt. Ein Dienstanbieter muss bei der Vergabestelle für Berechtigungszertifikate des Bundesverwaltungsamts berechtigtes Interesse für das Auslesen personenbezogener Daten aus dem Personalausweis nachweisen. Innerhalb einer Erforderlichkeitsprüfung wird das berechtigte Interesse festgestellt, welches Voraussetzung für die Vergabe des Berechtigungszertifikates ist. Das berechtigte Interesse kann sich beispielsweise nur auf die Altersverfikikation beziehen, entsprechend würde dies im Berechtigungszertifikat vermerkt werden und der Dienstanbieter hätte ausschließlich Zugang zum auf dem Personalausweis gespeicherten Geburtsdatum. Ist die Erforderlichkeitsprüfung positiv verlaufen, erhält ein Dienstanbieter von der Bundesdruckerei - offizielle Berechtigungs-CA - das Berechtigungszertifikat.

Das Berechtigungszertifikat

Das Berechtigungszertifikat - Card Verfiable Certificate (Card VC) - kann vom Personalausweis direkt überprüft werden und ist mit einer ganzen Reihe von Daten versehen:

  • Art und Umfang der Ausleseberechtigungen
  • Zuständige Datenschutzaufsichtsbehörde
  • Angaben zum Verwendungszweck der Daten
  • Kontaktdaten des Dienstanbieters (inkl. URL)
  • Gültigkeitszeitraum des Berechtigungszertifikates
  • Name und URL des Berechtigungszertifikatausstellers

Eine AusweisApp muss diese Informationen einem Nutzer anzeigen, bevor dieser durch die Eingabe seiner PIN den Zugang zu den Daten auf seinem Personalausweis ermöglicht. Darüber hinaus sind weitere technische Informationen enthalten, die hier nicht weiter Gegenstand der Betrachtungen sein werden. Genauso wenig wird das Verfahren zur Prüfung des Berechtigungszertifikates betrachtet werden.

Es wurde bereits beschrieben, dass die Vergabe der Berechtigungszertifikate ein kontrollierter Prozess ist. Es stellt sich allerdings die Frage wie restriktiv die Erforderlichkeitsprüfungen tatsächlich durchgeführt werden. Da es keine offizielle Übersicht über die vergebenen Berechtigungszertifikate bzw. deren Ausleseberechtigungen gibt, soll es nachfolgend darum gehen das Berechtigungszertifikat eines Dienstanbieters automatisch auslesen und speichern zu können, also ohne Interaktion eines Nutzers mit einem Dienstanbieter. Im Idealfall - unter der Annahme alle existierenden Dienstanbieter wären bekannt - ergibt sich dadurch eine vollständige Datenbank aller aktuell im Umlauf befindlichen Berechtigungszertifikate mit deren Ausleseberechtigungen. Eine Analyse der gesammelten Ausleseberechtigungen kann anschließend Hinweise auf die Erforderlichkeitsprüfungen geben.

Die Online Identifikation

Nutzersicht

Die gesamte Online Identifikation findet in mehreren Schritten statt und wird nachfolgend oberflächlich und mehr aus Sicht des Nutzers dargestellt. Anschließend folgt eine detaillierte Auseinandersetzung mit jedem für die Betrachtungen benötigten Schritt. Eine komplette Darstellung findet sich in der Technischen Richtlinie BSI TR-03112 Teil 7 Protokolle.

  1. Ein Nutzer befindet sich zunächst auf einer Webseite, die eine Funktion unter Nutzung des neuen Personalausweises anbietet. Beispielsweise wird das Herunterladen einer Datei gegen eine Altersverifikation ermöglicht oder aber ein Bestellformular kann mit den Daten aus dem Personalausweis bereits gefüllt werden. Der Nutzer startet hier die Prozedur zur Nutzung seines Personalausweises durch eine entsprechende (Menü-)Auswahl.
  2. Der Browser erhält daraufhin vom Dienstanbeiter eine Antwort, in der für die nun folgende Nutzung des eService erforderliche Daten enthalten sind. Durch einen JavaScript Handler in der erhaltenen Antwort kontaktiert der Browser automatisch den eService.
  3. Hierauf erhält der Browser eine weitere HTML-Seite, die mit einem Object-Tag versehen ist, auf den die installierte AusweisApp bzw. das durch die AusweisApp im Browser installierte Plugin reagiert.
  4. Die AusweisApp startet selbstständig und nutzt die im Object-Tag enthaltenen Informationen um ihrerseits eine Verbindung zum eService herzustellen
  5. Nun beginnt das eigentliche Kommunikationsprotokoll, welches unter anderem die Übermittlung des Berechtigungszertifikates beinhaltet und an dessen Ende die gegenseitige Authentisierung von Nutzer und Dienstanbieter steht.

Technische Sicht

Es folgt eine detaillierte Betrachtung der vorgenannten Schritte inklusive einer Bewertung der Automatisierungsmöglichkeiten.

  1. Der erste Schritt setzt in der Regel eine HTTPS-Verbindung voraus, die Browser problemlos herstellen können. Die verwendete HTTP Methode ist von Dienstanbieter zu Dienstanbieter unterschiedlich. Es wird sowohl GET, als auch POST verwendet. Ebenso prüfen Dienstanbieter die HTTP-Header Informationen teilweise genau und legen Wert auf einen Browser als User-Agent und eine passende Referer Adresse. Zusätzlich gibt es mitunter ein CAPTCHA als weiteren Sicherungsmechanismus. Hiermit einhergehend ist eine zustandsgebundene HTTP-Verbindung über Cookies oder sitzungsgebundene URL-Parameter (Session-IDs). Dienste, die mit CAPTCHAs gesichert sind, lassen sich nicht zuverlässig automatisiert nutzen, denn genau dies soll ein CAPTCHA verhindern. Dagegen steht grundsätzlich einer Automatisierung von HTTP GET und POST Requests nichts im Wege. Allerdings lässt sich nur schwer eine generische Lösung dafür finden, da die verwendeten URL-Parameter bzw. die zu übermittelnden Daten bei einem POST Request nicht generisch sind.
  2. Die erhaltene Antwort ist ein HTML-Dokument, aus dem sich die für Kontakt zum eService benötigten Informationen extrahieren lassen. Die hier verwendete HTTP-Methode ist POST, ebenfalls über eine normale SSL/TLS-Verbindung.
  3. Der im vorigen Schritt kontaktierte eService liefert eine umfangreichere HTML-Seite zurück, da sie im Browser des Nutzers zur Anzeige kommt. Durch den enthaltenen Object-Tag lassen sich die im Weiteren benötigten Informationen zweifelsfrei identifizieren und extrahieren. Im normalen Nutzerszenario übernimmt das Browser-Plugin diese Aufgabe. Der Inhalt eines solchen Object-Tags ist nachfolgend skizziert.
    

    <object type="application/vnd.ecard-client">
    

    <param name="ServerAddress" value="http://sal.example.com">
    

    <param name="SessionIdentifier" value="1A23…B129">
    

    <param name="Binding" value="urn:liberty:paos:2006-08">
    

    <param name="PathSecurity-Protocol" value="urn:ietf:rfc:4279">
    

    <param name="PathSecurity-Parameters" value="<PSK>4BC1 … A0B5</PSK>">
    

    <param name="SHA256ofSAMLRequest" value="91A4 … 32B2CF">
    

    <param name="RefreshAddress" value="http://service.example.com">
    

    </object>
    

    4. 

  4. Die AusweisApp startet im Nutzerszenario nun die Verbindung zum eService. Gemäß BSI TR-03112 Teil 7 wird diese Verbindung nach RFC 4279 "PSK Ciphersuites for TLS" gesichert. Hierbei fließt der im Object-Tag enthaltene Parameter "PathSecurity-Parameters" als PSK in die Schlüsselableitung mit ein. Dieser spezielle Verbindungsaufbau kann mit der SSL/TLS-Bibliothek OpenSSL nicht ohne Anpassungen durchgeführt werden. Es existiert aber ein Patch für OpenSSL 1.0.0c, der es ermöglicht RFC 4279 konforme Verbindungen aufzubauen. Somit lässt sich auch dieser Schritt ohne die AusweisApp realiseren.
    5. 

  5. Das folgende Kommunikationsprotokoll ist umfangreich und basierte bei allen betrachteten Dienstanbietern (und der resultierenden Verbindung zum eService) auf der PAOS Spezifikation. Hierbei handelt es sich um ein umgekehrte Bindung der SOAP-Spezifikation an HTTP. Im Speziellen werden bei dieser Bindungsform die Rollen von Service und Client vertauscht. Da mit BSI TR-03112 Teil 7 eine detaillierte Dokumentation des verwendeten Protokolls vorliegt und auch die für die eingesetzten Services erforderlichen WSDL/XSD Informationen vorhanden sind, sollte dieser Schritt ebenfalls nachzubilden sein.


Realisierung


Überblick


Die folgenden Abschnitte beschreiben detailliert, wie die einzelnen Schritte bis zum Start des PAOS basierten Kommunikationsprotokolls nachgebildet wurden. Abschließend wird auf die existierenden Probleme eingegangen.



Python


Es wurde Python als Programmiersprache für die Umsetzung gewählt, da diese Sprache weit verbreitet und damit auf vielen Systemen bereits vorhanden ist. Außerdem bringt die Sprache eine Reihe von Bibliotheken mit, die einen einfachen Verbindungsaufbau über HTTP(S) und Parsen von HTML-Dokumenten ermöglichen. Ebenso lässt sich Python vergleichsweise einfach durch eigene C-Funktionen erweitern. Dies kann im Hinblick auf die anzupassende OpenSSL Version von Vorteil sein.

Um so wenig Interferenzen wie möglich durch bereits installierte Python Module zu erzeugen, wurde das virtualenv Modul verwendet. Es stellt durch Manipulation der PATH Umgebungsvariable eine "virtuelle Pythonumgebung" zur Verfügung. Unter der Annahme, dass die Python setuptools installiert sind, kann das virtualenv Modul mit dem folgenden Aufruf installiert werden:



easy_install virtualenv



Im Weiteren wird für die Herstellung der virtuellen Pythonumgebung das folgende Shellskript (prepare_env.sh) verwendet:



#!/bin/bash
python_version="2.6"
py_env="zzz_env"
project_dir=`pwd`
virtualenv --python=python$python_version --no-site-packages $py_env
source $py_env/bin/activate
cd $project_dir



Es wird beim Aufruf ein Ordner mit dem Namen "zzz_env" erstellt werden, dieser beherbergt die "virtuelle Pythonumgebung". Mit dieser Skript-Vorlage ist es einfach möglich weitere Module "manuell" oder in Form von Abhängigkeiten zu installieren. Zum jetzigen Zeitpunkt sind keine weiteren Module nötig. Das Skript sollte in der zu verwendenden Shell-Session so aufgerufen werden:



. ./prepare_env.sh



Die ersten beiden Schritte der Online Identifikation wurden nun in Python realisiert. Exemplarisch wurde dies für einen Dienstanbieter mit initialem HTTP GET und für einen mit initialem HTTP POST Request getan. Hierbei wurde darauf geachtet stets einen vollständigen HTTP Header zu senden, ganz so wie ein normaler Browser.
Es ist in Python nicht möglich RFC 4279 konforme TLS-Verbindungen zu öffnen. Oben wurde bereits angedeutet, dass dafür eine angepasste OpenSSL Version zum Einsatz kommen wird. Diese wird durch ein in C geschriebenes Programm benutzt werden, welches zunächst ohne Python Bindings auskommt. Das Python-Skript wird das C-Programm lediglich als externes Programm aufrufen und die im zweiten Schritt extrahierten Daten für den Verbindungsaufbau übergeben.



OpenSSL


Es wurde bereits beschrieben, dass für RFC 4279 konforme TLS-Verbindungen eine angepasste OpenSSL Version benötigt wird. Christian Dietrich hat diesen Patch für die OpenSSL Version 1.0.0c geschrieben und auf seiner Webseite bereitgestellt. Die passenden OpenSSL Version 1.0.0c kann hier runtergeladen werden. Unter der Annahme sowohl das Archiv mit dem Patch, als auch das OpenSSL Source Archiv sind im aktuellen Verzeichnis vorhanden, dann sind die folgenden Aufrufe nötig um die gepatchte OpenSSL Version zu kompilieren:



tar xvzf openssl-1.0.0c.tar.gz
tar xvf openssl-1.0.0c.tls-rsa-psk.tar
cd openssl-1.0.0c
patch -p1 -i ../openssl-1.0.0c.tls-rsa-psk.patch
mkdir openssl
./config --openssldir=`pwd`/openssl
make
make test
make install



Am Ende befindet sich im Verzeichnis "openssl" die gepatchte OpenSSL Version.



C-Programm


Die eigens kompilierte OpenSSL Version wird in einem C-Programm verwendet, welches die TLS-PSK Verbindung zum eService herstellt. Gemäß der Informationen in BSI TR-03112 Teil 7 wird nach dem Verbindungsaufbau ein Request gebraucht, dessen Response bereits alle Informationen des Berechtigungszertifikates hält. Entsprechend wurde das C-Programm zunächst so realisiert, dass es selbstständig diesen einen Request ausführt, auf die Antwort wartet, diese für weitere Verarbeitung ausgibt und die Verbindung zum eService anschließend trennt. Da sich dieser eine Request als sehr problematisch herausgestellt hat, wurde die Vorbereitung des Requests in das Python-Srkipt ausgelagert. Damit wurde erreicht, dass Tests mit unterschiedlichen Requests einfacher - ohne erneute Kompilierung des C-Programms - durchgeführt werden können.

Um das C-Programm korrekt gegen die selbst kompilierte OpenSSL Version linken zu können wurde ein Makefile geschrieben. Das C-Programm wurde seiner Bestimmung entsprechend ssl_connector genannt und die OpenSSL Version ist im Verzeichnis "/root/Projects/openssl" zu finden. 



 CFLAGS = -v -Wall -Wextra -g -I /root/Projects/openssl/include/ -L/root/Projects/openssl/lib -ldl
 PRG = ssl_connector

 all: $(PRG)

 ssl_connector: ssl_connector.c
 	  cc $(CFLAGS) -o $@ $@.c -lssl -lcrypto

 clean:
 	  rm -f $(PRG)



Probleme


Im vorstehenden Abschnitt wurde bereits angedeutet, dass es Probleme mit der Durchführung des in BSI TR-03112 Teil 7 beschriebenen Kommunikationsprotokolls gibt. Die Technische Richtlinie beschreibt in Abschnitt 2.3.2 "Overview of connection process", dass das PAOS-Binding entsprechend der PAOS-Spezifikation mittels eines HTTP GET oder eines HTTP POST Requests stattfinden kann. Für Ersteres muss dem HTTP Header ein PAOS spezifischer Teil hinzugefügt werden. Letzteres benötigt neben der HTTP Header Erweiterung noch einen SOAP-Aufruf von "StartPAOS". Da der HTTP GET Request wesentlich kürzer ist und ganz ohne SOAP-Inhalte auskommt, wurde sich im Rahmen der Untersuchung für diesen entschieden. BSI TR-03112 Teil 7 liefert ein Beispiel für einen solchen Request:



GET /eService?SessionIdentifier=12345 HTTP/1.1 
Host: example.com 
Accept: text/html; application/vnd.paos+xml 
PAOS: ver="urn:liberty:paos:2003-08"; "urn:iso:std:iso-iec:24727:tech:schema"





Die Erweiterung des HTTP Headers ist in der letzten Zeile erkennbar. Entsprechend der PAOS-Spezifikation wird zunächst die unterstützte PAOS Version genannt und anschließend der zu startende Service. Laut BSI TR-03112 Teil 7 muss der Service dem Namespace in der zugehörigen WSDL Definition entsprechen.
Schickt man diesen Request mit korrektem SessionIdentifier und korrektem Host an den eService, so quittiert dieser den Request mit einem HTTP 400 Error und dem folgenden Stacktrace:


 
HTTP/1.1 400 Bad Request
 Set-Cookie: JSESSIONID=211369B02BB4BF8A1CE334FACEB03360; Path=/; Secure
 Transfer-Encoding: chunked
 Date: Thu, 29 Sep 2011 16:29:54 GMT
 Connection: close
 Server: Server

 68a
 com.openlimit.ecard.paos.exceptions.InvalidHTTPHeaderException: Not a HTTP GET/POST request or valid HTTP response!
	  at com.openlimit.ecard.paos.schemata.HTTPHeader.parse(HTTPHeader.java:366)
	  at com.openlimit.ecard.paos.tools.HTTPTools.readHTTPHeader(HTTPTools.java:104)
	  at com.openlimit.eidserver.httphandler.HTTPHandler.jndiConnection(HTTPHandler.java:1037)
	  at com.openlimit.eidserver.httphandler.HTTPHandler.processRequest(HTTPHandler.java:472)
	  at com.openlimit.eidserver.httphandler.HTTPHandler.doGet(HTTPHandler.java:234)
	  at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
	  at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
	  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	  at org.apache.catalina.core.ApplicationFilterChain.doResponse:
 Filter(ApplicationFilterChain.java:206)
	  at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
	  at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	  at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	  at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	  at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	  at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
	  at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:864)
	  at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579)
	  at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1600)
	  at java.lang.Thread.run(Thread.java:662)


Aus dem Stacktrace kann man schließen, dass es sich um ein Problem mit der PAOS HTTP Header Erweiterung handelt. Gemäß der PAOS Spezifikation besitzt die HTTP Header Erweiterung diese Form:



PAOS = "PAOS" ": " PAOS_Version ["," Extension] *(";" Service ["," #Option] ["," #Action]) 
PAOS_Version = "ver" "=" 1#quotedURI
Extension = "ext" "=" 1#quotedURI
Service = quotedURI 
Option = quotedURI 
Action = "action" "=" 1#quotedURI 
quotedURI = <">anyURI<">



Es handelt sich um eine Darstellung in erweiterter BNF gemäß RFC 2616 Abschnitt 2.1. Die im Request verwendete HTTP Header Erweiterung



PAOS: ver="urn:liberty:paos:2003-08"; "urn:iso:std:iso-iec:24727:tech:schema"



entspricht der vorstehenden Spezifikation. Daher ist es sehr verwunderlich, warum ein Parser auf Seiten des eService den erweiterten HTTP Header moniert bzw. den Request als nicht valide verwirft.

Weitere Untersuchungen haben gezeigt, dass sich der Webserver grundsätzlich normal verhält. Allerdings konnten keine weiteren Informationen gewonnen werden, die zu einer Korrektur des Requests führten.

Selbst die Verwendung eines früheren Requests der AusweisApp mit SOAP-Aufruf brachte denselben Fehler hervor. Der Netzwerkverkehr der aktuellen AusweisApp kann nicht mehr entschlüsselt werden, dann zum jetzigen Zeitpunkt die Ciphersuites 



TLS_RSA_PSK_WITH_RC4_128_SHA
TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA
TLS_RSA_PSK_WITH_AES_128_CBC_SHA
TLS_RSA_PSK_WITH_AES_256_CBC_SHA



verwendet werden. Diese lassen sich im Gegensatz zu den zuvor verwendeten



TLS_PSK_WITH_RC4_128_SHA
TLS_PSK_WITH_3DES_EDE_CBC_SHA
TLS_PSK_WITH_AES_128_CBC_SHA
TLS_PSK_WITH_AES_256_CBC_SHA



nicht mehr nur unter Kenntnis des PSK entschlüsseln. Somit kann auch hieraus keine weitere Information gewonnen werden.



Fazit


Im Rahmen des Workshops war es nicht möglich eine Datenbank mit Informationen über die aktuell zur Anwendung kommenden Berechtigungszertifikate aufzubauen. Die Umsetzung scheiterte im Wesentlichen daran, dass das PAOS basierte Kommunikationsprotokoll zwischen AusweisApp und eService nicht gestartet werden konnte. Anscheinend scheitert dies an einem syntaktischen Problem bei der Anwendung des initialen HTTP Requests. In weiteren Untersuchungen sollte sich dieses Problem ausmerzen lassen. Danach würde sich zeigen in wie weit eine umfangreichere Realisierung der in BSI TR-03112 Teil 7 beschriebenen Service Funktionlitäten erforderlich ist.

Das beschriebene Problem mit den unterschiedlichen HTTP Requests des jeweiligen Dienstanbieters bzw. dessen weitere Sicherungsmaßnahmen (CAPTCHA) lässt mit dem gewählten Ansatz nur bedingt lösen. Zwar kann man sich eine generalisierte Variante vorstellen, die mittels Nutzerinteraktion alle benötigten Informationen für den initialen HTTP Request zum Dienstanbieter zusammenstellt, allerdings scheint dies eine eher umständliche Lösung zu sein. Spätestens wenn Cookie-Inhalte übertragen werden müssen. Eine weitere Möglichkeit ist hier ein Browser Plugin, welches die Funktionalität der AusweisApp bzw. des zugehörigen Plugins simuliert. Dies hätte den Vorteil, dass das Plugin seine Positionierung im Browser Zugang zu allen benötigten Informationen besitzt. In weiteren Untersuchungen müsste noch der konkrete Funktionsumfang des skizzierten Plugins herausgearbeitet werden.

Abschließend kann festgehalten werden, dass es grundsätzlich möglich ist die ursprünglich geplante Datenbank mit Berechtigungszertifikaten anzulegen.



Quellen


NOCH UNVOLLSTÄNDIG










Retrieved from "https://sarwiki.informatik.hu-berlin.de/index.php?title=Datenbank_mit_CertificateDescription_für_Berechtigungszertifikate&oldid=9625"