Schon seit Jahren bietet der Personalausweis in Deutschland die Möglichkeit, sich digital
auszuweisen und zu authentifizieren (vergleiche Bundesinnenministerium (2021)). Leider
findet das Verfahren kaum Anwendung und ist in der Bevölkerung auch kaum bekannt.
Daher möchte ich in diesem Blogeintrag darstellen, wie eine elektronische Authentifizierung
mit dem Personalausweis nutzerfreundlich gestaltet werden könnte.

Wie funktioniert der elektronische Ausweis?

Der elektronische Ausweis (eID) ist aus technischer Sicht ein Near Field Communication (NFC) Chip, der in den Personalausweis eingearbeitet ist. Dieser NFC Chip speichert die Daten, die auch auf dem Personalausweis stehen. Über bestimmte Authentifizierungsverfahren können diese Daten gelesen und an eine Behörde oder einen anderen Dienst weitergegeben werden.

Notwendig für die Benutzung sind zum einen natürlich ein aktueller Personalausweis, eine Anwendung auf dem Desktop-PC oder Laptop sowie entweder die AusweisApp2 auf dem Smartphone oder Tablet oder ein Kartenlesegerät. Fordert ein Dienst nun eine Authentifizierung an, wie es zum Beispiel bei Onlineanträgen notwendig sein kann, muss der Ausweis an das Kartenlesegerät oder das Smartphone gehalten werden. Dadurch werden die Daten vom Ausweis gelesen. Mit einer selbstgewählten PIN gibt man dann diese Daten zur Verwendung durch den Antrag frei. Dieser Ablauf ist in Abbildung 2.1 dargestellt.

Abb. 2.1: Ablauf der Authentifizierung mit dem elektronischen Personalausweis.

Da die gesamte Kommunikation Ende-zu-Ende verschlüsselt passiert, können die Daten nicht abgefangen werden. Außerdem kann der Benutzer auswählen, welche Daten er an welchen Dienst weitergeben möchte. So ist es theoretisch möglich, Dokumente nach den Maßgaben einer qualifizierten elektronischen Unterschrift zu signieren.

Wo liegen die Probleme im bisherigen Verfahren?

Es ist auffällig, dass sich die Authentifizierung mit der eID deutlich von den üblichen Methoden, wie einem Login bei bekannten Onlinediensten, unterscheidet. Primär ist das Konzept auf die Datensicherheit ausgelegt, damit auch sichergestellt werden kann, dass der Eigentümer des Ausweises die Authentifizierung durchführt. Das Problem, das daraus resultiert, ist, dass das Konzept nicht mehr benutzerfreundlich ist.

Das größte Hindernis an diesem Verfahren sind die hohen Zugangsbeschränkungen. Die Anwendung, die die Daten tatsächlich übermittelt, muss auf einem Rechner installiert werden, der auf Microsoft Windows oder MacOS läuft. Damit werden Personen ausgeschlossen, die diese Systeme nicht benutzen möchten oder können. Noch viel schwerwiegender ist allerdings, dass man ein Kartenlesegerät benötigt oder sein Smartphone mit dem Rechner koppeln muss.

Ein Kartenlesegerät werden sich für diesen Zweck wohl die wenigsten Personen anschaffen, da es nicht nur Geld, sondern auch Zeit kostet, dieses zu bestellen und einzurichten. Das Koppeln des Smartphones mit dem PC ist für viele Menschen eine hohe technische Hürde. Auch hier ist davon auszugehen, dass die meisten Menschen sich nicht die Zeit nehmen möchten, die Software entsprechend einzurichten.

Wie könnte man diese Hürden abbauen?

Damit das Verfahren benutzerfreundlicher wird, kann man sich Methoden bedienen, die in anderen Webanwendungen schon weit verbreitet sind. Die meisten großen Dienste, die einen sogenannten Single-Sign-On (SSO) bieten, setzen dabei auf Open Authorization 2.0 (OAuth 2.0) (vergleiche Siriwardena (2020, S. 81)). OAuth 2.0 ist damit ein de-facto Standard für die Authentifizierung und Authorisierung von Personen.

Abb. 4.1: Der Authorization Code Flow von OAuth2. Nach Boyd (2012, Abb. 2-1, S. 14)

Kurz erklärt funktioniert die Methode folgendermaßen: Der Benutzer möchte sich authentifizieren und sich bei einer Anwendung einloggen. Zum Login wird er auf den Authentifizierungsserver weitergeleitet, sodass der Client die Anmeldedaten nicht lesen kann. Hat der Authorization Server den Login validiert, bekommt der Client einen Authorization Code, mit dem dann der Token geholt werden kann. Mit dem Token wiederum kann der Client die Ressource vom Resource Server beziehen, der den Token mithilfe des Authorization Servers validiert (vergleiche Boyd (2012, S. 14)). So funktionieren zum Beispiel die Logins mit Google oder Facebook bei Drittanbietern.

Dieses Vorgehen kann man adaptieren: Verwendet man die AusweisApp2, so könnte der Authentifizierungsserver einen QR-Code bereitstellen, der den Authentifizierungsvorgang repräsentiert. Mit der AusweisApp2 scannt man diesen QR-Code und bekommt dann die Möglichkeit, seinen Personalausweis zu scannen und die PIN einzugeben. Diese Daten werden an den Authentifizierungsserver übermittelt, der dann den Authorization Code ausstellt. Alternativ kann der Vorgang auch mit der PC-Anwendung und einem Kartenlesegerät abgeschlossen werden. Die Kommunikation zwischen Authorization Server und App beziehungsweise Kartenlesegerät bleibt selbstverständlich Ende-zu-Ende verschlüsselt.

Das heißt, der Benutzer benötigt nur entweder die AusweisApp2 oder ein Kartenlesegerät am PC, nicht mehr beides. Es entfallen dadurch die aufwendigen Einrichtungen, wie zum Beispiel das Koppeln des Smartphones mit dem PC. Darüber hinaus ermöglicht man dem Benutzer, sich auch mobil mit dem Personalausweis zu authentifizieren und gibt Personen, die weder Windows noch MacOS nutzen, die Möglichkeit, am Verfahren teilzunehmen. Es sei dazu gesagt, dass Android quelloffen ist und diese App daher nicht an Googles Version des Betriebssystems gebunden ist. Der Ablauf ist in Grafik 4.2 dargestellt.

Abb. 4.2: Das eID Verfahren gekoppelt mit OAuth2.

Der Ablauf wäre demnach folgendermaßen:

  1. Der Benutzer ruft den Onlineantrag auf.
  2. Der Benutzer möchte eine qualifizierte elektronische Signatur abgeben.
  3. Der Onlineantrag leitet den Benutzer auf den Authorization Server weiter.
  4. Der Authorization Server stellt eine verschlüsselte Verbindung zur AusweisApp2 oder dem Kartenlesegerät her.
  5. Der Benutzer scannt seinen Ausweis.
  6. Der Benutzer gibt seine PIN ein.
  7. Der Authorization Server stehllt den Authorization Code aus.
  8. Der Onlineantrag verwendet den Authorization Code, um den Token vom Authorization Server zu holen.
  9. Der Onlineantrag greift mit dem Token auf den Resource Server, also den Dienst für die Ausstellung der Singaturschlüssel, zu.
  10. Der Onlineantrag signiert sich mithilfe der Schlüssel.

Ob der Onlineantrag Signaturschlüssel abrufen darf, wird über die Client Scopes geregelt. Das heißt, dass bei OAuth 2.0 im Vorfeld geregelt wird, welche Daten ein Client theoretisch anfragen darf. Technisch ist es auch möglich, diese Scopes je Anfrage festzulegen, sodass der Benutzer bei jedem Vorgang wählen kann, welche Zugriffe der Client erhalten soll. Allerdings ist hier wieder zu beachten, dass es der Benutzer einfach haben möchte und tendentiell mehr Daten freigeben wird, weil eine Auswahl Zeit kostet.

Fazit

Das aktuelle Verfahren rund um die eID ist zu aufwendig, um sich einer breiten Benutzerbasis zu erfreuen. Jedoch ist es verhältnismäßig einfach möglich, auf eine sichere Methode wie OAuth 2.0 zu wechseln. Technisch müsste dafür nicht viel verändert werden, da die Kommunikation zwischen Kartenlesegerät oder Smartphone und Authorization Server weiterhin direkt erfolgt. Jedoch fallen diverse technische Hürden weg, die aktuell sicherlich die Akzeptanz verringern.

Leider ist aktuell nicht abzusehen, ob sich in diesem Bereich in der nahen Zukunft etwas ändern wird. Es bleibt zu hoffen, dass das Bundesinnenminsiterium nachjustiert, da die elektronische Ausweiskontrolle viel Potential birgt, das aktuell einfach verschenkt wird.

Literatur

[Boyd 2012]
Boyd, Ryan: Getting Started with OAuth 2.0. O’Reilly, 2012

[Bundesinnenministerium 2021]
Bundesinnenministerium: Der Online-Ausweis.
Website. 2021. – URL https://www.personalausweisportal.de/Webs/PA/DE/
buergerinnen-und-buerger/online-ausweisen/online-ausweisen-node.html

[Siriwardena 2020] Siriwardena, Prabath: Advanced API Security: OAuth 2.0 and
Beyond. 2. Apress, 2020

Abkürzungen

eID Elektronischer Personalausweis
NFC Near Field Communication
OAuth 2.0 Open Authorization 2.0
SSO Single-Sign-On