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.

Der große Vorteil von OAuth 2.0 gegenüber anderen Authentifizierungsmethoden ist,
dass die Benutzerdaten auf einem zentralen Server verbleiben und nur herausgegeben
werden, wenn der anfragende Dienst die nötigen Berechtigungen hat. Der Dienst, der Benutzerdaten abfragen möchte, wird Client genannt. Clients sehen auch, je nach Flow,
nicht die Anmeldedaten der Benutzer. Dieser Ablauf ist in Abbildung 4.1 dargestellt.

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