Seite 2: Handarbeit

Inhaltsverzeichnis

Handarbeit

Nach einem CeBIT-Besuch, diversen Gesprächen mit Anbietern und einigen Probeinstallationen war klar, dass unsere Sicherheitsanforderungen alle verfügbaren kommerziellen Produkte vor unüberwindbare Probleme stellten. Vielfach kam der Hinweis, dass man so viel Sicherheit nicht wirklich brauche und man erst einmal mit einer kleinen Lösung anfangen könne, etwa einer Windows-Anmeldung an einem Active Directory mit Smartcard-Unterstützung. Die anderen Anwendungen und Systeme würde man dann im Rahmen von weiteren Projekten anbinden.

Hinzu kam, dass die Erfahrungen bei Probeinstallationen das Vertrauen des IT-Teams in die kommerziell verfügbaren Lösungen hinlänglich erschütterten. So konnte man beispielweise Produkte, die angeblich die PIN-Eingabe sicher schützen, durch simples Umändern eines Eintrages in der Windows-Registry von Debug=0 in Debug=255 dazu bewegen, die PIN freiwillig in eine Logdatei zu schreiben. Das Fazit der IT-Abteilung: Eine wirklich sichere Lösung erhält man nur dann, wenn man sich persönlich von der Funktionalität der Software überzeugt. In letzter Konsequenz benötigt man den Quellcode, um sich mit eigenen Augen davon zu überzeugen, was die Software macht.

Eine weitere Schlussfolgerung war, dass es für die IT-Umgebung der Nordrheinischen Ärzteversorgung (nur Unix-Server, Samba als Domänencontroller für die Windows-Clients, Microsoft-Produkte nur an den W2K-Arbeitsplätzen, aber auch dort kein IE oder Outlook) offenbar sowieso keine fertige Lösung gab. Das reduzierte die verfügbaren Optionen auf zwei: Aufgeben oder selber programmieren.

Letzteres war dann überraschend einfach: Mit OpenSSL und OpenSC standen zwei freie Software-Pakete zur Verfügung, die alle wesentlichen Bestandteile für ein sicheres Anmeldesystem enthielten. OpenSSL liefert alles, was man braucht, wenn man mit asymmetrischer Kryptographie und Zertifikaten arbeiten will. OpenSC sorgt für die Middleware zum Zugriff auf Smartcards. Beide Produkte mussten "nur noch" zusammengeschmiedet und mit den vorhandenen Anwendungen über Schnittstellen verbunden werden.

Schnittstellen gab es reichlich. Glücklicherweise waren die meisten entweder standardisiert oder durch Beschreibungen und Beispiel-Quelltexte im Internet dokumentiert. Die eigentliche Arbeit bestand somit weniger in der Programmierung als vielmehr in der Einarbeitung in diverse unterschiedliche Vorgehensweisen und Standards im Smartcard-Umfeld.

Die Frage, welchen Gegenstand man als Authentifizierungs-Token einsetzen sollte, hatte sich indessen während der Vorbereitungsarbeiten erübrigt. Anlässlich eines Umzugs der Nordrheinische Ärzteversorung im Jahr 2003 bekamen alle Mitarbeiter einen neuen Mitarbeiterausweis in die Hand gedrückt. Der enthielt einen Crypto-Chip für die spätere Anmeldung am PC, für den man sich nach dem Motto "Wenn die Software, die diesen Chip benutzen soll, noch nicht feststeht, nehmen wir den Chip mit der besten frei verfügbaren Dokumentation" entschieden hatte. Dieses Auswahlkriterium hat sich in der folgenden Zeit dann auch sehr ausgezahlt.

Bei den Schnittstellen, die implementiert werden mussten, stellte sich die Situation wie folgt dar:

• Der Windows-Logon an der Samba-Domäne basiert Windows-seitig auf der sehr gut dokumentierten Schnittstelle MS-GINA. Serverseitig kann man durch die offen verfügbaren Quelltexte von Samba beliebig in den Authentifizierungsmechanismus eingreifen. Praktischerweise ist der Samba-Quellcode so schön modularisiert, dass man schnell die Stelle gefunden hat, an der man die herkömmliche Passwort-Authentifizierung gegen ein anderes Verfahren austauschen kann.

• SAP setzt auf Standards, nicht nur was die Authentifizierung betrifft, aber in dem Bereich besonders gut. Für den Austausch der Passwort-basierten Anmeldung gegen ein anderes Verfahren gibt es eine genau für diesen Zweck vorgesehene Schnittstelle. SAP nennt sie SNC-Adapter (Secure Network Communication), aber dahinter verbirgt sich das Generic Security Service API, ergänzt um eine kleine SAP-Spezialität. Das GSS-API wurde als Request for Comment veröffentlicht (unter anderem RFCs 1508, 2078, 2743) und im Netz findet man diverse Beispielimplementationen.

• Bei Browser und Mail-Programm verwendet die Nordrheinische Ärzteversorgung die Programme der Mozilla-Suite. Diese benutzen den PKCS#11-Standard für den Zugriff auf Mitarbeiterausweise und ähnliche krytographische Gerätschaften. Die erste Version dieses De-facto-Standards der Firma RSA stammt aus dem Jahr 1995 und ist hinlänglich bekannt. Beispiele zu seiner Nutzung findet man im Netz.

• Intranet-Anwendungen werden bei der Nordrheinische Ärzteversorgung mit PHP-Frameworks erstellt. Die Skriptsprache besitzt von Haus aus eine Schnittstelle zu OpenSSL. Mehr braucht man auch serverseitig nicht, denn die Schnittstelle zur Smartcard wird nur da benötigt, wo sich die Smartcards befinden, also auf den Clients.

• Für selbsterstellte Anwendungen kann der einfache Weg gewählt werden, OpenSSL und/oder OpenSC direkt einzubinden. Beim Verstehen der APIs dieser freien Produkte helfen die Teilnehmer der einschlägigen Mailinglisten schnell und kompetent. In diese Gruppe gehören bei der Nordrheinischen Ärzteversorgung eine ganze Reihe von Oracle-Anwendungen, die über das Foreign Function Interface von Oracle Forms auf beliebige Windows-DLLs – also auch auf die OpenSSL-Bibliotheken – zugreifen können.

Bei der Implementation der genannten Schnittstellen (und einiger weiterer, siehe hierzu die Grafik) erwies sich die Koordination zwischen den unterschiedlichen Schnittstellen zuweilen als Problem. So sieht der PKCS#11-Standard zwar den gleichzeitigen Zugriff mehrerer Anwendungen auf die Smartcard zu, aber nur, wenn alle Anwendungen auch das PKCS#11-API benutzen. Bei der Nordrheinischen Ärzteversorgung musste aber ein den GSS-API-Standard benutzendes SAP-GUI mit einem den PKCS#11-Standard benutzenden Mozilla-Browser zusammenspielen und das Ganze auf einem W2K-Arbeitsplatz, dessen Bildschirmschoner ebenfalls mit der Smartcard kommunizieren muss.

Bei der Auswahl des Mitarbeiterausweises hatte das Team die OpenSC-Unterstützung für diese Smartcard nur sehr oberflächlich überprüft. 2003 unterstützte OpenSC zwar bereits das Betriebssystem des in dieser Karte enthaltenen Crypto-Chips (TCOS 2.0), aber leider nicht das spezielle Karten-Layout der ausgewählten Smartcard (NetKey E4 Card). Dieses Problem brachte einen wesentlichen Vorteil von freier Software zu Tage: Wenn etwas fehlt, kann man es – entsprechende Kenntnisse vorausgesetzt – selbst hinzufügen. Und so wurde der Autor dieses Artikels über Nacht Mitglied des OpenSC-Entwicklerteams, konnte Dank der vorhandenen Karten-Dokumentation den für sein eigenes Projekt erforderlichen Treiber erstellen und ist seit 2004 innerhalb des OpenSC-Projektes für TCOS-basierte deutsche Signaturkarten zuständig.