Mit Karte, bitte!

Elektronische Dokumente ID über Chip (Teil 2)
Kommentare

Windows Developer

Der Artikel „ID über Chip“ von Helmut Stoiber ist erstmalig erschienen im Windows Developer 9.2012
Basic Access Control
Während „Passive Authentication“ für jeden zu den ICAO-Spezifikationen

Windows Developer

Der Artikel „ID über Chip“ von Helmut Stoiber ist erstmalig erschienen im Windows Developer 9.2012

Basic Access Control

Während „Passive Authentication“ für jeden zu den ICAO-Spezifikationen kompatiblen, elektronischen Reisepass obligatorisch ist, können die herausgebenden Staaten eigenverantwortlich entscheiden, ob sie zusätzlich „Basic Access Control“, kurz BAC, implementieren. Jeder international anerkannte Pass, also auch klassische Pässe ohne Chip, weist auf der Datenseite eine maschinenlesbare Zeichenkette auf. Diese so genannte Machine Readable Zone (MRZ) lässt sich mit OCR-Verfahren auslesen und kann somit vom Lesegerät interpretiert und ausgewertet werden. Bei Reisepässen besteht die MRZ aus zwei Zeilen, die primär eine Dokumenten- und Länderkennung, die Passbuchnummer sowie einige Daten des Passinhabers enthalten. Weiterhin enthält die MRZ Füll- und Kontrollzeichen.

Die Daten eines BAC-Passes lassen sich erst dann ausgelesen, wenn das Lesegerät über die MRZ verfügt. Somit ist gewährleistet, dass nur dann auf die Daten des Passes zugegriffen werden kann, wenn das Passbuch geöffnet ist, sodass die auf der Datenseite befindliche MRZ verfügbar ist. Ein unbemerktes Abgreifen (Skimming) der Passdaten ist infolgedessen ausgeschlossen, und zwar auch dann, wenn ein Angreifer so nahe an den Pass gelangen könnte, dass die Funkverbindung über das Kontaktlosinterface des Chips aufgebaut werden könnte.

Extended Access Control

Weiterhin sind die biometrischen Daten gegen das unberechtigte Auslesen besonders zu schützen, um einen adäquaten Datenschutz zu gewährleisten. Die Technologie zum Schutz der biometrischen Daten ist nicht Bestandteil der ICAO-Spezifikationen. Vielmehr kommt hier die vom Bundesamt für Sicherheit in der Informationstechnik (BSI) herausgegebene Spezifikation [3] zum Tragen. Gemäß Abbildung 2 ist das Kernstück eine dreistufige EAC-PKI, bestehend aus einer Country Verifying Certificate Authority (CVCA), mindestens einer Document Verifying Certificate Authority (DVCA) und mindestens einem Inspection System (IS) je DVCA. Bei den hier eingesetzten Zertifikaten handelt es sich nicht um X.509-Zertifikate, sondern um so genannte Card Verifiable Certificates. Dieser Zertifikatstyp zeichnet sich durch eine sehr kleine Datengröße aus, wobei die Zertifikatsattribute speziell auf den jeweiligen Anwendungsfall abgestimmt sind. Mit das wichtigste Attribut neben der Zertifikatsgültigkeitsdauer ist das Attribut „Roles and Access Rights“. Aus diesem Attribut lässt sich ableiten, ob es sich um CV-, DV- oder IS-Zertifikate handelt. Weiterhin sind hier die Zugriffsrechte auf die biometrischen Daten, also Fingerabdrücke oder Iris-Scans, verankert.

Abb. 2: Zertifikatsbasiertes EAC-Verfahren
Abb. 2: Zertifikatsbasiertes EAC-Verfahren

Das von der CVCA ausgegebene hierarchisch höchste Country Verifying-Zertifikat wird während der Passproduktion in einen geschützten Bereich des Chips geschrieben und stellt den obersten Trust Point der EAC-PKI dar. Genauer betrachtet handelt es um eine Speicherzelle, die nach der Produktion von außen nur noch gelesen werden kann. Zusätzlich wird ein asymmetrisches Schüsselpaar generiert und wie folgt im Chip gespeichert: Der private Schlüssel wird in einen von außen unzugänglichen Speicherbereich (Secure Memory) gespeichert, d. h. er ist weder lesbar noch modifizierbar und steht somit nur chipintern zur Verfügung. Der öffentliche Schlüssel wird hingegen in einer von außen zugreifbaren Struktur gespeichert, die bei der Chipauthentisierung benötigt wird. Wie aus Abbildung 2 hervorgeht, gliedert sich die Passverifikation in die beiden Phasen „Chip Authentication“ und „Terminal Authentication“, wobei hierfür die gesamte Zertifikatskette (CV, DV, IS) und eine vom IS-Service bereitzustellende Signatur erforderlich sind. Erst wenn diese beiden Authentifizierungsphasen erfolgreich durchgeführt werden konnten und das Attribut „Roles and Access Rights“ entsprechend gesetzt ist, können biometrische Daten gelesen werden. Während das CVCA des Deutschen Reisepasses auf der Internetseite des BSI für jedermann öffentlich verfügbar ist, werden das DVCA- und das IS-Zertifikat nur an Behörden und hoheitliche Institutionen ausgegeben. Daraus folgt, dass das Auslesen biometrischer Daten genau diesen Kreisen vorbehalten ist. Als Konsequenz kann die nachstehend vorgestellte Lesesoftware nur biografische Daten und das Gesichtsbild auslesen.

Datenstrukturen

Voraussetzung für die weltweite Interoperabilität elektronischer Reisepässe ist die durch ICAO veröffentlichte Spezifikation [1]. Hier sind neben den funktionalen Aspekten eines MRTD die Datenstrukturen und die Zugriffsmechanismen auf die Datencontainer des Chips definiert. Die derzeit aktuelle Logical Data Structure (LDS) enthält eine Reihe vordefinierter Elementary Files (EF). Die Inhalte der wichtigsten EFs sind in Tabelle 2 zusammengefasst. Neben der entsprechenden Kurzbeschreibung ist der jeweilige für den Zugriff erforderliche File Identifier (FID) in hexadezimaler Notation wiedergegeben. Die gesamte LDS ist TLV-kodiert (vgl. Teil 2 dieser Artikelserie) gespeichert und ist nach dem Auslesen entsprechend zu dekodieren.

LDS gemäß ICAO

EF Kurzbeschreibung FID
EF.COM Enthält die LDS-Versionsnummer (z. B. 1.7), die Unicodenummer (z. B. 4.0.0) und eine Liste, die alle gespeicherten und damit verfügbaren EFs enumeriert. 0x1E
EF.SOD Security Data Object enthält einen Hash-Wert und die korrespondierende Signatur für jede gespeicherte Datengruppe. Wird für die Validierung der Echtheit der im Chip gespeicherten Daten verwendet. 0x1D
EF.DG1 Biografische Daten des Passinhabers, Kontroll-Digits 0x81
EF.DG2 Gesichtsbild (ISO Image) 0x82
EF.DG3 Fingerabdrücke 0x83
EF.DG4 Iris-Scan 0x84
EF.DG14 EAC-Schlüsseldaten 0x8E
Lesersoftware mit GUI

Die nachfolgend im Detail vorgesellte Lesersoftware weist ein rudimentäres GUI gemäß Abbildung 3 auf, das zur Darstellung der aus dem Chip des Passes zu lesenden, biografischen Daten und des Gesichtsbildes geeignet ist. Weiterhin werden nach einem erfolgreichen Lesevorgang die MRZ und die Sicherheitsfeatures des Passes ausgegeben. Außerdem werden die während des Lesevorganges durchgeführten Aktionen direkt im unteren Teil des GUI ausgegeben.

Abb. 3: Lesersoftware mit GUI
Abb. 3: Lesersoftware mit GUI

Der Hauptmenüpunkt CONFIGURATION untergliedert sich in die beiden Untermenüpunkte READER und LOGGING. Der Erstgenannte ist für das Auswählen und Speichern eines im System verfügbaren kontaktlosen Lesers vorgesehen. Der Untermenüpunkt LOGGING ermöglicht die Vorgabe eines Logfiles, das den gesamten APDU- und Datenverkehr eines Lesevorganges protokolliert. Wie in Abbildung 4 gezeigt, lässt sich vorgeben, ob die aus dem Chip des Passes gelesenen Datengruppen persistent an einem wahlfreien Speicherort gespeichert werden sollen. Die auf diese Weise gespeicherten Datengruppen können via Schaltfläche READ FROM FILES (Abb. 3) wieder eingelesen und visualisiert werden, ohne dass der zugehörige Pass vorliegen muss.

Abb. 4: Einstellung der Logging-Optionen
Abb. 4: Einstellung der Logging-Optionen
Kompletter Leseprozess

Nachfolgend ist ein kompletter Leseprozess anhand der signifikanten Verarbeitungsschritte und Codesequenzen der in C# realisierten Lesersoftware sukzessive beschrieben. Die Beschreibungen beziehen auf das zu diesem Artikelteil gehörenden .NET-Projekt „ePassReader.sln“, das als ZIP-Datei auf www.windowsdeveloper.de verfügbar ist.

  • Das Aktivieren der Schaltfläche READ PASSPORT leitet den Lesevorgang ein. Zuvor sollte der zu lesende Pass auf den Kontaktlosleser gelegt werden.
  • Die Klasse ePassReader stellt die Methode ReadPassportData() mit folgender Funktionalität bereit: Herstellen einer Verbindung zum Chip via PC/SC-Interface (vgl. Teil 1 dieser Serie) mit SCConnect(). Selektion der „Issuer Data Application“ durch Zusammenstellen und Senden einer geeigneten APDU-Sequenz mit der Methode SendAPDU() der Klasse SCManager.
  • Ermittlung, ob es sich um einen Pass mit oder ohne BAC handelt, indem die von der Klasse DataGroupReader bereit gestellte Methode GetSecurityFeature() aufgerufen wird.
  • Liegt ein Pass mit „Passive Authentication“ vor, so wird der Lesevorgang unmittelbar durch den Aufruf der Methode ReadPA() der Klasse DataGroupReader gestartet.
  • Liegt hingegen ein BAC-Pass vor, so wird den obigen Ausführungen entsprechend, die auf der Datenseite des Passes aufgedruckte MRZ benötigt.
  • Hierfür ist die einfache Dialogbox „MRZ“ gemäß Abbildung 5 vorgesehen, die automatisch geöffnet wird.
Abb. 5: Dialogbox zur Eingabe der MRZ
Abb. 5: Dialogbox zur Eingabe der MRZ
  • Nachdem die Schaltfläche OK geklickt wurde, erfolgt der Aufruf der Methode ReadBAC() der Klasse DataGroupReader, wobei die in der Dialogbox „MRZ“ eingegebene MRZ als Parameter übergeben wird.
  • Nach erfolgreichem Lesen werden die gelesenen DG in der Hashtable htDataGroups zurückgegeben und der eigentliche Lesevorgang ist abgeschlossen, d. h. die im Chip gespeicherten Datengruppen konnten erfolgreich ausgelesen werden.
  • Die gelesenen biometrischen Daten können nun mit der Methode ProcessPassPortData() weiterverarbeitet werden, indem sie an das GUI übergeben und dort angezeigt werden.
  • Die Verarbeitung des Gesichtsbildes erfordert zunächst die Analyse, ob es sich um ein Standard-JPEG oder ein JPEG2000 handelt, denn beides ist zulässig. Ist letzteres der Fall, dann muss das Bild mit einem Add-on (z. B. FreeImageNET) konvertiert werden, da das .NET Framework ein JPEG2000 nicht verarbeiten kann.
  • Daran anschließend wird mit der Methode ProcessSignedData() die Validierung der gelesenen Datengruppen vorgenommen und die vorliegenden Signatur- und Hash-Algorithmen ermittelt und angezeigt.
  • Falls die oben beschriebene Option „WriteDatagroups to File“ selektiert ist, werden die Datengruppen in das voreingestellte Verzeichnis mit der Methode StoreDGs() gespeichert.
  • Nun ist der gesamte Lesezyklus beendet und es kann abschließend die bestehende Verbindung mit SCDisconnect() abgebaut werden.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -