Smartcards sind in der heutigen IT-Landschaft allgegenwärtig. Linux zeigt auch in diesem Bereich, dass es mit nahezu allem kommuniziert, was zwischen Null und Eins unterscheiden kann.

Chipkarten sind aus dem Alltag nicht mehr wegzudenken, seit Anfang der 80ger Jahre die ersten Pilotversuche mit Telefonkarten und Karten zum bargeldlosen Zahlungsverkehr durchgeführt wurden. Die Plastikkarten werden in Bereichen wie Zeiterfassung, Mobilfunk (SIM-Karten), Zugangskontrolle, Bank- und Gesundheitswesen eingesetzt. Es wird wohl kaum jemanden geben, der mit ihnen noch nicht in Kontakt gekommen ist. Der folgende Artikel erklärt die grundlegenden Elemente solcher mit Hightech bepackten Chipkarten und beschreibt Einsatzmöglichkeiten von Kartenlesern und -schreibern unter Linux.

Die glorreichen Drei

Grundsätzlich gibt es drei Chipkartentypen: Speicher- und Prozessorkarten sowie die kontaktlosen Karten. Speicherkarten besitzen keine oder nur sehr geringe Intelligenz. Neben den reinen Speicherkarten, die gänzlich ungeschützt sind und beliebig Bit für Bit ausgelesen und beschrieben werden können, gibt es auch Karten, bei denen der Zugriff auf den Speicher durch eine Sicherheitslogik kontrolliert wird: Schreiboperationen sind erst dann ausführbar, wenn eine eingegebene PIN (Personal Identification Number) an die Karte gesendet, dort mit einer Referenz-PIN verglichen und die Übereinstimmung festgestellt wird.

Die Architektur einer solchen Speicherkarte besteht aus der schon erwähnten Sicherheitslogik, einem EEPROM (Electrically Erasable Programmable Read Only Memory), dessen Größen in der Regel zwischen 256 Byte und 8 KByte liegt, einem ROM und der nach außen offenen I/O-Schnittstelle.

Die Kommunikation solcher Speicherkarten mit einem Kartenleser beziehungsweise -schreiber (oft als Terminal bezeichnet) erfolgt über ein synchrones serielles Übertragungsprotokoll wie zum Beispiel I2C. Typische Beispiele solcher Speicherkarten sind Telefonkarten oder Krankenversicherungskarten (KVK).

Mehr als speichern

So richtig smart sind Speicherkarten noch nicht – über Eigenintelligenz verfügen erst Prozessorkarten, die häufig auch Smartcards genannt werden. Neben dem reinen Abspeichern von Informationen können diese Karten noch wesentlich komplexere Aufgaben wie etwa die Verschlüsselung von Daten übernehmen. Die Architektur von Prozessorkarten besteht aus einem vollständigen Rechner mit Microcontroller, RAM, ROM und EEPROM. Smartcards mit Security-Funktionen enthalten zusätzliche Komponenten wie Coprozessor, Zufallsgenerator oder spezielle Recheneinheiten zur DES- oder RSA-Verschlüsselung.

Das ROM enthält das Betriebssystem des Chips und wird bei der Herstellung eingebrannt; das EEPROM dient als nicht-flüchtiger Speicher und beinhaltet Daten und Programmcode, es ist nur unter Kontrolle des Betriebssystems les- und beschreibbar. Es gibt keine I/O-Leitungen, über die von außen direkt auf diesen Speicher zugegriffen werden kann – sämtliche Daten lassen sich nur über festgelegte Anfragen an den Prozessor auslesen und verändern. Beliebiger Lesezugriff wie bei Speicherkarten ist hier nicht möglich.

Wie bei Speicherkarten erfolgt die Kommunikation mit dem Terminal über ein serielles Übertragungsprotokoll. Am weitesten verbreitet sind die Protokolle T=0 und T=1. Beide arbeiten asynchron. T=0 wird weltweit in GSM-Karten eingesetzt und ist Byte-orientiert – die kleinste Einheit, die dieses Protokoll bearbeitet, ist also ein Byte. Das Protokoll T=1 ist blockorientiert, hier ist die kleinste Einheit ein Block, der aus mehreren Bytes besteht.

Prüfen im Vorübergehen

Neben den Speicher- und Prozessorkarten gibt es als dritte Variante die kontaktlosen Karten. Sie haben den großen Vorteil, dass sie nicht in einen Kartenleser geschoben werden müssen, um von ihnen Daten lesen zu können: Sie werden lediglich an dem Kartenleser entlanggezogen.

Kontaktlose Karten werden vor allem dort eingesetzt, wo in kürzester Zeit sehr viele Authentifizierungen durchgeführt werden müssen, etwa im Personenverkehr. Terminals für kontaktlose Karten arbeiten nach dem Prinzip der induktiven Kopplung und erlauben Entfernungen bis zu einem Meter.

Für den eigentlichen Zugriff auf eine Smartcard benötigt man neben der Karte selbst einen Kartenleser und -schreiber: Dieses Terminal bildet die Schnittstelle zwischen dem Host und der Chipkarte. Die Hauptaufgabe des Terminals besteht im Austausch von Daten und Befehlen mit der Karte, diese Kommunikation wird auch als Pingpong-Kommunikation bezeichnet und erfolgt halbduplex: Das bedeutet, dass immer nur einer der Kommunikationspartner senden oder empfangen darf.

Karte und Terminal arbeiten zusammen

Die Kommunikation sieht folgermaßen aus: Das Terminal sendet einen Befehl (Command) an die Karte, die die Anfrage bearbeitet und das Ergebnis (Response) an das Terminal zurückschickt. Für diesen Datenaustausch werden so genannte APDUs (Application Protocol Data Units) verwendet, die als universelle Container für Befehle und Daten dienen. Man unterscheidet zwischen Command-APDUs, die den Befehl an die Karte enthalten, und Response-APDUs, die die Antwort der Karte aufnehmen. Abbildung 1 zeigt den Aufbau der APDUs und den Kommunikationsfluss zwischen Terminal und Smartcard.

Die Command-APDU setzt sich aus Header und Body zusammen. Der Header besteht aus vier jeweils 1 Byte großen Elementen: Class (CLA), Instruction (INS) und den beiden Parametern 1 und 2 (P1, P2). CLA gibt den zu verwendenden Befehlssatz an: So bezeichnet etwa das Class-Byte »A0« den GSM-Befehlssatz. Der eigentliche Befehl ist in dem Instruction-Byte kodiert. P1 und P2 dienen der genaueren Parametrisierung des Instruction-Kommandos. Im Body gibt Lc die Länge des Datenfelds an, das optional an die Karte zu verschickende Daten enthalten kann. Le schließlich spezifiziert noch die Größe des von der Karte zurückzusendenden Datenblocks. Hat die Karte die Command-APDU empfangen und unterstützt sie den angeforderten Befehlssatz, wird der Befehl bearbeitet und das Ergebnis ans Terminal zurückgeschickt.

Eine Response-APDU besteht aus dem optionalen Body, dessen Länge im Le-Feld der Command-APDU spezifiziert wurde, und den Trailern SW1 und SW2. Das optionale Datenfeld kann je nach Befehl Antwortdaten für das Terminal enthalten. Die beiden Trailer-Bytes sind hingegen zwingend vorgeschrieben, da sie den Result Code des auszuführenden Befehls enthalten.

Das ist die einzige Möglichkeit, um zu erkennen, ob die Chipkarte den angeforderten Befehl ordnungsgemäß ausführen konnte oder ob ein Fehler aufgetreten ist. Bei einem korrekt ausgeführten Befehl enthalten SW1 und SW2 das Wertepaar »90 00« oder »9F XY«, falls noch eine Antwort-APDU in der Größe von »XY« Bytes vorliegt.

Abbildung 1: Über die Application Protocol Data Units (APDUs) tauschen sich Terminal und Karte aus; auf jede Anfrage des Terminals hat die Karte eine Antwort.

Smartcard-Terminals

Für Linux gibt es diverse Chipkarten-Terminals; angeboten werden sie unter anderem von den Firmen[2], [3] und [4]. Das meistverbreitete ist wohl das Chipdrive von Towitoko[2]. Towitoko bietet neben Schlumberger ein Linux-Developer-Paket an, das ein Terminal, Treiber, API-Dokumentation und zwei Smartcards enthält.

Wer die zirka 45 Euro für das Linux-Paket sparen möchte, kann oft ein Chipdrive-Terminal bei diversen Internet-Auktionen günstig ersteigern und sich Treiber und Dokumentation aus dem Internet holen. Lediglich Karten zum Testen müssen dann noch etwa bei[8] oder [9] erworben werden. Hat man das Chipdrive an den Rechner angeschlossen und sich die Treiber von[1], [2] heruntergeladen, folgt die Installation:

tar zxvf towitoko-2.0.5.tar.gz
configure
make
make install
ldconfig

Die Programmierung eigener Smartcard-Applikationen kann etwa über die vom Towitoko-Treiber unterstützte Programmierschnittstelle CT-API erfolgen. Dem Treiber liegt das Programm Tester bei, mit dem über ein rudimentäres Benutzer-Interface von der Karte gelesen und auf sie geschrieben werden kann. Hier ist direkt zu erkennen, ob der Treiber richtig eingerichtet wurde und die Kommunikation zwischen dem Host-System und dem Terminal funktioniert.

Das Tool setzt auf der CT-API auf und kann als erstes Referenz-Programm für die Smartcard-Programmierung dienen. Das Thema Programmierung von Smartcard-Applikationen lässt sich nicht in ein paar Zeilen beschreiben, ein eigener Artikel im nächsten Linux-Magazin wird sich damit befassen.

Steuerung per Skript

Ein weiteres auf der CT-API aufsetzendes Programm ist Smartcard, das unter[6] erhältlich ist. Es steht unter der GNU General Public License und ist ein kommandozeilenbasiertes Tool, das die Kommunikation mit Terminals ermöglicht, auf die über die CT-API zugegriffen werden kann.

Mit einfachen Kommandos wie »read« und »write«, der Angabe des Ports, an dem das Terminal angeschlossen ist, und Spezifikation der zu lesenden oder schreibenden Bytes können Speicherkarten (und nur diese) bearbeitet werden. Der folgende Aufruf liest von Port »0« (»/dev/ ttyS0«) 10 Bytes und gibt sie auf der Standardausgabe aus:

smartcard --read --count=10 --port=0

Wem die Eingabe über die Kommandozeile zu umständlich ist, der findet unter[5] ein GTK-basiertes Tool namens Gsmartcard. Diese Gnome-Applikation setzt auf Smartcard auf und stellt dessen Funktionalität unter einer ansprechenden Oberfläche zur Verfügung. Mit Hilfe des Programms lassen sich Speicherkarten auslesen, beschreiben, löschen und kopieren.

Smartcard-Anwendungen für Linux

Als erster Web-Anlaufpunkt rund um das Thema Smartcards und Linux sei das M.U.S.C.L.E.-Projekt[1] genannt: Movement for the Use of SmartCards in a Linux Environment. Neben der Bereitstellung von Treibern, Dokumentation, Applikationen und einer Linkliste zu Smartcard- und Terminal-Herstellern wird auch eine Mailingliste gepflegt, die über das Thema informiert. Das Linux-Developer-Paket von Towitoko ist ebenfalls in Zusammenarbeit mit diesem Projekt entstanden.

Die wohl häufigste Aufgabe von Smartcards ist die Authentifizierung eines Benutzers gegenüber einem System. Beispiele sind normale Benutzer-Logins, der Login-Mechanismus für einen Web- oder FTP-Server, der Zugang zum passwortgeschützten Tagebuch oder Ähnliches. Alle Anwendungen haben eins gemeinsam: Erst nach erfolgreicher Authentifizierung erhält der Benutzer Zugriff auf den geschützten Datenbereich.

Der verbreitetste Login-Mechanismus ist die Eingabe eines Passworts über die Tastatur und der anschließende Vergleich des eingegebenen Passworts mit einem auf dem System gespeicherten Referenz-Passwort (etwa in »/etc/ passwd«). Möchte man für den System-Login nicht mehr auf die lokal gespeicherte Datei »passwd« zugreifen, sondern die Authentifizierung über einen NIS-Server durchführen, eine Smartcard verwenden oder ein gänzlich anderes Verfahren einsetzen, müssten im Regelfall der Source Code angepasst und das System neu kompiliert werden. Das ist gerade im Hinblick auf die immer größer werdenden und sich ständig ändernden Sicherheitsanforderungen nicht gerade flexibel.

Abbildung 2: Wer die Kommandozeile scheut, kann Gsmartcard einsetzen, die Gnome-Smartcard-Applikation für Speicherkarten.

PAM-Authentifizierung

Um mit Linux einen flexiblen Authentifizierungsmechanismus realisieren zu können, wurde das Linux-PAM-Projekt (Pluggable Authentication Module)[10] ins Leben gerufen: Linux-PAM ist eine Sammlung von Modulen zur Benutzer-Authentifikation. PAM-kompatible Programme nutzen ein festes PAM-Interface, das unabhängig von dem gewünschten Authentifizierungsmechanismus ist. Man erreicht so eine Entkopplung der Applikation von der tatsächlich verwendeten Authentifizierung.

Über eine zum Programm gehörende Konfigurationsdatei wird der gewünschte Mechanismus festgelegt. In dieser Datei steht, welches PAM-Modul verwendet und wie gegebenenfalls auf Ergebnisse des Moduls reagiert werden soll. Es lassen sich auch mehrere Module der Reihe nach durchlaufen – dies wird als Modul-Stacking bezeichnet.

Die eigentliche Authentifizierung wird dann nicht mehr von der Applikation selbst, sondern von dem jeweiligen PAM-Modul übernommen. Da nun lediglich die PAM-Konfigurations-Datei geändert werden muss, entfällt das umständliche Neukompilieren und man kann sehr flexibel auf neue Sicherheitsanforderungen reagieren.

PAM wurde ursprünglich von Sun entwickelt, ist aber mittlerweile für Solaris, HP-UX und FreeBSD verfügbar. Linux-PAM hat Einzug in die meisten Distributionen wie Red Hat, Caldera, Debian und SuSE gehalten. Abbildung 3 verdeutlicht das prinzipielle Zusammenspiel zwischen Applikation, PAM und Authentifizierungsmechanismus.

Abbildung 3: Wird zur Authentifizierung PAM verwendet, braucht die Applikation sich nicht um verschiedene Mechanismen zu kümmern.

Konfiguration von PAM-Modulen

Wie zuvor bereits angesprochen gibt es für jede PAM-fähige Applikation eine Konfigurationsdatei, die den Authentifizierungsmechanismus beschreibt. Diese Datei befindet sich normalerweise unter »/etc/pam.d/«. Ältere Versionen von Linux-PAM hatten eine zentrale Konfigurationsdatei »/etc/pam.conf« für alle Anwendungen.

Eine PAM-Datei besteht für jedes zu verwendende Modul aus vier Einträgen:

• Modul-Typ: Zeigt die zu übernehmende Management-Aufgabe.
• Control-Flag: Gibt an, wie im Falle eines fehlerhaften oder korrekt abgearbeiteten Moduls weiter vorgegangen werden soll.
• Modul-Pfad: Modulname mit Pfadangabe.
• Argumente: Argumente für den Modul-Aufruf.

Im Kasten “PAM-Smartcard-Login” wird exemplarisch der Aufbau der PAM-Konfigurationsdatei für den Standard-Login-Vorgang mit Hilfe einer RSA-Smartcard beschrieben.

PAM-Modul für RSA-Smartcards

Übliche Authentifizierungsverfahren, bei denen sich Benutzer lediglich über ein Passwort ausweisen (One Factor Authentication Systems), werden dem Wunsch nach mehr Sicherheit oft nicht mehr gerecht: Jeder Angreifer, der sich Zugang zu dem Passwort verschafft hat (etwa durch Sniffing oder Social Engineering), kann ohne weiteres auf sensible Daten zugreifen.

Abhilfe schaffen so genannte Two Factor Authentication Systems, bei denen der Benutzer neben einem Passwort noch eine Art Schlüssel besitzen muss. Erst dieser zweite Schlüssel authentifiziert eindeutig die Person. Die unter[11] und[12] zu findenden PAM-Module realisieren ein solches System, indem sie auf einer RSA-Smartcard den privaten Schlüssel des Benutzers abspeichern.

Das Projekt Smartcard-Login[11] wurde als Projektarbeit an der Zürcher Hochschule Winterthur[13] realisiert und erlaubt die lokale Anmeldung an einem Linux-System mit Hilfe einer RSA-Smartcard. Darauf aufbauend wurde eine Diplomarbeit[12] erstellt, die den Login-Mechanismus auf netzwerkweiten Einsatz erweitert.

Die Installation des RSA-Smartcard-PAM-Moduls ist sehr gut in einem Howto beschrieben und braucht daher hier keine Erläuterungen. Nach Installation der benötigten Programmpakete (OpenLDAP, OpenSSH, OpenSSL, Flex, diversen Perl-Skripten, Linux-PAM, PC/SC-Lite und eines entsprechenden Terminal-Treibers) ist für die jeweilige PAM-Applikation einzustellen, dass das RSA-Smartcard-Modul verwendet werden soll. Anschließend werden für jeden Benutzer ein X.509-Zertifikat, das den öffentlichen Schlüssel des Benutzers enthält, sowie der private Schlüssel und ein Passwort auf die Smartcard geschrieben. Ein nachträgliches Auslesen des Passworts oder des privaten Schlüssels ist nicht möglich, so dass ein Verlust der Smartcard zu verschmerzen und kein Sicherheitsrisiko ist.

Möchte sich ein Benutzer anmelden, so wird folgendes Szenario durchlaufen: Der Benutzer gibt seinen Benutzernamen und das Passwort ein, womit die Krypto-Funktionen auf der Smartcard freigeschaltet werden. Anschließend wird das Zertifikat von der Karte ausgelesen und auf Gültigkeit überprüft. Dies geschieht mit einem Root-Zertifikat einer netzwerkweiten Certificate Revocation List (CRL). Die CRL enthält eine Liste aller gesperrten Zertifikate. So lassen sich beispielsweise Zertifikate mit einer beschränkten Gültigkeitsdauer nach Ablauf eintragen.

Ist ein entsprechendes Benutzerprofil auf der Karte eingetragen, wird eine Zufallszahl erzeugt (»/dev/urandom«) und an die Smartcard geschickt, von dieser mit Hilfe des im Zertifikat befindlichen privaten Schlüssels signiert und zurückgeschickt (der private Schlüssel verlässt dabei nie die Smartcard). Anschließend wird das Resultat mit dem öffentlichen Schlüssel dekodiert und mit der ursprünglichen Zufallszahl verglichen.

Stimmen beide Werte überein, konnte der Benutzer eindeutig erkannt werden, anderenfalls wird der Login-Versuch abgebrochen. Als Hardware-Umgebung kam das Kartenterminal Chipdrive von Towitoko zum Einsatz – prinzipiell ist aber wohl jedes Terminal mit entsprechender PC/SC-IFD-Handler-Unterstützung einsetzbar.

Die Smartcard sollte eine an sie geschickte Nachricht mit einem auf der Karte gespeicherten privaten Schlüssel verschlüsseln können. Zum Einsatz kam hier die RSA-Smartcard Cyberflex, die dankenswerterweise von Mario Strasser, einem der beiden Autoren der Diplomarbeit, zur Verfügung gestellt wurde. Insgesamt ist diese Diplomarbeit wirklich gut gelungen und die Autoren können gewiss sein, dass ihre Arbeit nicht wie viele andere in irgendeiner Uni-Schublade verstaubt.

Fazit

Smartcards werden in Zukunft immer mehr an Verbreitung gewinnen. Neben dem herkömmlichen Einsatz, etwa im Zahlungsverkehr, werden im Bereich Authentifizierung immer mehr personenbezogene Daten auf ihnen gespeichert und verwaltet. Das können digitale Unterschriften oder biometrische Daten sein. Gerade in diesem sensiblen Umfeld wird das Thema Sicherheit die meiste Aufmerksamkeit finden.

Wer mehr über die Technik von Smartcards erfahren möchte, dem sei das Buch[7] als umfangreiches Nachschlagewerk empfohlen. ( hge)

PAM-Smartcard-Login