Mit Karte, bitte!

Elektronische Dokumente ID über Chip (Teil 3)
Kommentare

Windows Developer

Der Artikel „ID über Chip“ von Helmut Stoiber ist erstmalig erschienen im Windows Developer 9.2012
Secure Messaging
Während des oben beschriebenen Leseprozesses können die im Chip

Windows Developer

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

Secure Messaging

Während des oben beschriebenen Leseprozesses können die im Chip des Passes gespeicherten Daten nicht ausgelesen werden, bevor die zu sendenden Datensequenzen in geeigneter Weise umkodiert wurden. Um beispielsweise eine sichere Kommunikation gemäß BAC-Spezifikation zwischen dem Chip des Passes und einer Lesersoftware aufbauen zu können, müssen zunächst die beiden Schlüssel K_ENC und K_MAC aus der MRZ errechnet werden. Während der Schlüssel K_ENC für das Verschlüsseln (Encryption) benötigt wird, ist für die Erzeugung eines Message Authentication Codes der Schlüssel K_MAC erforderlich. Nachdem diese beiden Schlüssel generiert sind, kann die nachfolgende Authentifizierungssequenz durchlaufen werden:

  • Anforderung einer Zufallszahl vom Chip des Passes durch das einfache Senden einer APDU-Sequenz (RND_ICC)
  • Generieren zweier Zufallszahlen mit 8-Bit (RND_IFD) und 16-Bit (K_IFD)
  • Verkettung der Zufallszahlen und anschließende Verschlüsselung mit dem Schlüssel K_ENC, wobei der symmetrische 3DES-Algorithmus anzuwenden ist, sodass das Kryptogramm E_IFD resultiert
  • Generierung einer auf E_IFD basierenden MAC-Sequenz nach dem CBC-Verfahren (Cypher Block Chain)
  • Verkettung von E_IFD und E_IFD zu einer Sequenz (E_IFD||E_IFD), die an den Chip gesendet wird
  • Überprüfung der vom Chip gesendeten MAC-Sequenz mit dem Schlüssel K_MAC
  • Entschlüsselung der vom Chip gesendeten Daten mit dem Schlüssel K_ENC
  • Erzeugung eines temporären Schlüssels K_SEED basierend auf K_IFD und K_ICC, wobei K_ICC aus der zuletzt vom Chip empfangenen Bytesequenz abgeleitet wird
  • Ableitung der beiden Session Keys KS_ENC und KS_MAC aus K_SEED
  • Ableitung des Sequenzzählers CSC aus RND_ICC und RND_IFD

Der gesamte Datenverkehr zwischen den Kommunikationspartnern Passbuchchip und einer Lesersoftware wird während der aktuellen Sitzung mit dem temporären Session Key KS_ENC verschlüsselt bzw. entschlüsselt. Der temporäre Schlüssel KS_MAC wird ebenfalls nur während der aktuellen Sitzung für die Berechnung der MAC-Sequenzen verwendet. Der Wert des Sequenzzählers CSC wird vom jeweiligen Kommunikationspartner vor jedem Sendevorgang inkrementiert und in die zu sendende Sequenz kodiert. Diese Technik ermöglicht das Erkennen, respektive Verhindern, von so genannten „Replay-Attacken“. Hierbei versucht ein Angreifer zuvor abgegriffene Sequenzen einer Session modifiziert oder unverändert in die Kommunikation einzuschleusen. Da aber in einem solchen Fall der aktuelle Wert des Sequenzzählers nicht mit dem empfangenen Sequenzzählerstand übereinstimmt, kann der Angriff eindeutig erkannt werden.

Bildformate des ISO-Images

Das in der Datengruppe EF.DG2 gespeicherte Gesichtsbild kann entweder als JPEG oder als JPEG2000 kodiert sein und ist gemäß [1] innerhalb von Kontrolldaten verschachtelt. Demzufolge sind zunächst die effektiven Bilddaten aus der Datengruppe EF.DG2 zu extrahieren, um daran anschließend zu ermitteln, ob eine Kodierung nach JPEG oder JPEG2000 vorliegt. Hierfür werden gemäß Listing 1 die binären Bilddaten auf definierte Bytemuster durchsucht. Die Suchmuster sind im vorliegenden Beispiel-Listing in den Variablen bJP2 für JPEG sowie bFIF bzw. bJFIFStart für JPEG2000 gespeichert. Nach erfolgreichem Matching werden die binären Bilddaten in das Byte Array bFaceImage kopiert.

Listing 1: Verarbeitung des ISO-Images

public static bool DisplayImage(...)
{
  byte[] bFaceImage = null;
  byte[] bJP2 = { 0x00, 0x00, 0x00, 0x0c, 0x6a }; // JP2
  byte[] bJFIFStart = { 0xFF, 0xD8, 0xFF, 0xE0 }; // FF D8 FF E0
  byte[] bJFIF = { 0x4A, 0x46, 0x49, 0x46 };// 4A 46 49 46 JFIF
        
  // JPEG  oder JPEG2000
  long lPos = Util.ArrayIndexOf(bImage, bJP2);
  if (lPos != -1) {
    bFaceImage = new byte[bImage.Length - lPos];
    Array.Copy(bImage, lPos, bFaceImage, 0, bImage.Length - lPos);
  } else {
  lPos = Util.ArrayIndexOf(bImage, bJFIFStart);
  if (lPos != -1 && Util.ArrayIndexOf(bImage, bJFIF) > -1) {
    bFaceImage = new byte[bImage.Length - lPos];
    Array.Copy(bImage, lPos, bFaceImage, 0, bImage.Length - lPos);
  } else
    return false;
  }
   
  // Überprüfen, ob auf FreeImage.dll zugegriffen werden kann
  if (!FreeImage.IsAvailable()) return false;

  // Bitmap-Daten an FreeImage übergeben
  FIBITMAP dib = FreeImage.LoadFromStream(new MemoryStream(bFaceImage));
  if (dib.IsNull) return false;

  // Konvertierung des FreeImage-Bitmaps zu einem .NET-Bitmap
  Bitmap bitmap = FreeImage.GetBitmap(dib);

  // Aktuelles Bitmap anzeigen
  if (bitmap != null)
  {
    // Falls vorhanden, altes Bitmap verwerfen
    if (pictureBox.Image != null) pictureBox.Image.Dispose();
    pictureBox.Image = bitmap;
  }
  FreeImage.UnloadEx(ref dib);
  return true;
}  

Da das JPEG2000-Format vom .NET Framework nicht unterstützt wird, muss auf ein geeignetes Add-on zurückgegriffen werden. Im vorliegenden Fall findet FreeImage Verwendung, das über den Link [4] frei verfügbar ist. Bevor FreeImage verwendet werden kann, ist die DLL FreeImageNET als Projektverweis in Visual Studio einzubinden. Während der Laufzeit müssen die DLLs FreeImage.dll und FreeImageNET.dll entweder im Laufzeitverzeichnis oder in einem Verzeichnis, das in gesetzt ist, gespeichert sein. Genau diese Verfügbarkeit wird, wie in Listing 1 gezeigt, überprüft, bevor die in bFaceImage gespeicherten Bitmap-Daten an FreeImage übergeben werden. Um das Bitmap in einer .NET Picturebox anzeigen zu können, wird es zuvor mit der Methode GetBitmap() der Klasse FreeImage entsprechend konvertiert und anschließend der .NET Picturebox zugewiesen.

Ausblick

Das ohnehin schon sehr breite Spektrum an verschiedensten Anwendungen mit Chipkarten erweitert sich ständig. Beispielsweise wurden in Deutschland der elektronische Reisepass und anschließend der digitale Personalausweis erfolgreich eingeführt. Derzeit laufen Bestrebungen, die ebenfalls auf Chipkarten basierende „Elektronische Gesundheitskarte“ großflächig einzuführen. Ein Ende der Weiterentwicklung der Chipkarte als solches und den korrespondierenden Hintergrundsystemen ist nicht abzusehen. Dies zeigt sich besonders deutlich im Hinblick auf die ständig steigenden Verarbeitungsgeschwindigkeiten und den realisierbaren Speicherkapazitäten. Aktuell ist das Thema Near Field Communication (NFC) in aller Munde, wobei auch hier eine Chipkarte die Basis für diese neue Technologie bereitstellt. Auch wenn der traditionelle Formfaktor der Chipkarte ID-1 immer seltener anzutreffen ist und stattdessen die Miniaturisierung des „Chipträgers“ sehr weit fortgeschritten und variantenreich ist oder das Chipinterface über eine USB-Schnittstelle oder eine RFID-Schnittstelle realisiert ist, basieren auch die modernsten Technologien auf der im ersten Artikelteil vorgestellten, rudimentären Architektur: Prozessor, Speicher- und IO-Komponente. Die Chipkarte und die diversen Derivate sind und werden auch in Zukunft die erste Wahl sein, wenn es um Hochsicherheit von Daten und Kommunikation sowie Mobilität geht.

Dipl.-Ing. Helmut Stoiber ist externer Berater für Software- und Systemarchitektur mit Schwerpunkt Sicherheitstechnologie sowie EDV-Sachverständiger für Systeme und Anwendungen der Informationsverarbeitung. Sie erreichen ihn unter hs@itgutachten.net.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -