Restricted ID für OpenPACE

Im Folgenden wird die Implementierung von Restricted Identification (RI) für OpenPace beschrieben.

Einleitung

OpenPace ist eine kryptographische Bibliothek für OpenSSL, die das Protokoll Extended Access Control (EAC) Version 2.0 unterstützt. Das Protokoll ist spezifiziert in der technischen Richtlinie TR-03110 des Bundesministerium für Sicherheit in der Informationstechnik (BSI). Es enthält die Protokolle Password Authentificated Connection Establishment (PACE), Chip Authentification (CA), Terminal Authentification (TA) und Restricted Identification (RI).

OpenPace kann unter http://sourceforge.net/projects/openpace/ oder https://svn.informatik.hu-berlin.de/SAR/OpenPACE/ heruntergeladen werden.

Restricted Identification

Restricted Identification ist ein Protokoll zur pseudonymen Identifizierung eines MRTD-Chip[1] gegenüber einem Terminal. Vorausgesetzt wird, dass der MRTD-Chip korrekt funktioniert und vor Beginn des Protokolls Chip und Terminal mithilfe von Chip Authentication (CA) und Terminal Authentication (TA) entsprechend TR-03110 authentisiert wurden. Die während des Protokoll erzeugte sektorspezifische Kennung ist für alle Terminals innerhalb eines festgelegten Sektors jederzeit gleich und kann für eine erneute Identifizierung des MRTD-Chip von dem Terminal gespeichert werden. Die Kennung eines Chips soll sich zwischen verschiedenen Sektoren unterscheiden. Die Verknüpfung von Kennungen verschiedener Sektoren soll mit vertretbaren Aufwand nicht möglich sein.

Restricted-Identification-Protokoll

Das in der technischen Richtlinie beschriebene Restricted-Identification-Protokoll ist ein Diffie-Hellman-Schlüsselaustausch (Key-Agreement), der eine sektorspezifische Kennung erzeugt.

Bezeichnen SK bzw. PK die jeweiligen geheimen bzw. öffentlichen asymetrischen Schlüssel. Sei KA das Key-Agreement und H eine Hash-Funktion. Entsprechend der Protokoll Spezifikation werden die folgenden Schritte ausgeführt:

1. Das Terminal sendet den statischen öffentlichen Sektor-Schlüssel $SK_{Sector}$ und die Domain-Parameter D an den MRTD-Chip.
2. Der MRTD-Chip verifiziert $PK_{Sector}$, berechnet mithilfe seines geheimen Schlüssels $SK_{ID}$ die sektorspezifische Kennung $I_{ID}^{Sector}=H(KA(SK_{ID},PK_{Sector},D))$ und übersendet die Kennung an das Terminal.
3. Das Terminal speichert die Kennung $I_{ID}^{Sector}$ und überprüft, ob sie in der vom Document Verifier[2] herausgegebenen Liste der widerrufenen Kennungen enthalten ist.

Widerrufs-Listen

Die Erstellung der Widerrufs-Listen und der benötigten Schlüssel wurde im Rahmen des IT Security Workshop 2011 nicht implementiert. Es wird vorausgesetzt, dass $SK_{Sector}$ gegeben ist. Spezifikation der Widerrufs-Listen findet man in der TR-03110 auf Seite 19 und 38.

OpenPace

Benutzung von OpenPace

Mit

make all

wird OpenSSL 1.0.0d lokal installiert und die Patches für OpenPace eingespielt.

OpenPace kann nun zum Beispiel mit dem pace-tool benutzt werden, oder als Programmbibliothek eingebunden werden (siehe Dokumentation). Mit

make test

kann man ein ausführliches Testszenario ausprobieren.

Erweiterungen für OpenPace

Mit Hilfe von Frank Morgner und Dominik Oepen wurden von mir die folgenden Dateien bearbeitet:

• OpenPACE/trunk/openssl/crypto/eac/eac.h
• OpenPACE/trunk/openssl/crypto/eac/eac_lib.c
• OpenPACE/trunk/openssl/crypto/eac/eactest.c
• OpenPACE/trunk/openssl/crypto/eac/ri.c
• OpenPACE/trunk/openssl/crypto/eac/ri.h
• OpenPACE/trunk/openssl/crypto/eac/ri_lib.c.
• OpenPACE/trunk/openssl/crypto/eac/ri_lib.h.

Zuerst habe ich in eac.h ein RI Context Objekt ri_ctx definiert, welches von dem allgemeineren eac_ctx Objekt abgeleitet ist. Es enthält unter anderem Daten für den zu verwendenen Algorithmus, den öffentlichen und den geheimen Schlüssel. Außerdem enthält dieses Objekt für das Key-Agreement einen Pointer auf die Funktion generate_key, die den öffentlichen Schlüssel erzeugt und einen Pointer auf die Funktion compute_key, die das gemeinsame Geheimnis berechnet.

In eac_lib.c habe ich die Methode EAC_CTX_init_ri angelegt, die RI_CTX_set_protocol in ri_lib.c aufruft und den öffentlichen Schlüssel für das Key-Agreement erzeugt.

In ri.c wird in der Funktion RI_STEP2_compute_identifier Schritt zwei des Protokolles ausgeführt. Es wird das gemeinsame Geheimnis des Key-Agreement bestimmt und davon der Hash-Wert berechnet.

In ri_lib.c setzt RI_CTX_set_protocol in ri_ctx entsprechend der Protokoll OID die Funktionen generate_key und compute_key und die Hash-Funktion.

Fußnoten

• [1] Machine-Travel-Document-Chip z.B. im Neuen Personalausweis (nPA) enthalten
• [2] Bundesamt für Sicherheit in der Informationstechnik: Advanced Security Mechanisms for Machine Readable Travel Documents - Technical Guideline TR-03110. Version 2.05. Bonn 2010. S. 14.