German ID card / nPA

Last week, Kryptotag and SPRING took place at HGI in Bochum. It turned out to be a very interesting event, although unfortunately, I could not stay very long. My talk dealt with how Transport Layer Security with RSA-secured Pre-Shared Keys is used in the eID Online Authentication of the new German ID card. I provided a short recap on the default RSA key exchange and the plain Pre-Shared Key variant before outlining the difference to the RSA-PSK variant. My slides are available here.

Since November 2010, the new German electronic ID card provides a facility to perform an online remote authentication of the ID card holder. This method is called eID online authentication and is defined in the Technical Guideline TR-03110 of the Federal Office for Information Security. As part of the eID online authentication, personal data can be transmitted from the electronic ID card to its counterpart, the eID server. All data transmitted between the eletronic ID card and the eID server is supposed to be subject to secure messaging.

As the eID online authentication is specifically tailored to be used in web applications, the secure messaging channel between the eID card and the eID server is mapped to the Security Assertion Markup Language (SAML) and uses several TLS channels (Transport Layer Security, RFC 5246). In order to prevent man-in-the-middle attacks, the TLS channels are intertwined with the Terminal Authentication. This binding is realized by two aspects, one of them being the fact that special cipher suites are used which combine X.509 certificate based peer authentication with pre-shared keys. These cipher suites are termed TLS-RSA-PSK and defined in RFC 4279.

I implemented one of the TLS-RSA-PSK cipher suites as a patch to openssl-1.0.0c. This patch is EXPERIMENTAL. Apply it like so:

tar xvzf openssl-1.0.0c.tar.gz

cd openssl-1.0.0c

patch -p1 -i ../openssl-1.0.0c.tls-rsa-psk.patch

IMPORTANT NOTE: This patch is provided "as is". See LICENSE.txt for details.

Testing TLS-RSA-PSK
You can test locally whether your openssl with TLS-RSA-PSK works as follows. Make sure that you actually call the currently generated openssl binary (in the apps directory):

# launching the server

openssl s_server \

    -psk c033f52671c61c8128f7f8a40be88038bcf2b07a6eb3095c36e3759f0cf40837 \

    -key privkey.pem \

    -cipher RSA-PSK-AES256-CBC-SHA \

    -debug -state



# launch the client

openssl s_client -connect localhost:4433 \

    -psk c033f52671c61c8128f7f8a40be88038bcf2b07a6eb3095c36e3759f0cf40837 \

    -cipher RSA-PSK-AES256-CBC-SHA \

    -debug -state

You should then be able to pass data back and forth between the server and the client. Additionally, I have provided transscripts of what it looks like if it works. There is a server log and a client log.

As posted before, we have done an analysis of the remaining risks of the new German ID card (neuer Personalausweis, nPA) conducted by the German Federal Ministry of the Interior (Bundesinnenministerium). In mid October 2010, we published the summary of our study, presenting the key findings of the remaining risks (in German) when using the eID functionality via the Internet.

As the summary is only available in German, I will try to sum up the key findings in English here. First of all, we have to state that we analyzed the eID functionality only (neither the sovereign identification with biometry etc. nor the signature function). Thus, you may compare the target of the eID function to what usually is achieved using username and password authentication today. However, the eID function has mutual authentication builtin. This is one of the biggest advantages compared to "classic" username/password authentication where the server side is - if at all - only authenticated by its SSL/TLS certificate (ever heard of phishing?). Furthermore, the nPA requires a secret PIN before it can be used which effectively turns it into a two-factor-authentication mechanism. Thus, the security level of the eID function can be regarded much higher than classic username/password authentication.

There is always two faces of the same coin, so what ARE the remaining risks? We found that the card reader category B (Basisleser) poses a certain threat: Malware on the user's computer may - under certain circumstances - misuse the eID function of an nPA. As the secret PIN must be entered via the computer's keyboard when using Cat-B card readers, a keylogger may easily catch the PIN. Note that this only works with Cat-B card readers, not with the higher class card readers Cat-S (Standardleser) or Cat-K (Komfortleser). For more details, see our summary. A list of certified card readers is available online.

On 24th of August, the German TV program ARD plusminus announced that in cooperation with Chaos Computer Club, security flaws were found in the Online Authentication functionality of the new German ID card to be issued in November 2010. This caught some media attention and people now wonder: what is the impact?

First of all, let me clarify some aspects on the usage of the new German ID card (nPA). The nPA combines 3 distinct functionalities in one card. First, the sovereign function of the ID card, i.e. the authentication of a person in question is what people know from the current ID card. The nPA contains biometrics features in form of fingerprints to support this and only the sovereign function. Second, the online authentication serves as a means to communicate personal data from the chip to a service provider. This makes it possible to open a bank account or register a vehicle online, without the need for additional offline authentication. The third functionality is optional and provides digital signatures according to the German Signaturgesetz.

The security flaw referenced above targets the online authentication function in combination with a specific card reader of class CAT-B according to BSI TR 03119, the standard document for categories of card readers for the nPA. Due to the fact that the user has to enter the secret PIN via the computer keyboard when using CAT-B card readers, malware such as keylogging trojans can intercept the PIN. We found this in experiments ourselves. Knowing the PIN, the trojan might then remote control the nPA (which must be on or near the card reader) and perform an online authentication in the background, possibly without the user's notice. However, the personal data that is transmitted as part of the online authentication is not subject to interception.

Possible means to prevent this kind of flaw is to use a card reader of higher categories, such as Cat-S or Cat-K (according to BSI TR 03119). Those card readers have a pinpad to enter the PIN and keyloggers on the host computer do not interfere with these pinpads. Furthermore, even Cat-B card readers might be provided with visual or aural indicators that tell the user whenever an online authentication starts.

For more information on the German ID card, see my blog category. For news and statements in German, see also https://www.internet-sicherheit.de.

On popular demand, I published my (German) Master Thesis titled 'eID Online Authentisierung mit dem neuen elektronischen Personalausweis nPA'. It deals with the electronic identification functionality which will be implemented in the new German ID card that will be issued from November 1st, 2010 onwards. As the thesis was conducted by the German Ministry of the Interior, parts of it are still classified and thus not included in the public version of the thesis. However, it should give fairly detailed insights into the overall technology, major algorithms used as well as security contexts. Below you will find a summary of the thesis (unfortunately only in German). Please note that the thesis was written in 2008, thus some technical guidelines, especially concerning EAC, have changed since then (some changes even due to my thesis' results).

Zusammenfassung/Summary
Zunächst soll diese Master Thesis die Notwendigkeit und die Vergleichbarkeit des Sicherheitsniveaus zwischen dem physikalischen und dem elektronischen Ausweisdokument aufzeigen. Darüber hinaus soll eine Implementierung der Authentisierungsfunktion bzw. Online-Authentisierung des nPA für die Anwendung über das Internet – die erste ihrer Art – ihre Machbarkeit demonstrieren. Im Rahmen der Arbeit werden also sowohl die notwendigen Komponenten aller teilnehmenden Parteien (eID Authentication Server, Bürgerclient etc.) vorgestellt, die für eine Realisierung benötigt werden als auch tatsächliche Implementierungen dieser Komponenten beschrieben und gefertigt. Der Ablauf der Online-Authentisierung soll zusätzlich aus der Perspektive des Anwenders dokumentiert werden. Hierbei sind wichtige Schritte detailliert zu beschreiben.

Notwendigkeit eines elektronischen Personalausweises
Grundsätzlich wird in diesem Kontext die Frage nach der Notwendigkeit eines neuen, elektronischen Personalausweises aufgeworfen. Es läge nahe, die Notwendigkeit mit mangelnder Fälschungssicherheit des bisherigen Personalausweises zu begründen. Betrachtet man dies jedoch im Detail, so ist keine mangelnde Fälschungssicherheit feststellbar. Im Gegenteil – die deutschen Ausweisdokumente, also sowohl der Reisepass als auch der Personalausweis gehören weltweit zu den am schwersten fälschbaren Dokumenten.
Betrachtet man jedoch die Möglichkeiten, die derzeit für eine Identifikation und eine Authentisierung anhand von Ausweisdokumenten über das Internet zur Verfügung stehen, so wird klar, dass hier keine sichere Lösung existiert. Der elektronische Personalausweis soll diese Lücke mit Hilfe der sog. Authentisierungsfunktion nun schließen und eine sichere Authentisierung über das Internet ermöglichen.

Die Online-Authentisierung des nPA
Die Authentisierungsfunktion ermöglicht eine sichere Übertragung von Daten, die auf dem Ausweis gespeichert sind an einen Dritten. Während die Identifikation mit Hilfe von biometrischen Merkmalen (und somit auch der Zugriff auf diese) lediglich für den hoheitlichen Anwendungsbereich vorgesehen ist, soll die Authentisierungsfunktion sowohl für eBusiness als auch eGovernment verfügbar sein. Spezielle Teilfunktionen der Authentisierungsfunktion sind die Altersverifikation sowie ein sektorspezifischer Identifikator. Die Altersverifikation kann als Jugendschutzfunktion eingesetzt werden und der sektorspezifische Identifikator bietet ein eindeutiges Benutzerkennzeichen.
Mit Hilfe der Authentisierungsfunktion können also auf sichere Art und Weise, Attribute an einen Dienstanbieter übermittelt werden. Die Bezeichnung Attribute umfasst dabei nicht notwendigerweise ausschließlich explizite personenbezogene Angaben wie Vor- und Nachname, sondern auch relative Aussagen, wie z.B. "die Person ist älter als 18 Jahre". Im Rahmen der Registierung in einem Webshop ist vorstellbar, dass anstelle der manuellen Eingabe der personenbezogenen Daten, z.B. der volle Name und die Adresse, diese mit der Authentisierungsfunktion aus dem nPA ausgelesen werden. Der Dienstanbieter hat dann die Gewissheit, dass die Daten authentisch und integer sind.

Implementierung der Online-Authentisierung
Die Authentisierungsfunktion baut auf dem erweiterten Zugriffsschutzmechanismus Extended Access Control (EAC) auf. Das vom Bundesamt für Sicherheit in der Informationstechnik (BSI) spezifizierte Verfahren EAC sichert die Authentizität und Integrität der Daten sowohl in gespeicherter Form als auch während der Übertragung. Es besteht aus den 3 Protokollen Password Authenticated Connection Establishment (PACE), Terminal Authentication und Chip Authentication. Kernbestandteile von Extended Access Control sind symmetrische und asymmetrische (Elliptische-Kurven-)Kryptographie, eine globale Public Key Infrastruktur sowie die Verwendung von abstreitbaren Challenge-Response-Verfahren.

PACE ist ein Verfahren zur Freischaltung des Chips durch ein Lesegerät. Mit Hilfe einer sechsstelligen PIN, die als Passwort fungiert, wird einem Lesegerät der Zugriff auf den Funkkanal zu einem Chip, z.B. dem nPA, gestattet. Aus kryptographischer Perspektive handelt es sich dabei um eine verschlüsselte Diffie-Hellman-Schlüsseleinigung. Im Rahmen der sog. Terminal Authentication prüft der Chip mit Hilfe eines Challenge-Response-Verfahrens die Zugriffsberechtigungen des Lesegeräts (Terminal). Die Chip Authentication ist ein Verfahren, das genutzt wird, um die Authentizität des Chips zu prüfen. Hierbei werden implizit die Daten, die ein Chip liefert authentisiert. Aus kryptographischer Sicht handelt es sich um eine Diffie-Hellman-Schlüsseleinigung mit statischem Chip-Schlüssel. Nach Abschluss der Chip Authentication ist ein verschlüsselter Ende-zu-Ende-Kanal etabliert.

Berechtigungszertifikat oder Terminal Certificate
Das Terminal Certificate ist ein wichtiger Bestandteil der Authentisierung zwischen nPA und EAS. Es enthält neben dem öffentlichen Schlüssel des EAS die Berechtigung des EAS. Die Berechtigung gibt an, welche Felder des nPA durch den EAS ausgelesen werden dürfen. Das Terminal Certificate muss durch einen gültigen Document Verifier signiert worden sein. Auf diese Weise kann ein nPA sicherstellen, dass nur die Inhalte der Datenfelder an den EAS gesendet werden müssen, für die der EAS auch tatsächlich authentifiziert ist. Im Rahmen der Terminal Authentication wird dem Benutzer ein Dialog angezeigt, der die Kenndaten des Terminal Certificate visualisiert. Dieser Dialog zeigt den Zertifikatsinhaber, die Gültigkeit des Zertifikats, die Zugriffsberechtigungen auf die auszulesenden Attribute, einen Verweis auf die zuständige Datenschutzaufsichtsbehörde sowie den Verwendungszweck.

Schwachstellen und Angriffe
Angriffe auf die Online-Authentisierung des nPA, bei denen Kernkomponenten durch bösartige Instanzen ausgetauscht werden scheitern in der Regel. Da eine beidseitige Authentikation in den Endpunkten stattfindet, kann eine bösartige Komponenten entlarvt werden und das Auslesen der Daten aus dem nPA scheitert. Auch ein Angriff auf die Transportverschlüsselung und -integrität wird üblicherweise erfolglos verlaufen, da hier stabile Kryptographie – wie z.B. AES und Elliptische-Kurven-Kryptographie (ECDSA und ECDH) – zum Einsatz kommt.
Verbleibende Ansatzpunkte für Angriffe sind

• die Verifikation des Terminal Certificate durch den nPA


• Man in the Middle Angriffe sowie


• das An-/Abwählen von Attributen im Dialog des Berechtigungszertifikats.

Die Verifikation des Terminal Certificate erfolgt im nPA. Der nPA hat eine logische Uhr, die anhand von erfolgreichen Verifikationen in der Vergangenheit synchronisiert wird. Je seltener ein nPA benutzt wird (konkreter: erfolgreich authentisiert), umso größer die Abweichung der logischen Uhr des nPA von der Realzeit. Sobald das Schlüsselmaterial eines vormals legitimen EAS sowie ein in Bezug auf die Realzeit abgelaufenes Terminal Certificate für einen Angreifer verfügbar wird, könnte ein nPA mit hoher Abweichung seiner logischen Uhr den Zugriff eventuell fälschlicherweise zulassen. Auch die Abfrage von Sperrlisten kann nicht verlässlich implementiert werden, da Socket-Operationen Teil des Betriebssystems des Clients und nicht des nPA sind. In der Konsequenz könnte der Gültigkeitszeitraum von Terminal Certificates sehr kurz ausfallen, z.B. lediglich 24 Stunden. Sobald Missbrauch festgestellt wird, kann auf diese Weise durch eine Verhinderung der Neuausstellung eines Zertifikats reagiert werden. Trotzdem gilt: Je häufiger ein nPA zur Authentisierung genutzt wird (und je geringer damit die Abweichung von Realzeit und logischer Uhr sind), umso geringer ist das Erfolgsrisiko für einen solchen Angriff. Beschreibungen zu den restlichen Ansatzpunkten sind ebenfalls Teil der Master Thesis.

See the full thesis for details.

The German government decided to renew the German ID card, not to be confused with the German passport that got renewed in 2007. Thus we (Germans) will all get an electronic ID card, called ePA or nPA, beginning in November 2010. Among other things, the ID card is smaller (so-called ID 1 format, like a driver's license), it has an electronic smart-card like chip that can be read wireless and, hey, after all it looks much more funky (see the pics below).





Basically, the ID card will show all the personal attributes that are printed on the current ID card, but they can be read with appropriate terminals, too. Before the data can be read, the terminal and the ID card perform mutual authentication using protocols such as PACE, Terminal Authentication and Chip Authentication. These protocols are part of Extended Access Control (EAC), a new standard by the German BSI to securely read machine-readable travel documents. Whenever personal attributes shall be read, an end-to-end encrypted channel is established between the ID card and the eID server. Thus, the data cannot be intercepted. In theory. They say.

OK, joking aside, to be serious, as far as I can tell, Extended Access Control with its protocols PACE, Terminal and Chip Authentication are, from an IT security perspective, really strong means to build-up a secure channel. We have put together some more information on our institute website (in German only).