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. Neben diesem Protokoll werden in der technischen Richtlinie TR-03110 des Bundesministerium für Sicherheit in der Informationstechnik (BSI) die folgenden Protokolle spezifiziert: 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.

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.

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.