Weil sie einen USB-Port benutzen, können USB-Token ohne externe Lesegeräte ein Zweifaktor-Authentifizierungssystem etablieren. Ihr lokaler Speicher nimmt neben digitalen Zertifikaten auch weitere Passwörter auf, die sich der Anwender nicht mehr merken muss.

Die jüngste Umfrage der Network Computing hat es gezeigt: Das Passwort dominiert weiterhin als das wichtigste Authentifizierungsmerkmal. 89 Prozent aller Befragten haben dies angegeben. Die anderen Methoden liegen, wie die Ausgabe 18/2004 auf Seite 43 zeigt, abgeschlagen auf den weiteren Plätzen. Das hat seinen guten Grund. Die Stärke des Authentifizierungsmerkmals und der verwendeten -technik sollte sich daran orientieren, wie sensibel und wichtig die zu schützenden Daten sind, auf die der jeweilige Anwender zugreifen darf. Daraus leitet sich schließlich eine Authentifizierungshierarchie ab, die unsensible Bereiche per Passwort abwickelt, während kritische Segmente ein zweites Merkmal einbinden. Man kann diese Hierarchie soweit ausreizen, dass im Hochsicherheitsbereich die Anwender sich biometrisch identifizieren, während ein gewöhnlicher User nur Passwortrichtlinien in Bezug auf Länge einzuhalten hat.

Viele Unternehmen gehen diesen Weg auch aus wirtschaftlichen Gründen, denn das Passwort ist standardmäßig in jeder Anwendung, jedem Betriebssystem enthalten. Zweifaktor- und Multifaktorsysteme brauchen dagegen spezielle Lesegeräte und Identifikationsträger, die für jeden Client angeschafft werden müssen. Diese in Client-Server-Modellen eingegossenen Authentifizierungssysteme müssen auch verwaltet und konfiguriert werden. Zusätzliche Kosten, die das Passwort in der Breite plötzlich rechtfertigen. Trotz der hinlänglich bekannten Mängel.

Die Hersteller der Mehrfaktor-Systeme haben sich daher immens bemüht, die Kosten für ihre Lösungen zu senken. Ihnen kommt entgegen, dass neue Client-Rechner standardmäßig mit einem oder mehreren USB-Ports ausgerüstet sind. Gerade die Token-Anbieter, vorneweg Aladdin, Activcard, Kobil und Vasco, nutzen diesen Anschluss, um sich an den Client zu koppeln. Damit steht nun ein verhältnismäßig kostengünstiger Weg offen, das Passwort-Modell durch diese Zweifaktor-Authentifizierung zu ersetzen. Kostengünstig deswegen, weil keine externen Lesegeräte mehr notwendig sind und der Preis für die Token in den vergangenen Monaten gefallen ist. Derzeit sind Lösungen für rund 60 Euro pro Stück verfügbar, wobei dieser Wert bei größeren Volumina noch weiter fällt.

Token-Offensive

Vor allem Activcard und Aladdin wollen bei den Kosten noch auf einem anderen Feld punkten. Ihre Token beherrschen auch One-Time-Password-Routinen (OTP). Damit kombinieren sie die physikalische Sicherheit – etwas, was der Anwender besitzt – mit klassischem Wissen. Diese neue Token-Generation besitzt ein LCD-Display und einen Knopf. Sobald der Anwender auf den Knopf drückt, generiert der Token eine einzigartige Zahlenkombination, die er über den lokal gespeicherten persönlichen Schlüssel und die aktuelle Zeit berechnet. Diese einzigartige Zahlenkombi nation ist nur in einem frei definierbaren Zeitraum gültig, in dem sich die Anwender über ein entsprechendes Login-Fenster authentifizieren müssen. Um den Prozess in Gang zu setzen, stecken sie den USB-Token in den entsprechenden Port. Der Client startet den Login-Vorgang, fragt nach dem Zahlencode und authentifiziert den Anwender.

Auf diese Weise lassen sich klassische Passwörter generell ersetzen. Und damit all die typischen Probleme, die sie verursachen. Anwender müssen sich keine Passwörter mehr merken. Sie können sie daher nicht vergessen und die Helpdesk-Abteilung belasten. Die Gartner Group hat in einer Studie im Jahr 2003 ermittelt, dass die Kosten für das Zurücksetzen von Passwörtern sich zwischen 40 und 140 Dollar pro Anruf einpendeln. Dabei sollen sich nach den Studienergebnissen rund 80 Prozent der Anrufe um Passwortbelange drehen. Auch das Sicherheitsniveau wird höher, weil schwach formulierte Zugangscodes genauso ausgeschlossen sind wie die Hilfswege der Anwender, die ihre persönlichen Passwörter auf Zetteln notieren und nahezu öffentlich an ihrem Monitor aushängen.

Aber was ist mit all den Zugangscodes, die außer dem Betriebssystem andere Anwendungen wie der Mail- oder Citrix-Client einfordern? Wie jeder USB-Token, so sind auch die Authentifizierungstoken mit unterschiedlich großem Speicher, in der Regel 16 und 32 KByte groß, ausgerüstet. Ablageraum, den weitere Passwörter oder digitale Zertifikate belegen können. Damit diese Daten beim Verlust des Tokens vor Fremden geschützt bleiben, werden sie lokal codiert und in diesem isolierten Chiffrierbereich hinterlegt.

Auch Microsoft tut seiniges dazu, um die Authentizifierung im Windows-Bereich zu stärken. Der Anbieter zertifiziert in seinem »Microsoft Independent Software Vendor«-Programm Lösungen von Fremdanbietern. Ziel ist es, die Interaktion zwischen der Windows-Welt und den externen Produkten zu festigen und zu belegen. Neben Kobil, deren Zertifizierung bereits im April bekannt gegeben wurde, arbeiten auch RSA Security und der PKI-Anbieter Verisign an einer Lösung. Verisign plant beispielsweise, das PKI-Management und die X.509-Attribute in die Active-Directory-Services beziehungsweise die Microsoft-Management-Console einzubinden. Auf diese Weise könnte der Anwender das ganze Projekt von den ihm bekannten Usermanagement-Oberflächen aus steuern. Die Lösungen sollen noch im Laufe dieses Jahres vorgestellt werden.

Innenleben

Jeder USB-Token besitzt intern eine kleine CPU, Speicher und ein eigenes, abgehärtetes Betriebssystem. Der Prozessor ist für sämtliche Chiffrierroutinen zuständig, wobei hier die typischen Verfahren DES, 3DES oder AES eingesetzt werden. Der Speicher ist dafür da, die User-Credentials und verschiedene Schlüssel aufzunehmen. Zudem besitzen die meisten Token ein Shared-Secret.

Wie jedes USB-Gerät, so melden sich die Token ebenfalls selbstständig beim Client an. Dazu greifen sie auf standardisierte Software-Schnittstellen zu. Zu den gängigsten gehören die PKCS#11- und die Microsoft-Crypto-API. Sie liefern die kryptografischen Basisfunktionen, mit denen sie Daten ver- und entschlüsseln oder digitale Signaturen durchreichen. Über Plug-ins koppeln sie sich an die klassischen Authentifizierungsroutinen von Applikationen, sei es nun das Betriebssystem oder ein VPN-Client. Bei Microsoft beispielsweise wir der »GINA«-Prozess um die Zweifaktor-Credentials der Token erweitert. Die Hersteller ihrerseits listen in ihren White-Papers auf, welche Anwendungen und Geräte sie bereits standardmäßig unterstützen. Dazu gehören neben den gängigsten VPN-Gateways und Firewalls auch Webapplikationen wie Citrix oder E-Mail-Tools wie Outlook. Die Integration in Public-Key-Infrastrukturen, beispielsweise von Entrust oder Verisign, ist darin ebenfalls aufgeführt. Jeder Hersteller liefert seine Token in verschiedenen Formaten und Größen. Um weitere Computer-fremde Systeme wie PDAs und Mobiltelefone einzuspannen, bieten sie Software-Token an.

Man sollte aber unbedingt evaluieren, wie die Token den »Safe Mode« von Windows-Plattformen handhaben. Falls sie ihn nicht blocken, so könnte man im Safemode an der Authentifizierung vorbei auf den Client zugreifen und Daten auslesen. Bei gestohlenen Notebooks eine unangenehme und untragbare Nebenwirkung.

Der Test sollte ebenfalls prüfen, wie die Software auf dem Token die lokal gespeicherten und codierten Credentials an den Authentifizierungsprozess externer Anwendungen weiterreicht. Statt das Passwort und die PIN im Klartext auszutauschen, sollte sie nur einen Hash der geheimen Zugangscodes weiterleiten.

Gerade für den Remote-Access-Bereich haben Hersteller wie Authenex daher Verfahren in ihre Token eingebettet, die verhindern sollen, dass die sensiblen Anwenderdaten bei der Authentifizierung den Token verlassen und über den Tunnel transferiert werden. Dazu hat dieser Anbieter ein Challenge-Response-Verfahren implementiert. Sobald ein Programm, sei es der VPN-Client oder die Webverbindung, den Anwender nach seinem Passwort befragt, wird dieser zusätzlich aufgefordert, seinen Token einzuführen. Der Token seinerseits gleicht das Passwort lokal ab und schickt bei positivem Ergebnis seine eigene serielle Nummer über den integrierten Radius-Client an den zentralen, eigenen Authentifizierungsserver im Unternehmen. Der gleicht diese Nummer ab und antwortet mit einer eigenen 128 Bit langen Challenge, die der Token wiederum dazu nutzt, einen völlig neuen Schlüssel zu generieren. Dazu verwendet er wieder seine lokale serielle Nummer und einen der 16 AES-Schlüssel, die lokal bei ihm hinterlegt sind. Diesen neuen Schlüssel schickt der Token an den Authentifizierungsserver zurück, der die Verbindung daraufhin mit dem ausgehandelten Schlüsseldetails etabliert. Auf diese Weise wird verhindert, dass die lokal hinterlegten Anwender-Credentials auch nur einmal den Token verlassen.

Management-Pflichten

Um die Token und ihr Management in das Netz zu integrieren, hat der Administrator im Grunde zwei Möglichkeiten: den Authentifizierungsserver des Herstellers oder eine Integration in bestehende Datenbanken, sei es die Active-Directory (AD) von Microsoft, eine Radius-, LDAP- oder ODBC-sprechende Plattform. Der dezidierte Authentifizierungsserver des Herstellers ist vor allem dafür gedacht, Single-Sign-On-Konzepte zu realisieren. Dazu koppelt er sich über Legacy-Schnittstellen an externe Applikationsserver, um den Anwender beim primären Login gleich bei allen anderen Programmen anzumelden, die er gemäß seinen Benutzerrechten ansteuern darf.

Integriert sich das Zweifaktor-Konzept in bestehenden Datenbanken wie der AD, so erweitert es die dortigen Einträge in der Regel um eigene Attribute. Hierbei ist wichtig, die Spezifikationen und Schemata des jeweiligen Verzeichnisdienstes nicht zu verletzen. Unabhängig davon sollte der Prozess möglichst Wizard-gestützt sein, um die Integration so einfach wie möglich zu gestalten. Im Idealfall fügen sich die Oberfläche und alle Managementbelange im Falle der AD in die bereits existierende Microsoft-Management-Console (MMC) ein. Darüber definiert der Administrator dann die Authentifizierungs-, Autorisierungs- und Accountingdetails. Ein Blick auf die verwendete Policy-Sprache lohnt sich dabei allemal. In seltenen Fällen muss der Administrator leider eine völlig neue Skript-Sprache lernen. Das kostet Zeit und Mühe und lässt potenzielle Fehlerquellen entstehen.

Die Policy selbst muss sowohl für Individuen als auch für Gruppen umsetzbar sein, damit das Management ausreichend skaliert. Sich zeitlich orientierende Regeln sind vor allem im Remote-Access-Bereich sinnvoll, wenn der Administrator beispielsweise den Zugriff auf gewisse interne Ressourcen nur zu gewöhnlichen Bürozeiten freihalten möchte.

Ebenfalls entscheidend ist, dass die verschiedenen Management-Aufgaben über Rechte auf verschiedene Personen aufgeteilt werden können. So ist es sinnvoll, der Helpdesk-Abteilung eine Reset-Funktion einzuräumen, damit sie verloren gegangene Token deaktivieren und vergessene PINs neu vergeben kann.

Zu den Management-Aufgaben gehört ebenfalls das Enrollment der Token. Wie kann man eine Umgebung mit mehreren Hundert Usern schnell und kontrolliert auf die Zweifaktor-Authentifizierung umrüsten? Das Stichwort hier heißt »Selfservice«. In der Regel setzen die Token-Hersteller Wizards ein, die den Anwender beispielsweise über ein Web-Portal instruieren.

Schließlich spielen wie bei allen Sicherheitstools die Monitoring- und Reporting-Tools eine wichtige Rolle. Natürlich müssen diese Werkzeuge neben allen erfolgreichen auch fehlgeschlagene Loginversuche aufzeigen. Die Logs sollte man flexibel nach Kriterien absuchen dürfen. Eine Einbindung über SNMP-Trabs an bereits existierende Frameworks und andere große Management-Applikationen ist vor allem in größeren Bereichen sinnvoll. [ pm ]