Restricted ID für OpenPACE: Difference between revisions

From
Jump to navigation Jump to search
 
(39 intermediate revisions by the same user not shown)
Line 1: Line 1:
Aufgabenstellung war es Restricted Identification (RI) für OpenPace zu implementieren.
Im Folgenden wird die Implementierung von Restricted Identification (RI) für OpenPace beschrieben.


==Einleitung==
==Einleitung==
[http://openpace.sourceforge.net/ OpenPace] ist eine kryptographische Bibliothek für [http://www.openssl.org/ OpenSSL] die Extended Access Control (EAC) Version 2.0 unterstützt. Dieses und weitere Protokolle wie RI sind in der Technischen Richtlinie [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr03110/index_htm.html TR-03110] des Bundesministerium für Sicherheit in der Informationstechnik [https://www.bsi.bund.de (BSI)] spezifiziert.
[http://openpace.sourceforge.net/ OpenPace] ist eine kryptographische Bibliothek für [http://www.openssl.org/ OpenSSL], die das Protokoll Extended Access Control (EAC) Version 2.0 unterstützt. Das Protokoll ist spezifiziert in der technischen Richtlinie [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr03110/index_htm.html TR-03110] des Bundesministerium für Sicherheit in der Informationstechnik [https://www.bsi.bund.de (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/ http://sourceforge.net/projects/openpace/] oder [https://svn.informatik.hu-berlin.de/SAR/OpenPACE/ https://svn.informatik.hu-berlin.de/SAR/OpenPACE/] heruntergeladen werden.
OpenPace kann unter [http://sourceforge.net/projects/openpace/ http://sourceforge.net/projects/openpace/] oder [https://svn.informatik.hu-berlin.de/SAR/OpenPACE/ 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===
==Benutzung von OpenPace==

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:
#Das Terminal sendet den statischen öffentlichen Sektor-Schlüssel <math>SK_{Sector}</math> und die Domain-Parameter ''D'' an den MRTD-Chip.
#Der MRTD-Chip verifiziert <math>PK_{Sector}</math>, berechnet mithilfe seines geheimen Schlüssels <math>SK_{ID}</math> die sektorspezifische Kennung <math>I^{Sector}_{ID}=H(KA(SK_{ID},PK_{Sector},D))</math> und übersendet die Kennung an das Terminal.
#Das Terminal speichert die Kennung <math>I^{Sector}_{ID}</math> und überprüft, ob sie in der vom ''Document Verifier''<!--<ref>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.</ref>-->[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 <math>SK_{Sector}</math> gegeben ist. Widerrufs-Listen sind in der TR-03110 auf Seite 19 und Seite 38 spezifiziert.

==OpenPace==
===Benutzung von OpenPace===
Mit
Mit
make all
make all
Line 16: Line 31:
kann man ein ausführliches Testszenario ausprobieren.
kann man ein ausführliches Testszenario ausprobieren.


==Erweiterungen für OpenPace==
===Erweiterungen für OpenPace===
Mit Hilfe von Frank Morgner und Dominik Oepen wurden von mir die folgenden Dateien bearbeitet:
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.h
Line 26: Line 41:
*OpenPACE/trunk/openssl/crypto/eac/ri_lib.h.
*OpenPACE/trunk/openssl/crypto/eac/ri_lib.h.


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

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


In ri.c wird in der Funktion <code>RI_STEP2_compute_identifier</code> Schritt zwei des Protokolles ausgeführt. Es wird das gemeinsame Geheimnis des Key-Agreement bestimmt und davon der Hash-Wert berechnet.
In eac_lib.c habe ich die Methode <code>EAC_CTX_init_ri</code> angelegt, die <code>RI_CTX_set_protocol</code> in ri_lib.c und <code>RI_init</code> in ri.c aufruft.


In ri.c setzt <code>RI_CTX_set_protocol</code> in <code>ri_ctx</code> entsprechend der Protokoll OID die Funktionen <code>generate_key</code> und <code>compute_key</code> und die Hash-Funktion.
In ri_lib.c setzt <code>RI_CTX_set_protocol</code> in <code>ri_ctx</code> entsprechend der Protokoll OID[3] die Funktionen <code>generate_key</code> und <code>compute_key</code> und die Hash-Funktion.


==Fußnoten==
...
<!-- <references /> -->
*[1] Machine-Readable-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.
*[3] 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. 60.

Latest revision as of 13:02, 14 October 2011

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 und die Domain-Parameter D an den MRTD-Chip.
  2. Der MRTD-Chip verifiziert , berechnet mithilfe seines geheimen Schlüssels die sektorspezifische Kennung und übersendet die Kennung an das Terminal.
  3. Das Terminal speichert die Kennung 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 gegeben ist. Widerrufs-Listen sind in der TR-03110 auf Seite 19 und Seite 38 spezifiziert.

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[3] die Funktionen generate_key und compute_key und die Hash-Funktion.

Fußnoten

  • [1] Machine-Readable-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.
  • [3] 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. 60.