Smartcard-Authentifizierung bei der Nordrheinischen Ärzteversorgung

Inhaltsverzeichnis

Seit vier Jahren melden sich die Mitarbeiter der Nordrheinischen Ärzteversorgung an allen Systemen ausschließlich mit ihrem als Smartcard implementierten Mitarbeiterausweis an. Alle Anwendungen greifen bei der Anmeldung auf den in der Tastatur eingebauten Kartenleser und die dort befindliche Smartcard zu. Die Smartcard selbst muss der Benutzer zuvor durch die Eingabe einer 6-stelligen PIN freischalteten.

Dieses Verfahren hat die Datensicherheit bei der Nordrheinischen Ärzteversorgung im Vergleich zur herkömmlichen Anmeldung mit Kennwort deutlich erhöht. Für die Mitarbeiter ist die Smartcard zudem bequemer als das Jonglieren mit vielen unterschiedlichen Passwörtern.

Da bei der Suche nach einer sicheren Alternative zur traditionellen Anmeldung per Passwort keine kommerzielle Lösung den Anforderungen der Nordrheinischen Ärzteversorgung genügte, griff das IT-Team in die Werkzeugkiste und erstellte ein eigenes System, das auf der freien Software OpenSSL und OpenSC aufsetzt. Das Vorgehen hat gegenüber einer kommerziellen Lösung deutlich Kosten gespart und eine maßgeschneiderte Lösung möglich gemacht, die höchsten Ansprüchen gerecht wird.

Die Zielsetzung des Projektes "Authentifizierung mittels Mitarbeiterausweis" bestand darin, alle Passwort-Anmeldungen durch ein einheitliches, sicheres, aber dennoch einfach handhabbares Authentifizierungsverfahren zu ersetzen. Man hätte im Prinzip auch schwierig zu erratende Kennwörter erzwingen und die Anwender nötigen können, ihre Passwörter periodisch zu ändern. Das eigentliche Problem jedoch – das Ausspähen oder Weitergeben von Kennwörtern – lässt sich auf diese Art allerdings nicht lösen.

Daher war ein Zwei-Faktor-Verfahren – der Besitz eines einmaligen Gegenstandes plus die Kenntnis einer PIN – das Mittel der Wahl. Die wesentlichen Anforderungen an das neue System waren:

• Eingaben, die zu Authentifizierungzwecken durchgeführt werden, durften nicht ausgespäht werden können – selbst dann nicht, wenn ein Angreifer einen Hardware- oder Software-basierten Keylogger installiert.

• Die Anmeldung sollte mit einem einmaligen Gegenstand erfolgen. Wer dieses Zugangs-Token weitergibt, sollte selbst nicht mehr in der Lage sein, sich anzumelden. Der Verlust des Zugangs-Tokens sollte zudem sofort auffallen.

• Ein Zugangs-Token sollte durch niemanden, auch nicht durch die Administratoren, dupliziert werden können.

• Der Besitz des Zugangs-Tokens sollte bei jedem Anmeldevorgang an den unterschiedlichen Anwendungen und Systemen nachgewiesen werden. Eine Single-Sign-On Lösung, bei der nur einmalig überprüft wird, ob der Mitarbeiter im Besitz seines Zugangs-Tokens ist, empfand die Nordrheinische Ärtzeversorgung als zu unsicher.

• Durch die Verwendung des Zugangs-Tokens auch für die Zutrittskontrolle zum Gebäude inklusive aller Zwischentüren und für die Bezahlfunktion in der Kantine sollte die Wahrscheinlichkeit des "versehentlichen Vergessens" des Gegenstandes weiter reduziert werden.

• Wenn ein Mitarbeiter sein Token verliert oder zu Hause liegen lässt, sollte es eine praktikable Lösung geben.

• Das Anmeldesystem durfte nicht durch die Administratoren der betroffenen Anwendungen und auch nicht durch die Administratoren des Anmeldesystems umgangen werden können.

• Die Lösung sollte ausnahmeslos alle Passwörter ersetzen, nicht nur die von besonders sensiblen Anwendungen, da nur so ein neues Anmeldeverfahren akzeptiert wird.

• Die Lösung musste sich in die vorhandene Infrastruktur einpassen, also mit Unix-Servern (Sun Solaris und Linux) funktionieren. Die Anschaffung und Einrichtung von Microsofts Active Directory oder die komplette Umstellung der Benutzerverwaltung waren keine Optionen, die zur Debatte standen.

Handarbeit

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.

Open Source lohnt sich

Open Source lohnt sich

Insgesamt hat sich der Aufwand mehr als bezahlt gemacht. Die Lösung erfüllt alle Anforderungen der Nordrheinischen Ärzteversorgung und sucht nach wie vor – fast vier Jahre nach ihrer Fertigstellung – ihresgleichen im kommerziellen Umfeld.

Die auf freie Software aufbauende Lösung hat sich als sehr flexibel erwiesen, auch in Zusammenhang mit weiteren kommerziellen Produkten, die bei der Erstellung im Jahr 2004 noch nicht im Einsatz waren. So konnte sich die Nordrheinische Ärzteversorgung für ein Produkt zur Erstellung von signierten PDF-Dateien (die Aloaha PDF Suite) entscheiden, weil der Anbieter es in kürzester Zeit an das Anmeldesystem anpassen konnte. Derzeit führt die Nordrheinische Ärzteversorgung ein Dokumenten-Management-System ein, das auf einem Produkt des niederländischen Anbieters BCT basiert. Zu den verbindlichen Auswahlkriterien gehörte die Unterstützung des Authentifizierungsverfahrens; für den Hersteller der Software, die bis zu diesem Zeitpunkt keine Smartcard-Anmeldung unterstützte, war es kein Problem, diese Funktion kurzfristig nachzurüsten.

Anfang des Jahres entschied sich die Nordrheinische Ärzteversorgung mit OpenVPN (Version 2.1) für eine VPN-Lösung, die ebenfalls die Authentifzierung mittels Smartcard unterstützt. Zusätzlich beabsichtigt die Einrichtung, zukünftig die Datensicherungen ihrer Mitarbeiter so zu verschlüsseln, dass sie nur noch mit den Mitarbeiterausweisen oder einem Notfallschlüssel wieder entschlüsselt werden können.

Wir sind uns sicher, dass die Integration der Authentifizierungs-Software in diese zusätzlichen Produkte weitaus komplizierter wäre, hätte man sich vor einigen Jahren für eine proprietäre Lösung entschieden. Sowohl fertige freie Software als auch freie Projekte, die vor einem Einsatz erst noch angepasst werden müssen, werden seitdem immer als Alternative zu kommerziellen Produkten in Erwägung gezogen. Die nachfolgende Liste der bei der Nordrheinischen Ärzteversorgung eingesetzten Open-Source-Software zeigt, dass diese Vorgehensweise auch in einigen anderen IT-Bereichen zum Einsatz von quelloffener Software geführt hat.

Eingesetzte Open Source Software

• Betriebssystem: Slackware 11.0
• Kryptographie: OpenSSL 0.9.8g
• Smartcard-Middleware: OpenSC 0.11.4
• Datei- und Domänenserver: Samba unter Sun-Solaris
• WebServer: Apache mit PHP und Oracle-Anbindung
• Firewall: iptables
• DNS- und DHCP-Server: Linux-basiert mit direkter Schnittstelle zur Oracle-DB
• Mailserver: Sendmail mit direkter Schnittstelle (zum Beispiel für Aliase) zur Oracle-DB
• Monitoring: Syslog-Server mit direkter Ablage der Meldungen in die Oracle-DB
• Hochverfügbarkeit: DRBD, Heartbeat
• Jukebox- und Bandroboter-Steuerung: MTX

Über die Nordrheinische Ärzteversorgung

Die Nordrheinische Ärzteversorgung wurde im Jahr 1958 als Einrichtung der Ärztekammer Nordrhein gegründet. Sie gehört zum System der ersten Säule der Alterssicherung für den ärztlichen Berufsstand im Bezirk Nordrhein. Die Ärzteversorgung hat die Aufgabe, ihren Mitgliedern und sonstigen nach der Satzung zum Empfang von Leistungen Berechtigten eine adäquate Alters-, Berufsunfähigkeits- und Hinterbliebenenversorgung zu gewähren. Derzeit verwaltet die Nordrheinische Ärzteversorgung die Daten von rund 43.000 Mitliedern.

Kontakt

Dr. Peter Koch
Nordrheinische Ärzteversorgung
Abteilung EDV
Tersteegenstrasse 9
40474 Düsseldorf

heise.pkoch@dfgh.net
+49(0)211 4302-1294
(akl)