Smartcard-Authentifizierung mit Oracle-Forms Teil 1: Theoretisches zur 2-Faktor Authentifizierung Das Smartcard-Projekt der Nordrheinischen Ärzteversorgung Irisstrasse 45 11. November 2004 1
Inhalt Kurzvorführung Authentifizierungsverfahren 1-Faktor / 2-Faktor Methoden Beispiele für 2-Faktor Verfahren (SecureID-Token, Biometrie) Public-Key Authentifizierung Zertifikate Das Smartcard-Projekt der Nordrheinische Ärzteversorgung Anforderungen Die Komponenten der eingesetzten Lösung 2
Authentifizierungsverfahren Passwort-Authentifizierung versus 2-Faktor Methoden Idee: Authentifizierung durch Kenntnis eines Passwortes wird ersetzt durch Authentifizierung durch Besitz eines Gegenstandes + Kenntnis eines Passwortes Vorteile: Gegenstand kann sich nur im Besitz einer Person befinden Passwort schützt im Fall des Verlustes oder bei Diebstahl des Gegenstandes Anforderungen an Gegenstand Gegenstand ist einmalig. Gegenstand ist nicht duplizierbar, auch nicht durch Systemadministratoren. Besitz des Gegenstandes lässt sich von einem entfernten Standort über eine unsichere Leitung gegenüber einem Server beweisen. Mögliche Gegenstände SecurID-Token Biometrische Merkmale (Fingerabdruck, Augenhintergrund, Gesichtszüge) Smartcard 3
SecurID-Token Beim SecurID-Token wird der Beweis des Besitzes dadurch geführt, dass die angezeigte 6-stellige Zahl an den Server übertragen wird Hierbei wird davon ausgegangen, dass: nur diejenige Person die momentan angezeigt Nummer kennen kann, die sich gerade im Besitz des Tokens befindet. Die oft geäußerte Behauptung, dass die Vorhersage der angezeigten Nummern nicht möglich ist, ist allerdings leider falsch. Die Kenntnis der Seriennummer des Tokens und des mathematischen Verfahrens, das in den Token implementiert wurde, reicht aus um die angezeigte Nummer für einen beliebigen Zeitpunkt vorherzuberechnen. z.b.: Token am Schlüsselbund von Dr. Koch, 11.11.2004 11:11 Uhr: 723350 11:12-11:20 Uhr: 112351, 605566, 510242, 624620, 764930, 127020, 953758, 872865, 643819 4
Biometrische Merkmale Der Beweis des Besitzes eines Körperteils kann gegenüber einem Computer offensichtlich nicht auf direktem Wege geführt werden, sondern nur indirekt dadurch, dass mit dem Körperteil computerauswertbare Muster erzeugt werden. Fingerabdruck: Kapazitative Muster auf Fingerabdruckleser. Augenhintergrund oder Gesichtszüge: Muster innerhalb Videobild. Problem 1: Problem 2: Muster lassen sich auch anderweitig erzeugen: Im Falle von Fingerabdrucklesern z.b. durch Tesafilm oder Gummibärchen auf dem Leser oder bei seriellen Lesern durch Abspielen zuvor aufgezeichneter Bytefolgen an der seriellen Schnittstelle. Im Falle von Augenhintergrund oder bei Gesichtszügen durch Fotographien vor der Videokamera oder durch Abspielen von Videosignalen mit einem Videorecorder. Mustererkennung erfolgt meist lokal, daher muss der Server dem Ergebnis der vom Client durchgeführten Mustererkennung vertrauen. Falls die lokale Software so verändert wird, dass sie sich auch ohne korrektes Muster gegenüber dem Server so verhält, als wäre ein korrektes Muster erkannt worden, so hat der Server keine Möglichkeit, das festzustellen. 5
Authentifizierung mit RSA-Schlüsseln Asymmetrische RSA-Schlüssel bestehen aus 2 Teilschlüsseln Einem sogenannten geheimen Schlüssel (SK, Secret Key, Private Key). Dieser ist nur dem Eigentümer des Schlüssels bekannt und muss geheim gehalten werden Einem sogenannten öffentlichen Schlüssel (PK, Public Key). Dieser darf Kommunikationspartnern mitgeteilt werden. Diese beiden Schlüssel haben folgende Eigenschaften: SK lässt sich NICHT aus PK berechnen und umgekehrt Mit SK verschlüsselte Nachrichten lassen sich nur mit PK entschlüsseln und umgekehrt. Dies ermöglicht folgendes Authentifizierungsverfahren Will ein Benutzer sich am Server anmelden, so verschlüsselt der Server eine Zufallszahl mit dem öffentlichen Schlüssel des Benutzers und sendet die verschlüsselte Zahl an den Client. Ist der Benutzer in der Lage die ursprüngliche Zufallszahl zurückzuschicken, muss er im Besitz des passenden privaten Schlüssels sein. Signaturgesetz-konforme Smartkarten Auf diesen Karten befindet sich ein asymmetrisches Schlüsselpaar. Nur der öffentliche Schlüssel lässt sich auslesen. Der private Schlüssel ist gegen Auslesen und Verändern geschützt, kann aber INNERHALB der Karte für kryptografische Operationen benutzt werden. Bei Signaturgesetz-konformen Karten kann deshalb nur derjenige im Besitz des privaten Schlüssels sein, der die Karte selber besitzt (Kopien ausserhalb der Karte existieren nicht). 6
Zertifikate Zertifikate enthalten öffentliche Schlüssel zusammen mit Informationen über den Besitzer des zugehörigen privaten Schlüssels Die im Zertifikat enthaltene Zuordnung zwischen Schlüssel und Besitzer wird durch eine vertrauenswürdige Stelle mit einer elektronischen Signatur bestätigt. Zertifizierungsstellen (CA = Certificate Authority) bieten folgende Dienstleistung an: Komm zu mir, beweise wer du bist, nenne mir deinen öffentlichen Schlüssel, beweise, dass du den passenden privaten Schlüssel besitzt, zahle Geld und ich verschlüssele deinen öffentlichen Schlüssel zusammen mit deinem Namen mit meinem privaten Schlüssel. Vorteile für das Authentifizierungsverfahren Der Server benötigt keine komplette Liste aller öffentlichen Schlüssel, da der Client seinen eigenen öffentlichen Schlüssel innerhalb eines Zertifikates an den Server übermitteln kann. Der Server kann dann durch Überprüfung der Zertifikats-Unterschrift feststellen, ob der öffentliche Schlüssel tatsächlich zur Person gehört, die ihn übermittelt hat. Da die Personengruppe, die berechtigt ist Zertifikate erstellen zu können, nicht mit den Systemadministratoren übereinstimmen muss, kann vermieden werden, dass sich die Systemadministratoren der Authentifizierungsserver uneingeschränkte Rechte verschaffen können. 7
Projektanforderungen Zertifikatsbasierte Authentifizierung Speicherung der geheimen Schlüsseln auf Signaturgesetz-konformen Smartkarten Keine Reproduktionsmöglichkeit der 2-Faktor-Gegenstände, auch nicht durch Adminstratoren und auch nicht durch EDV-Leiter Kein Single-Sign-On, stattdessen einmalige Freischaltung mit PIN und dann Überprüfung des Gegenstandes bei jeder Anmeldung Windows-Logon an Samba-PDC (optional Windows-ADS) Oracle-Anmeldung (Client-Server und OAS / Forms im Web) Secure-Shell Anmeldung an Unix-Rechnern SAP-Anmeldung PKI-Software für Zertifikatsverwaltung praktikable Regelungen im Verlustfall / bei Diebstahl der Smartcard sichere aber trotzdem praktikable Regelungen für die PIN-Vergabe (u.a. PIN-Verteilung per PIN-Brief) 8
Smartcard-Lösung TCOS NetKey E4-Karten mit drei Schlüsselpaaren, Signaturgesetz-konform zusätzlicher Sender für berührungslose Zutrittskontrolle, Zeiterfassung und Bezahlfunktion Verwaltung der Smartkarten, der Zertifikate und der öffentlichen Schlüssel in Oracle-Tabelle. Zugriff auf Smartkarten von Forms (Client-Server-Version) aus via Oracle FFI-Interface (PL/SQL- Package + Windows DLL) Verteilung der PINs mittels PIN-Brief (Ersatz-Briefe für vergessene PINs) Austausch der Windows-Anmelde DLL (MS-GINA.dll) gegen Smartcard-basierte Version (SCardGINA.dll). Anmelde-Server unter Unix zur Anbindung von Samba-Server. PKCS#11-DLL zur Anbindung von Mozilla (SSL-Client-Authentifizierung) SSL Client-Zertifikate können für folgende Authentifizierungszwecke benutzt werden: Zugriff auf nicht allgemein verfügbare Seiten im Intranet Email-Abruf mit Mozilla-Email-Client Authentifizierung vom Browser aus gegenüber Oracle Application SSO-Server Einsatz einer modifizierten Version des Freeware SSH-Clients PuTTY SAP-Gui Anbindung via GSS-API (Stand 11/2004 noch in Arbeit) 9
Smartcard-Lösung Fileserver Printserver Oracle- DB OAS Webserver EMail Unix SAP- DB Windows- Logon Forms Runtime Mozilla Browser SSH Client SAP Gui SCardGINA.dll SCardPKCS11.dll GSS-API SCardLib.dll Karte OpenSSL DLLs 10